Sind JSON-Webdienste anfällig für CSRF-Angriffe?

82

Ich erstelle einen Webdienst, der ausschließlich JSON für seine Anforderungs- und Antwortinhalte verwendet (dh keine formularcodierten Nutzdaten).

Ist ein Webdienst für CSRF-Angriffe anfällig, wenn Folgendes zutrifft?

Jede POSTAnfrage ohne ein JSON-Objekt der obersten Ebene, z. B., {"foo":"bar"}wird mit einer 400 abgelehnt. Beispielsweise würde eine POSTAnfrage mit dem Inhalt 42somit abgelehnt.
Jede POSTAnfrage mit einem anderen Inhaltstyp als application/jsonwird mit einem 400 abgelehnt. Beispielsweise würde eine POSTAnfrage mit einem Inhaltstyp application/x-www-form-urlencodedabgelehnt.
Alle GET-Anforderungen sind sicher und ändern daher keine serverseitigen Daten.
Clients werden über ein Sitzungscookie authentifiziert, das ihnen der Webdienst gibt, nachdem sie über einen POST mit JSON-Daten ein korrektes Paar aus Benutzername und Kennwort angegeben haben, z {"username":"user@example.com", "password":"my password"}.

Nebenfrage: Sind PUTund DELETEAnfragen jemals für CSRF anfällig? Ich frage, weil es den Anschein hat, dass die meisten (alle?) Browser diese Methoden in HTML-Formularen nicht zulassen.

BEARBEITEN: Artikel 4 hinzugefügt.

BEARBEITEN: Bisher viele gute Kommentare und Antworten, aber niemand hat einen bestimmten CSRF-Angriff angeboten, für den dieser Webdienst anfällig ist.

http security csrf

— DJsmith
quelle

Tokenisieren Sie Ihre Anfragen über Session- und Cookie-gepaarte Werte, bereinigen Sie alle Anweisungen, die Sie über den übermittelten JSON auslösen, und fügen Sie Salz für zusätzlichen Geschmack hinzu

— Brandt Solovij,

Ich glaube nicht, dass es hier genug Informationen gibt, um eine gute Antwort zu geben. Welche Authentifizierungsmethode verwenden Sie? Wer sind die beabsichtigten Verbraucher des Webdienstes (dh Benutzer einer Website auf demselben Host wie Ihr Dienst?)

— McGarnagle

1

Alle Ihre aktuellen Validierungen sind absolut sinnvoll und begrenzen Ihre Angriffsfläche, aber sie befassen sich nicht mit der CSRF-Sicherheitsanfälligkeit.

— Cheekysoft

2

Siehe security.stackexchange.com/questions/10227/csrf-with-json-post

— eskatos

2

@ DavidBalažic Welcher Vektor? Wenn Sie über AJAX sprechen, verhindern Richtlinien mit demselben Ursprung dies.

— DJsmith

73

Schmieden willkürliche CSRF - Anfragen mit beliebigen Medientypen ist effektiv nur mit XHR, weil ein Methode des Formulars beschränkt ist , GET und POST und ein POST - Nachrichtentext des Formulars wird auch auf die drei Formate beschränkt application/x-www-form-urlencoded, multipart/form-dataundtext/plain . Mit der Formulardatencodierung ist text/plaines jedoch weiterhin möglich, Anforderungen zu fälschen, die gültige JSON-Daten enthalten .

Die einzige Bedrohung geht also von XHR-basierten CSRF-Angriffen aus. Und diese werden nur dann erfolgreich sein, wenn sie denselben Ursprung haben, also im Grunde genommen irgendwie von Ihrer eigenen Site (z. B. XSS). Achten Sie darauf, CORS nicht als Schutz zu deaktivieren (dh Access-Control-Allow-Origin: * nicht festzulegen). CORS verhindert einfach, dass Clients die Antwort lesen. Die gesamte Anfrage wird weiterhin vom Server gesendet und verarbeitet.

— Gumbo
quelle

9

Während ich Ihre verknüpfte Antwort kommentierte, versichere ich, dass Text / Plain tatsächlich für JSON-Fälschungen verwendet werden kann, wenn der Server keine Anwendung / JSON benötigt, wobei Techniken verwendet werden, die pentestmonkey.net/blog/csrf-xml-post-request ähneln .

8

Diese Antwort ist bis heute richtig, wird aber wahrscheinlich bald falsch sein. W3C erwägt, dem HTML-Standard enctype = "application / json" hinzuzufügen : darobin.github.io/formic/specs/json Verlassen Sie sich für dauerhafte Sicherheit nicht auf den Typ des POST-Körpers, sondern verwenden Sie ein Anti-CSRF-Token.

— LordOfThePigs

@LordOfThePigs Das Fälschen von gültigem JSON ist bereits mit Text / Plain möglich .

— Gumbo

@Gumbo korrekt, aber Sie können derzeit nicht festlegen, auf application/jsonwelchen Enctype CSRF-Angriffe in dieser Antwort abgewehrt werden sollen . Mit dem vorgeschlagenen Standard können Sie den Enctype auf setzen application/json, wodurch die in der Antwort beschriebenen Inhaltsartenprüfungen zunichte gemacht und die Anwendung für CSRF geöffnet werden.

