csrf absichern

easteregg

easteregg

0
heyho

eins vorweg, das projekt an dme ihc grad arbeite, hat sone absicherung eigentlich gar nicht nötig, ich wills nur machen , damit ich mich damit auskenne ;) kann ja nich schaden.

und zwar, um was es bei csrf geht is ja klar, dass nich jemand mich dazu bringt in nem forum - wo ich per cookie eingeloggt bin - nen beitrag zu schreiben, nur weil der mich auf seine javascript gefüllte seite loggt.

okay soweit so gut.

wie mans macht is ja laut anleitungen im netz recht simpel, einfach ne random id mit ins form rein die dann abgefragt wird.

bleibt bei mir die frage stehen... kann ich nich einfach per javascript mir vorher die id holn?!
also klar, damit brauch man nen request mehr, aber wenn ich einfach mir die seite via javascript hol, die id rausparse und das ganze wieder zurück schick hab ich doch gar keinen schmerz?

oder überseh ich hier was?
danke schonmal ;)
 
Der Clou ist, dass du für jede Seite immer eine neue Id erzeugst, die auch nur einen begrenzten Zeitraum gültig ist. Das heißt, dass für jeden Request eine andere Id erzeugt wird und sie somit nicht vorher abgefragt werden kann. Problematisch wird dies jedoch, wenn du eine persistente XSS Lücke auf der Seite hast, dann lässt sich das natürlich leicht umgehen.
 
jo das so soweit klar, die id die ich generiere ist ja auch immer anders und wird im backend für die session gespeichert und dann überprüft.

wenn ich jetzt aber zwei requests absetz von meiner seite

* der erste holt die id
* der zweite sendet das form mit entsprechend der id

dann hab ich doch auch genau das geschafft, was ich ohne die id schaffen würde?
überseh ich hier was?
 
Es gibt an sich zwei Fälle, die es zu unterscheiden gilt.

Fall 1 ist, dass das Javascript nicht von deinem Server kommt. Das könnte passieren, wenn du auf irgendeiner Webseite surfst, und diese versucht, per JavaScript über deine Facebook-Session Aktionen auszuführen. In diesem Fall hilft dir die zufällige ID, denn das Javascript auf der fremden Seite hat keine Chance, diese zu erhalten.

Fall 2 ist der, dass dein Server im Kontext deiner Session das bösartige Javascript ausliefert. Ein Beispiel ist, dass du das Verschicken von Nachrichten oder das Erstellen von Kommentaren erlaubst, und diese nicht korrekt validierst. In diesem Fall kann das Script natürlich die ID aus der Seite auslesen und damit Aktionen tätigen. Das einzige, was die ID jetzt noch (vielleicht) verhindert ist, dass das ganze unbemerkt geschieht. Der Server erstellt schließlich für jeden Seitenaufruf neue IDs, sodass du beim Weitersurfen die falsche ID verwendest. Wenn sich der Autor des Scripts etwas mehr Mühe gibt, kann er natürlich die neue ID überall eintragen, sodass du trotzdem nichts merkst.

Die Konsequenz ist, dass diese ID nur zusätzliche, aber keine totale Sicherheit bietet. Fall 1 ist allerdings der, der für einen Angreifer sehr viel leichter durchzuführen ist, schließlich benötigt er keinen Bug auf deinem Server.
Um diesen Fall zu verhindern könntest du natürlich auch den Referer checken, was normalerweise einfacher umzusetzen ist. Außerdem verhinderst du dann (afaik) nicht das Benutzen des Zurück-Buttons.
 
Eine solche Id (aka Pagetoken) macht jede URL der Seite "einzigartig". Das heißt, wenn du einen Request stellen willst, um die Id, die nötig ist um einen Post abzuschicken, abzufragen, brauchst du die gültige Id zu der Seite, auf der du deinen Post erstellen kannst. Um diese gültige Id zu bekommen, brauchst du die Id, die benötigt wird um auf diese Seite zu kommen usw. Da jede Id nur für eine Abfrage gültig ist, hat der Angreifer keine Chance eine gültige Id zu bekommen.
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben