it-swarm.com.de

Sicherheitsprobleme im JWT-Speicher

Ich erstelle einen JWT-Anmeldemechanismus für eine Site.

Es gibt zwei sehr gegensätzliche Meinungen darüber, wie das JWT gespeichert werden soll. Stormpath schwört auf Cookies httponly: https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage Auth0 schwört auf localStorage: https://auth0.com/blog/cookies-vs-tokens-definitive-guide

Zuerst habe ich mich für Auth0 entschieden, dann für Stormpath, aber jetzt denke ich wieder, dass localStorage am besten ist. Die Fallstricke von localStorage sind, dass ein xss-Angriff die JWT erfassen kann. Die Fallstricke von auth0 ist, dass ein csrf-Angriff das Cookie stehlen kann.

Es scheint, dass der Entwickler dem Hacker die Cookie-Methode wirklich schwer machen kann, über CSRF Zugriff zu erhalten, aber nicht unmöglich. Wenn der Entwickler jedoch localStorage verwendet und seine Codebasis verwaltet und seine Eingaben bereinigt, scheint es, dass der Hacker keinen Weg hinein hat. Ist das falsch?

12
user2331566

Das Hauptargument für die lokale Speicherung scheint folgendes zu sein:

es ist einfacher, sich vor XSS zu schützen, als sich vor XSRF zu schützen

Das Argument dafür ist, dass XSS angeblich durch automatische Eingabesanierung gelöst wird, während CSRF schwer zu verstehen ist.

Der zweite Punkt mag zutreffen oder auch nicht, aber - wie Ihre Quelle angibt - ist ein vollständiger Schutz gegen CSRF relativ einfach. Wenn Ihre Anwendung ruhig ist, müssen Sie lediglich alle POST - Anfragen nach einem CSRF-Token * überprüfen.

XSS ist dagegen nicht so einfach. Eingabesanierung ist nicht die Lösung, die Codierung der Ausgabe ist. Und das Problem ist, dass diese Codierung vom Kontext abhängt. Eine andere Codierung ist beispielsweise erforderlich, wenn Sie sich in einem JavaScript- oder HTML-Kontext befinden.

Während einige Frameworks Template-Engines mit automatischer Codierung bereitstellen, tun andere dies nicht. Und die automatische Codierung codiert im Allgemeinen nur HTML, berücksichtigt jedoch nicht XSS in einem JavaScript-Kontext. Hinzu kommt, dass viele Entwickler in einigen Fällen die Template-Engines überspringen und Benutzereingaben direkt ausgeben. Ich würde argumentieren, dass XSS schwieriger zu verteidigen ist als CSRF.

* Dies ist etwas vereinfacht und es gibt noch andere Dinge zu beachten. Beispielsweise kann durch HTML-Injection CSRF-Token verloren gehen, und die Anwendung kann tatsächlich GET-Anforderungen verwenden, um den Serverstatus zu ändern.

Fazit

Ich würde nicht zustimmen, dass XSS leichter zu verteidigen ist als CSRF. Da dies das Hauptargument für die lokale Speicherung ist, würde ich mich für den Cookie-Ansatz entscheiden. Es bietet eine kleine Reduzierung für XSS und den zusätzlichen Vorteil, dass relevante Daten nur über HTTPS gesendet werden (über das Attribut "Secure Cookie").

7
tim

Nach meiner Erfahrung als Entwickler und Pen-Tester würde ich argumentieren, dass es wahrscheinlich einfacher ist, mit einem Webentwicklungs-Framework zu arbeiten, das einen integrierten Schutz gegen CSRF bietet, als Entwickler korrekt gegen XSS zu schützen. Dies würde Stormpaths Lösung vorschlagen.

Wahrscheinlich möchten Sie sich trotzdem vor beiden Angriffen schützen.

4
Colin Cassidy

Wahrscheinlich ist die Verwendung einer Kombination aus beiden sicherer, da jedes Geschäft Sie vor einer Angriffsform (XSS oder CSRF) schützt. Hier ist eine schöne Beschreibung darüber:

http://www.redotheweb.com/2015/11/09/api-security.html

0
amit_saxena