— LordOfThePigs

10

Es sieht so aus, als würde der Entwurf diesen Angriff vorwegnehmen. In Abschnitt 5 wird festgelegt, dass application/jsonFormularbeiträge der gleichen Ursprungsrichtlinie entsprechen müssen, was bedeutet, dass der Angriff nicht stärker als XHR ist.

— James_pic

3

Ja, es ist möglich. Sie können einen Angreifer-Server einrichten, der eine 307-Weiterleitung an den Zielserver an den Opfercomputer zurücksendet. Sie müssen Flash verwenden, um den POST zu senden, anstatt das Formular zu verwenden.

Referenz: https://bugzilla.mozilla.org/show_bug.cgi?id=1436241

Es funktioniert auch auf Chrome.

— Timothy Leung
quelle

1

Es ist möglich, CSRF auf JSON-basierten Restful-Diensten mit Ajax durchzuführen. Ich habe dies in einer Anwendung getestet (sowohl mit Chrome als auch mit Firefox). Sie müssen den contentType in text / plain und den dataType in JSON ändern, um eine Preflight-Anforderung zu vermeiden. Dann können Sie die Anfrage senden, aber um Sitzungsdaten zu senden, müssen Sie das withCredentials-Flag in Ihrer Ajax-Anfrage setzen. Ich diskutiere dies hier ausführlicher (Referenzen sind enthalten):

http://wsecblog.blogspot.be/2016/03/csrf-with-json-post-via-ajax.html

— Filip Waeytens
quelle

Das ist unnötig. Wenn der Server Klartextanforderungen als JSON liest, reicht ein als Klartext codiertes Formular aus, um eine solche Anforderung zu fälschen, wie Gumbo erwähnt hat. API-Server sollten Klartextanforderungen einfach ablehnen.

— Franklin Yu

-1

Ich habe einige Zweifel in Bezug auf Punkt 3. Obwohl dies als sicher angesehen werden kann, da es die Daten auf der Serverseite nicht verändert, können die Daten dennoch gelesen werden und das Risiko besteht darin, dass sie gestohlen werden können.

http://haacked.com/archive/2008/11/20/anatomy-of-a-subtle-json-vulnerability.aspx/

— panteo
quelle

1

Dies funktioniert nur, wenn das von der API zurückgegebene Objekt der obersten Ebene ein JSON-Array ist, da Javascript das Überschreiben des Array-Konstruktors ermöglicht. Ein Objekt der obersten Ebene ist sicher. Mehr unter flask.pocoo.org/docs/0.10/security/#json-security .

— Btubbs

Laut dem Autor selbst " glaube ich nicht, dass moderne Browser diesen Fehler mehr haben ".

— Franklin Yu

-6

Ist ein Webdienst für CSRF-Angriffe anfällig, wenn Folgendes zutrifft?

Ja. Es ist immer noch HTTP.

Sind PUT- und DELETE-Anfragen jemals für CSRF anfällig?

Ja

Es scheint, dass die meisten (alle?) Browser diese Methoden in HTML-Formularen nicht zulassen

Denken Sie, dass ein Browser die einzige Möglichkeit ist, eine HTTP-Anfrage zu stellen?

— symcbean
quelle

3

Nur weil ein Dienst HTTP verwendet, ist er nicht anfällig für CSRF. Können Sie einen tatsächlichen CSRF-Angriffsvektor identifizieren, für den dieser Dienst wie beschrieben anfällig ist? Und natürlich denke ich nicht, dass ein Browser die einzige Möglichkeit ist, eine HTTP-Anfrage zu stellen, aber der Browser ist die häufigste (nur?) Methode, mit der ein Benutzer dazu verleitet wird, eine gefälschte, standortübergreifende Anfrage zu stellen, die er nicht gestellt hat erwarten von.

— DJsmith

Mit anderen Worten, zeigen Sie mir einen bestimmten CSRF-Angriffsvektor, der PUT verwendet, um einen Benutzer dazu zu bringen, eine PUT-Anforderung an meinen Webdienst zu senden (wie beschrieben). Ich glaube es ist nicht möglich.

— DJsmith

@symcbean: Könnten Sie bitte entweder Referenzen posten oder Ihre Antwort auf andere Weise verteidigen? Ich habe nicht über diese Antwort abgestimmt. Ich möchte, dass Sie sich zuerst einschalten. Vielen Dank.

— Dotancohen

Ist Google wieder ausgefallen? Abgesehen vom inhaltlichen Typ haben alte Versionen von Flash (neuere Versionen von Flash haben ein domänenübergreifendes Kontrollmodell - aber es unterscheidet sich von HTML5) - wie wäre es mit Glasschmuggel - pseudo-flaw.net/content/web-browsers/corrupted -jars (Java wird im aktiven Kontext ausgeführt, kann jedoch im passiven Kontext Javascript aufrufen). Dann gibt es DNS-Rebinding-Angriffe und MITM-Angriffe

— Symcbean

Browser-Plugins können Ihr CSRF-Cookie lesen und jeden gewünschten Header senden, sodass selbst die standardmäßigen CSRF-Durchsetzungsmechanismen für ein böswilliges Browser-Plugin anfällig sind.

— DJsmith