Cross Site History Manipulation Auflösung

Question

Wir haben eine neue Anwendung entwickelt und vor dem Verschieben der Änderungen haben wir einen statischen Scan von Code mit checkmarx durchgeführt. Es gibt eine Sicherheitslücke auf mittlerer Ebene, die im Code "Cross Site History Manipulation" gefunden wird.

Dies wird in der JSP-Seite detacted, wo ich die Sitzungswerte am Validieren:

if(request.getSession().getAttribute("sesStrUID")!=null) 

Können Sie mir bitte helfen, diese Verwundbarkeit zu verstehen und was getan werden sollte, diese zu beseitigen?

Answer 1

Von OWASP Site

Cross-Site Geschichte Manipulation (xshm) ist ein SOP (Same Origin Policy) Sicherheitsverletzung. SOP ist das wichtigste Sicherheitskonzept moderner Browser . SOP bedeutet, dass Webseiten unterschiedlicher Herkunft von Design nicht miteinander kommunizieren können. Die Manipulation der standortübergreifenden History beruht auf der Tatsache, dass das clientseitige Browserverlaufsobjekt nicht ordnungsgemäß pro Site partitioniert ist. Manipulieren Browser Geschichte kann dazu führen, SOP kompromittieren, ermöglichen bidirektionale CSRF und andere Auswertungen wie: Verletzung der Benutzer-Privatsphäre, Login-Status Erkennung, Ressourcen-Mapping, sensible Informationen Inferenz, Aktivität Tracking-und URL-Parameter zu stehlen.

Mit request.getSession().getAttribute("sesStrUID"), Sie sind nicht etwas zu tun, die Browser-Geschichte geht, sieht so wie seine falsche Erkennung

Answer 2

Dies ist mehr ein browser vulnerability than a website vulnerability in Internet Explorer from 2010:

Checkmarx Research Labs eine neue kritische identifiziert Schwachstelle in Internet Explorer (andere Browser sind wahrscheinlich auf die gleiche Weise ausgesetzt), dass Hacker erlauben würde, Web-Anwendungen leicht zu kompromittieren.

Dies ist eine Verletzung der gleichen Ursprungsrichtlinie durch den Browser und es ist nicht etwas, das Sie in Ihrer Webanwendung beheben sollten. Die gemeldete Sicherheitsanfälligkeit bezieht sich wahrscheinlich auf eine Weiterleitung, die Sie basierend auf Ihrem Zustand durchführen. Es heißt, dass wenn Sie serverseitig auf der Sitzung sesStrUID Wert umleiten, dann könnte ein Angreifer IFrame Ihre Website, und wenn es erkennt, dass Sie umleiten, kann daraus ableiten, ob sesStrUID Null ist oder nicht.

Dies ist nur ein Problem, wenn Ihre Benutzer einen fehlerhaften Browser verwenden. Wenn Ihre Benutzer moderne Browser verwenden, ist es nicht wert, IMO zu reparieren. Wenn Sie besonders sicher sein und auch vor Clickjacking-Angriffen schützen möchten, können Sie den HTTP-Header X-Frame-Options: DENY ausgeben, um Framing zu verhindern. Bitte beachten Sie, dass dies nur Sie vor der IFrame-Version des Angriffs schützen würde. Für andere Angriffsvektoren, die in der Tiefe diskutiert werden, check out this XSHM paper.

bearbeitet nach @ adar Antwort:

Adar Antwort ist sehr ähnlich wie ich und enthält viel die gleichen Informationen, es sei denn, dass das Plakat sagt, dass dies immer noch ein Problem.

Allerdings ist XSHM kein Problem, wenn Sie Server-Seite über die location HTTP header umleiten. HTTP 3xx redirects bewirken, dass der Wert history.length in modernen Browsern nicht erhöht wird, sodass nicht ermittelt werden kann, ob der Benutzer an einer bestimmten Site angemeldet ist.

Wenn Sie JavaScript-Code ausgeben Umleitung nach dem

if(request.getSession().getAttribute("sesStrUID")!=null) 

Code dann xshm ein Problem, wenn Sie Server-Seite umleiten

<% 
    String redirectURL = "http://example.com/myJSPFile.jsp"; 
    response.sendRedirect(redirectURL); 
%> 

dann sind Sie nicht anfällig.

bearbeiten nach Antwort des @ adar II:

@adar ist richtig: Wenn Sie die folgende Angriffsszenario versuchen:

1. öffnen Login.jsp in einem IFrame - Geschichte enthält Login.jsp.
2. öffnen ShowSecretInfo.jsp - wenn der Server dann auf Login.jsp mit HTTP-Umleitungen 3xx, bleiben history.length wird dann gleich, wenn ein Server zeigt ShowSecretInfo.jsp-history.length von 1.

Deshalb, wenn history.length erhöht erhöht wird, können Sie bestimmen, dass der Benutzer angemeldet ist. Ich konnte das oben mit IE 11 und Firefox 33.1 unter Windows 7 neu erstellen. Chrome 39 ist auf diese Weise nicht anfällig für meine Tests, aber es ist in einem anderen:

Angenommen, dass /ShowSecretInfo.jsp umgeleitet wird /Login.jsp (ohne q uery), wenn der Benutzer nicht angemeldet

1. öffnen /ShowSecretInfo.jsp in einem IFrame -. Geschichte enthält /ShowSecretInfo.jsp.
2. die iframe src zu /Login.jsp Set - wenn history.length nicht erhöht, dann wissen Sie, der Benutzer angemeldet ist

Es scheint, dass Chrome nicht umgeleitet werden nicht versuchen, wenn die src bereits auf die aktuelle URL festgelegt ist. . Ich könnte das auch in IE und Firefox neu erstellen.

Answer 3

Hier ist die Antwort, die ich von Alex Roichman bekam, Chief Software Architect @Checkmarx:

Cross-Site-Geschichte Manipulation ein Browser Same Origin Policy Verletzung ist, wo es möglich ist, einen Zustand einer Bedingung von einem anderen Ursprung kennen. Zum Beispiel überprüfen viele Seiten, ob ein Benutzer authentifiziert wurde, bevor er ihnen seine privaten Daten zeigte. Dies kann durch folgenden Code erfolgen:

If (!IsAuthenticated()) 
      Redirect “login.jsp” 

Durch xshm Verwendung ist es möglich, von einer anderen Seite wissen, ob ein Benutzer gerade an dieser Stelle authentifiziert wird.

Lassen Sie uns nun für eine gegebene Zeile aussehen:

if(request.getSession().getAttribute("sesStrUID")!=null) 

Diese Linie scheint zu überprüfen, ob ein Benutzer eine Sitzung oder sogar bereits authentifiziert hat. Da innerhalb der 'if' Anweisung 'redirect' steht, ist es für jede andere Seite möglich zu wissen, dass request.getSession().getAttribute("sesStrUID")!=null oder wenn ein Benutzer bereits authentifiziert wurde.
Also dieses Ergebnis ist wahr und es hat nichts mit alten oder modernen Browsern: alle modernen Browser bieten einen Zugriff auf history.lengh, Diese Eigenschaft kann zu Verletzungen der Privatsphäre über XSHM führen, und es gibt keine einfache Lösung aus Gründen der Abwärtskompatibilität .

X-Frame-Options: DENY kann vor der IFrame-Version von XSHM schützen, aber alte Browser unterstützen diese Option nicht.

bearbeiten nach SilverlightFox Antwort

Ich bin damit einverstanden wir haben sehr ähnliche Antworten.

Dennoch betreffend:

Dies ist richtig und xshm auf dieser Basis genau „3xx Umleitungen nicht den Wert von history.length bewirken in modernen Browsern erhöht werden“ .

Suchen Sie nach dem folgenden Angriffsszenario:

1. Open ‚Login.jsp‘ in einem IFrame - jetzt Geschichte enthält ‚login.jsp‘ oben drauf.
2. Öffnen Sie 'ShowSecretInfo.jsp' - wenn ein Server zu 'Login.jsp' mit 3xx umleitet, dann bleibt history.length gleich, wenn ein Server 'ShowSecretInfo.jsp'- history.length anzeigen wird, wird erhöht von 1.

und dies bedeutet, dass ein angegriffener Benutzer authentifiziert ist - Verletzung der Privatsphäre.