AJAX gegen CSRF absichern?

[metty]

Hallo zusammen.

Wie der Betreff schon erahnen lässt, interessiert es mich ob es notwendig ist Requests die via AJAX gesendet werden, gegen CSRF zu schützen. Die Django Doku gibt an, das es nicht notwendig sei:

...We can do this safely because, in the context of a browser, the header can only be added by using XMLHttpRequest, and browsers already implement a same-domain policy for XMLHttpRequest....

Auch unter stackoverflow wurde darüber diskutiert und ist nach etwas hin und her ebenfalls zum Schluss gekommen, dass eine Absicherung gegen CSRF nicht notwendig sei. Ich persönlich würde jetzt auch mal behaupten, das Requests via AJAX (relativ) sicher sind. Natürlich, wenn die Seite nicht auch noch eine XSS-Schwäche aufweist...

Wie geht ihr vor? Sichert ihr eure AJAX-Requests mit einem csrf-token ab?

Freundliche Grüße

[Hyperion]

Es gibt eine CSRF-Extension für flask. Evtl. gibt Dir das ja ein wenig Aufschluss darüber, wo so ein Schutz greift und weswegen er ggf. abhängig vom Framework nicht nötig ist.

[metty]

Es gibt eine CSRF-Extension für flask. Evtl. gibt Dir das ja ein wenig Aufschluss darüber, wo so ein Schutz greift und weswegen er ggf. abhängig vom Framework nicht nötig ist.

Auf den ersten Blick macht es das selbe wie der CSRF-Schutz bei Django. Es fügt ein "hidden input" in ein Formular ein.

[DasIch]

Wie die Django Dokumentation schon klar stellt für (REST) APIs braucht man kein CSRF da Browser eine same-domain policy haben.

[Darii]

Wie die Django Dokumentation schon klar stellt für (REST) APIs braucht man kein CSRF da Browser eine same-domain policy haben.

Was meinst du mit REST-API? Jede per GET aufrufbare URL kann eine REST-Ressource sein. Natürlich muss man sich gerade bei einer definierten Schnittstelle gegen CSRF schützen. CSRF basiert ja gerade genau auf dem Vorhandensein einer eben solchen. Wenn es keine Möglichkeit für den Angreifer gibt die für den Angriff notwendige URL/Request in Erfahrung zu bringen, ist auch kein CSRF möglich.

[apollo13]

Wie die Django Dokumentation schon klar stellt für (REST) APIs braucht man kein CSRF da Browser eine same-domain policy haben.

Was meinst du mit REST-API? Jede per GET aufrufbare URL kann eine REST-Ressource sein.

GET sollte man nicht gegen CSRF absichern müssen, da GET keine Ressourcen verändern sollte.

Natürlich muss man sich gerade bei einer definierten Schnittstelle gegen CSRF schützen. CSRF basiert ja gerade genau auf dem Vorhandensein einer eben solchen. Wenn es keine Möglichkeit für den Angreifer gibt die für den Angriff notwendige URL/Request in Erfahrung zu bringen, ist auch kein CSRF möglich.

Jein, wie schon gesagt: GET sollte side-effect free sein. Ein Angreifer darf über GET also erstmals keinen Schaden anrichten. POST requests muss man natürlich absichern; solange sie nicht via XHR kommen, denn da ist JS im Browser an die same-origin Policy gebunden.

[Darii]

Wie die Django Dokumentation schon klar stellt für (REST) APIs braucht man kein CSRF da Browser eine same-domain policy haben.

Was meinst du mit REST-API? Jede per GET aufrufbare URL kann eine REST-Ressource sein.

GET sollte man nicht gegen CSRF absichern müssen, da GET keine Ressourcen verändern sollte.

Aber kann und darf. Ich kann mich noch dunkel daran erinnern, dass es mal Probleme mit Mozilla link-prefetch Funktion gab…

[apollo13]

Aber kann und darf.

Technische Möglichkeit ist dennoch kein Freifahrtsschein, wenn GET-Requests Daten verändern bist du selber Schuld…

EDIT:// Es steht btw sogar in der Http1.1 Spec, dass man GET nicht für Änderungen verwenden soll:

In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.

Wenn du dann noch immer GET verwendest um Daten zu ändern fällt das unter; selber schuld, kein mitleid.

[metty]

GET sollte man nicht gegen CSRF absichern müssen, da GET keine Ressourcen verändern sollte.

Das sehe ich genau so...

Leider gibts aber immer wieder Negativbeispiele ala "adduser.php?username=max&password=1234"

[Darii]

EDIT:// Es steht btw sogar in der Http1.1 Spec, dass man GET nicht für Änderungen verwenden soll:

Was heißt sogar? Wenns woanders stünde, wäre es irrelevant.

Aber zum Glück steht da „should not“ und nicht „must not“. Denn darauf, dass es ziemlich umständlich/unmöglich ist, den Browser per HTML zu nicht-GET zu bewegen, ist HTTP nicht vorbereitet (oder umgekehrt HTML ist nicht dafür ausgelegt, dass man mit GET nichts verändern darf). Ohne JS wird man in der Beziehung leider nicht froh). Ein <a method="DELETE" href=".. würde ja schon reichen.

Gegen das Prinzip per GET nichts zu verändern verstößt ja beispielsweise dieses Forum schon mehrmals(z.B. der „Forum beobachten“-Link)…

[apollo13]

Gegen das Prinzip per GET nichts zu verändern verstößt ja beispielsweise dieses Forum schon mehrmals(z.B. der „Forum beobachten“-Link)…

Klar, aber da es in dem Fall eher nicht so gefährlich ist würd ich das auch tun…