it-swarm.com.de

Zugriffskontrolle-Erlaubnis-Ursprung: * mit einem Inhaber-Token

Beim Testen einer Anwendung mit nur einer Seite habe ich festgestellt, dass die Endpunkte REST] CORS-Header zurückgeben, die domänenübergreifenden Zugriff ermöglichen:

access-control-allow-credentials: true
access-control-allow-methods: GET, POST, DELETE, PUT
access-control-allow-Origin: *

Diese Endpunkte verarbeiten vertrauliche Daten. Meine erste Reaktion darauf besteht darin, eine Sicherheitsanfälligkeit mit hohem Risiko auszulösen.

Als ich jedoch versuchte, das Problem auszunutzen, stellte ich fest, dass ich es nicht konnte. Die Site verwendet anstelle eines Sitzungscookies ein Inhaber-Token im Autorisierungsheader. Es ist zwar möglich, domänenübergreifende Anforderungen zu stellen, der erforderliche Header kann jedoch nicht angehängt werden.

Was sind die Risiken bei diesem Modell? Ist das eine vernünftige Art, Dinge zu tun?

15
paj28

Es gibt einige Dinge, die bedeuten, dass Ausbeutung unwahrscheinlich ist.

Beginnen mit

access-control-allow-credentials: true
access-control-allow-Origin: *

ist eine ngültige Kombination :

Wichtiger Hinweis: Bei der Beantwortung einer Anfrage mit Anmeldeinformationen muss der Server eine Domäne angeben und darf kein Platzhalterzeichen verwenden. Das obige Beispiel würde fehlschlagen, wenn der Header mit einem Platzhalter versehen wäre: Access-Control-Allow-Origin: *. Da in Access-Control-Allow-Origin explizit http://foo.example Erwähnt wird, wird der Inhalt mit Anmeldeinformationen an den aufrufenden Webinhalt zurückgegeben.

Eine andere Sache ist, dass der Autorisierungsheader ist kein einfacher Header , daher würde ein Preflight erforderlich sein, der zu einer Access-Control-Allow-Headers Antwort führt, die diesen Header zurückgibt. Der Server, der dies nicht zurückgibt, würde auch einen CSRF-Angriff verhindern, da der Vorflug ihn blockiert.

Wenn der Header nicht zulässig ist, ist es normalerweise nicht möglich, einen benutzerdefinierten Header domänenübergreifend hinzuzufügen, es sei denn, Sie versuchen einen Exploit mit Flash , der in bestimmten Browsern verwendet wurde.

Was sind die Risiken bei diesem Modell? Ist das eine vernünftige Art, Dinge zu tun?

Da es ungültig ist, diese Kombination von Headern anzugeben, ist dies in der Tat keine sinnvolle Vorgehensweise. Möglicherweise gibt es einen seltsamen Browser, der dies zulässt, und die Website ist anfällig (sollte ein potenzielles Opfer sie verwenden). Wenn Sie alle Ursprünge, jedoch keine Anmeldeinformationen zulassen, kann der Browser des Opfers kann als eine Art Proxy verwendet werden , um auf ansonsten unzugängliche Ressourcen zuzugreifen. Da der Bearer-Header jedoch nicht angehängt werden kann (ohne einen Flash-Exploit) und durch Access-Control-Allow-Headers Erlaubt wird, würde ich nicht sagen, dass dies ein hohes Risiko darstellt. Da der Angreifer nicht über das Inhaber-Token seines Opfers verfügt, werden alle domänenübergreifenden Anforderungen, die gestellt werden, eher von der Sitzung des Angreifers als von der Sitzung des Opfers gestellt.

Ich würde wahrscheinlich als Hinweis darauf hinweisen, dass sie überprüfen sollten, ob ihre CORS-Header ihrer Absicht entsprechen.

11
SilverlightFox