Quer-Seite scripting (XSS) ist ein Typ der in Webanwendungen normalerweise gefundenen Computerunsicherheitsverwundbarkeit (wie WWW-Browser durch Brüche der Browser-Sicherheit), der Angreifern ermöglicht, Kundenseite-Schrift in von anderen Benutzern angesehene Webseiten einzuspritzen. Eine Quer-Seite scripting Verwundbarkeit kann von Angreifern verwendet werden, um Zugriffssteuerungen wie dieselbe Ursprung-Politik zu umgehen. Quer-Seite scripting ausgeführt auf Websites ist für ungefähr 80.5 % der ganzen Sicherheitsverwundbarkeit verantwortlich gewesen, die von Symantec bezüglich 2007 dokumentiert ist. Ihre Wirkung kann sich von einem unbedeutenden Ärger bis ein bedeutendes Sicherheitsrisiko abhängig von der Empfindlichkeit der Daten erstrecken, die durch die verwundbare Seite und die Natur jeder vom Eigentümer der Seite durchgeführten Sicherheitsmilderung behandelt sind.

Hintergrund

Quer-Seite scripting Löcher ist Webanwendungsverwundbarkeit, die Angreifern erlaubt, Kundenseite-Sicherheitsmechanismen zu umgehen, die normalerweise dem Webinhalt durch moderne WWW-Browser auferlegt sind. Indem er Weisen findet, böswillige Schriften in Webseiten einzuspritzen, kann ein Angreifer erhobene Zugriffsvorzüge zum empfindlichen Seiteninhalt, den Sitzungsplätzchen und einer Vielfalt anderer Information gewinnen, die durch den Browser im Auftrag des Benutzers aufrechterhalten ist. Quer-Seite scripting Angriffe ist deshalb ein spezieller Fall der Codeeinspritzung.

Der Ausdruck "Quer-Seite scripting" ursprünglich verwiesen auf die Tat, die angegriffene Drittwebanwendung von einer Angriffsseite ohne Beziehung gewissermaßen zu laden der ein Bruchstück von JavaScript durchführt, der vom Angreifer im Sicherheitszusammenhang des ins Visier genommenen Gebiets (eine widerspiegelte oder nichtbeharrliche XSS Verwundbarkeit) bereit ist. Die Definition, die allmählich ausgebreitet ist, um andere Weisen der Codeeinspritzung, einschließlich beharrlicher und non-JavaScript Vektoren (einschließlich Javas, ActiveX, VBScript, Blitzes, oder sogar reinen HTML und SQL-Abfragen) zu umfassen, etwas Verwirrung Neulingen zum Feld der Informationssicherheit verursachend.

XSS Verwundbarkeit ist berichtet und seit den 1990er Jahren ausgenutzt worden. Prominente in der Vergangenheit betroffene Seiten schließen das sozial vernetzende Seite-Gezwitscher, ein

Facebook,

MySpace und Orkut. In den letzten Jahren hat Quer-Seite scripting Fehler Pufferüberschwemmungen übertroffen, um die allgemeinste öffentlich berichtete Sicherheitsverwundbarkeit mit einigen Forschern zu werden, 2007 nicht weniger als 68 % von Websites als wahrscheinlich offen für XSS-Angriffe ansehend.

Typen

Es gibt keine einzelne, standardisierte Klassifikation der Quer-Seite scripting Fehler, aber die meisten Experten unterscheiden zwischen mindestens zwei primären Geschmäcken nach XSS: nichtbeharrlich und beharrlich. Einige Quellen teilen weiter diese zwei Gruppen in den traditionellen (verursacht durch Codefehler der Server-Seite) und DOM-basiert (im Kundenseite-Code).

Nichtbeharrlich

Das nichtbeharrliche (oder widerspiegelt) Quer-Seite scripting Verwundbarkeit ist bei weitem der allgemeinste Typ. Diese Löcher tauchen auf, wenn die Daten, die von einem Webkunden meistens in HTTP-Anfragenrahmen oder in HTML-Form-Vorlagen zur Verfügung gestellt sind, sofort durch Schriften der Server-Seite verwendet werden, um eine Seite von Ergebnissen für diesen Benutzer zu erzeugen, ohne die Bitte richtig zu sterilisieren.

Weil HTML-Dokumente eine flache Serienstruktur haben, die Kontrollbehauptungen, Formatierung und den wirklichen Inhalt mischt, irgendwelche gültig nichtgemachten benutzergelieferten Daten, die in die resultierende Seite ohne richtige HTML-Verschlüsselung eingeschlossen sind, kann zu Preiserhöhungseinspritzung führen. Ein klassisches Beispiel eines potenziellen Vektoren ist ein Seite-Suchmotor: Wenn man nach einer Schnur sucht, wird die Suchschnur normalerweise wortwörtlich auf der Ergebnis-Seite wiedergezeigt, um anzuzeigen, wonach gesucht wurde. Wenn diese Antwort nicht richtig flüchtet oder HTML-Kontrollcharaktere zurückweist, wird eine Quer-Seite scripting Fehler folgen.

Ein widerspiegelter Angriff wird normalerweise über die E-Mail oder eine neutrale Website geliefert. Der Köder ist eine unschuldig aussehende URL-ADRESSE, zu einer vertrauten Seite hinweisend, aber den XSS Vektoren enthaltend. Wenn die vertraute Seite für den Vektoren verwundbar ist, kann das Klicken auf die Verbindung den Browser des Opfers veranlassen, die eingespritzte Schrift durchzuführen.

Beharrlich

Das beharrliche (oder versorgt) XSS Verwundbarkeit ist eine verheerendere Variante einer Quer-Seite scripting Fehler: Es kommt vor, wenn die vom Angreifer zur Verfügung gestellten Daten durch den Server gespart, und dann dauerhaft auf "normalen" Seiten gezeigt werden, die anderen Benutzern im Laufe des regelmäßigen Durchsuchens ohne das richtige HTML-Entgehen zurückgegeben sind. Ein klassisches Beispiel davon ist mit Online-Anschlagbrettern, wo Benutzern erlaubt wird dahinzueilen, hat HTML Nachrichten für andere Benutzer formatiert, um zu lesen.

Nehmen Sie zum Beispiel an, dass es eine datierende Website gibt, wo Mitglieder die Profile anderer Mitglieder scannen, um zu sehen, ob sie interessant aussehen. Aus Gemütlichkeitsgründen verbirgt diese Seite jedermanns echten Namen und E-Mail. Diese werden heimlich auf dem Server behalten. Die einzige Zeit ein echter Name und E-Mail eines Mitgliedes sind im Browser, ist, wenn das Mitglied in unterzeichnet wird, und sie von niemandem anderen nicht sehen können.

Nehmen Sie an, dass sich Mallory, ein Hacker, der Seite anschließt und die echten Namen der Männer ausrechnen will, die sie auf der Seite sieht. Um so zu tun, schreibt sie eine Schrift, die von den Browsern von Männern läuft, wenn sie ihr Profil besuchen. Die Schrift sendet dann eine schnelle Nachricht an ihren eigenen Server, der diese Information sammelt.

Um zu tun, beschreibt das, für die Frage "Ihr Ideales Erstes Datum" gibt Mallory eine kurze Antwort (um normal zu scheinen), aber der Text am Ende ihrer Antwort ist ihre Schrift, um Namen und E-Mails zu stehlen. Wenn die Schrift innerhalb <script&gt eingeschlossen wird; Element, es wird auf dem Schirm nicht gezeigt. Dann nehmen Sie an, dass Bob, ein Mitglied der datierenden Seite, das Profil von Mallory erreicht, das ihre Antwort auf die Erste Datum-Frage hat. Ihre Schrift wird automatisch durch den Browser geführt und stiehlt eine Kopie von Bobs echtem Namen und E-Mail direkt von seiner eigenen Maschine.

Beharrlicher XSS kann bedeutender sein als andere Typen, weil eine böswillige Schrift eines Angreifers automatisch ohne das Bedürfnis gemacht wird, Opfer individuell ins Visier zu nehmen oder sie zu einer Drittwebsite zu locken. Besonders im Fall von sozialen Netzwerkanschlussseiten würde der Code weiter entworfen, um sich über Rechnungen selbstfortzupflanzen, einen Typ eines Kundenseite-Wurmes schaffend.

Die Methoden der Einspritzung können sich viel ändern; in einigen Fällen muss der Angreifer nicht eventuell sogar mit der Webfunktionalität selbst direkt aufeinander wirken, um solch ein Loch auszunutzen. Irgendwelche Daten, die durch die Webanwendung (über die E-Mail, System-Loge, usw.) erhalten sind, der von einem Angreifer kontrolliert werden kann, konnten ein Spritzenvektor werden.

Traditionell gegen die DOM-basierte Verwundbarkeit

Traditionell würde Quer-Seite scripting Verwundbarkeit im Code der Server-Seite vorkommen, der dafür verantwortlich ist, die dem Benutzer zu dienende HTML-Antwort vorzubereiten. Mit dem Advent des Webs 2.0 Anwendungen ist eine neue Klasse von XSS-Fehlern erschienen: DOM-basierte Verwundbarkeit. DOM-basierte Verwundbarkeit kommt in den zufriedenen in einer Prozession gehenden Stufen vor, die vom Kunden, normalerweise in der Kundenseite JavaScript durchgeführt sind. Der Name bezieht sich auf das Standardmodell, um HTML oder XML Inhalt zu vertreten, der Document Object Model (DOM) genannt wird. Programme von JavaScript manipulieren den Staat einer Webseite und bevölkern ihn mit dynamisch geschätzten Daten in erster Linie durch das Handeln nach dem DOM.

Ein typisches Beispiel ist ein Stück von JavaScript zugreifende und herausziehende Daten von der URL-ADRESSE über den DOM oder Empfang roher Nichthtml-Daten vom Server über XMLHttpRequest und dann des Verwendens dieser Information, um dynamisches HTML ohne das richtige Entgehen völlig auf der Kundenseite zu schreiben.

Großtat-Beispiele

Angreifer, die vorhaben, Quer-Seite scripting Verwundbarkeit auszunutzen, müssen sich jeder Klasse der Verwundbarkeit verschieden nähern. Für jede Klasse wird ein spezifischer Angriffsvektor hier beschrieben. Die Namen sind unten Fachbegriffe, die vom Wurf von in der Computersicherheit allgemein verwendeten Charakteren genommen sind.

Nichtbeharrlich:

1. Alice besucht häufig eine besondere Website, die von Bob veranstaltet wird. Bobs Website erlaubt Alice, in mit einem Paar des Benutzernamens/Kennwortes zu loggen, und versorgt empfindliche Daten wie sich schnäbelnde Information.
2. Mallory bemerkt, dass Bobs Website eine widerspiegelte XSS Verwundbarkeit enthält.
3. Mallory fertigt eine URL-ADRESSE, um die Verwundbarkeit auszunutzen, und sendet Alice eine E-Mail, sie lockend, auf eine Verbindung für die URL-ADRESSE unter falschen Vorwänden zu klicken. Diese URL-ADRESSE wird zu Bobs Website (entweder direkt oder durch einen iframe oder ajax) hinweisen, aber wird den böswilligen Code von Mallory enthalten, den die Website widerspiegeln wird.
4. Alice besucht die von Mallory zur Verfügung gestellte URL-ADRESSE, während geloggt, in Bobs Website.
5. Die böswillige in der URL-ADRESSE eingebettete Schrift führt im Browser von Alice durch, als ob es direkt aus Bobs Server gekommen ist (das ist die wirkliche XSS Verwundbarkeit). Die Schrift kann verwendet werden, um das Sitzungsplätzchen von Alice Mallory zu senden. Mallory kann dann das Sitzungsplätzchen verwenden, um empfindliche Information zu stehlen, die für Alice (Beglaubigungsausweis verfügbar ist, Info usw. in Rechnung stellend), ohne die Kenntnisse von Alice.

Beharrlicher Angriff:

1. Mallory sendet eine Mitteilung mit der böswilligen Nutzlast zu einem sozialen Netz ab.
2. Wenn Bob die Nachricht liest, stiehlt der XSS von Mallory Bobs Plätzchen.
3. Mallory kann jetzt Bobs Sitzung entführen und Bob imitieren.

Fachwerk:

Das Browser-Ausnutzungsfachwerk konnte verwendet werden, um die Website und die lokale Umgebung des Benutzers anzugreifen.

Das Reduzieren der Drohung

Die Kontextproduktionsverschlüsselung/Entgehen der Schnur eingegeben

Der primäre Abwehrmechanismus, XSS aufzuhören, ist Kontextproduktionsverschlüsselung/Entgehen. Es gibt mehrere verschiedene flüchtende Schemas, die je nachdem verwendet werden müssen, wohin die unvertraute Schnur innerhalb eines HTML-Dokumentes einschließlich HTML-Entitätsverschlüsselung, des Entgehens von JavaScript, des CSS Entgehens und der URL-ADRESSE (oder Prozent) Verschlüsselung gelegt werden muss. Die meisten Webanwendungen, die reiche Daten nicht zu akzeptieren brauchen, können das Entgehen verwenden, um die Gefahr von XSS auf eine ziemlich aufrichtige Weise größtenteils zu beseitigen.

Es lohnt sich zu bemerken, dass, obwohl es weit empfohlen wird, einfach HTML-Entitätsverschlüsselung auf den fünf XML bedeutenden Charakteren durchführend, nicht immer genügend ist, viele Formen von XSS zu verhindern. Verschlüsselung kann heikel sein, und der Gebrauch einer Sicherheitsverschlüsselungsbibliothek wird hoch empfohlen.

Sicher gültig machendes unvertrautes HTML eingegeben

Viele Maschinenbediener von besonderen Webanwendungen (z.B Foren und webmail) möchten Benutzern erlauben, etwas vom Eigenschaft-HTML zu verwerten, stellt wie eine beschränkte Teilmenge der HTML-Preiserhöhung zur Verfügung. Wenn das Annehmen des HTML-Eingangs von Benutzern (sagt), wird Produktionsverschlüsselung (solcher als) nicht genügen, seitdem der Benutzer Bedürfnisse eingegeben hat, als HTML durch den Browser gemacht zu werden (so zeigt es sich als "sehr groß", statt "<b>very</b> groß"). Das Aufhören von XSS, wenn es HTML-Eingang von Benutzern akzeptiert, ist in dieser Situation viel komplizierter. Unvertrauter HTML-Eingang muss ein HTML-Politikmotor durchbohrt werden, um sicherzustellen, dass er XSS nicht enthält. HTML sanitization Werkzeuge wie OWASP AntiSamy und vollbringt http://htmlpurifier.org/ diese Aufgabe.

Plätzchen-Sicherheit

Außer der zufriedenen Entstörung werden andere unvollständige Methoden für die Quer-Seite scripting Milderung auch allgemein verwendet. Ein Beispiel ist der Gebrauch von zusätzlichen Sicherheitssteuerungen, wenn es Plätzchen-basierte Benutzerbeglaubigung behandelt. Viele Webanwendungen verlassen sich auf Sitzungsplätzchen für die Beglaubigung zwischen individuellen HTTP-Bitten, und weil Kundenseite-Schriften allgemein Zugang zu diesen Plätzchen haben, können einfache XSS-Großtaten diese Plätzchen stehlen. Um diese besondere Drohung (obwohl nicht das XSS Problem im Allgemeinen) zu lindern, binden viele Webanwendungen Sitzungsplätzchen an die IP Adresse des Benutzers, der ursprünglich in geloggt hat, und erlauben Sie nur dass IP, dieses Plätzchen zu verwenden. Das ist in den meisten Situationen wirksam (wenn ein Angreifer nur nach dem Plätzchen ist), aber bricht offensichtlich in Situationen zusammen, wo ein Angreifer Veralberungen ihre IP-Adresse, hinter demselben NATed IP Adresse oder Webvertretung ist — oder sich einfach dafür entscheidet, an der Seite oder den Diebstahl-Daten durch die eingespritzte Schrift herumzubasteln, anstatt zu versuchen, das Plätzchen für den zukünftigen Gebrauch zu entführen.

Eine andere Milderungsgegenwart in D. H. (seit der Version 6), Firefox (seit der Version 2.0.0.5), Safari (seit der Version 4), Oper (seit der Version 9.5) und Google Chrom, ist eine Fahne von HttpOnly, die einem Webserver erlaubt, ein Plätzchen zu setzen, das zu Kundenseite-Schriften nicht verfügbar ist. Während vorteilhaft, verhindert die Eigenschaft Plätzchen-Diebstahl nicht völlig, noch es kann Angriffe innerhalb des Browsers verhindern.

Das Deaktivieren von Schriften

Schließlich, während Web 2.0 und Entwerfer von Ajax den Gebrauch von JavaScript bevorzugt, werden einige Webanwendungen dem geschrieben (manchmal fakultativ) funktionieren völlig ohne das Bedürfnis nach Kundenseite-Schriften. Das erlaubt Benutzern, wenn sie wählen, um scripting in ihren Browsern vor dem Verwenden der Anwendung unbrauchbar zu machen. Auf diese Weise konnten sogar potenziell böswillige Kundenseite-Schriften unentkommen auf einer Seite eingefügt werden, und Benutzer würden gegen XSS-Angriffe nicht empfindlich sein.

Einige Browser oder Browser plugins können konfiguriert werden, um Kundenseite-Schriften auf einer Basis pro Gebiet unbrauchbar zu machen. Wenn scripting standardmäßig erlaubt wird, dann ist diese Annäherung des beschränkten Werts, da es schlechte Seiten nur blockiert, nachdem der Benutzer weiß, dass sie schlecht sind, der zu spät ist. Funktionalität, die den ganzen scripting und Außeneinschließungen standardmäßig blockiert und dann dem Benutzer erlaubt, ihn auf einer Basis pro Gebiet zu ermöglichen, ist wirksamer. Das ist seit langem in D. H. (seit der Version 4) durch die Aufstellung seiner so genannten "Sicherheit Zonen", und in der Oper (seit der Version 9) das Verwenden seiner "Seite Spezifische Einstellungen" möglich gewesen. Eine Lösung für Firefox und andere Gecko-basierte Browser ist die offene Quelle Erweiterung von NoScript, die, zusätzlich zur Fähigkeit, Schriften auf einer Basis pro Gebiet zu ermöglichen, etwas anti-XSS Schutz zur Verfügung stellt, selbst wenn Schriften ermöglicht werden.

Das bedeutendste Problem mit dem Blockieren aller Schriften auf allen Websites ist standardmäßig die wesentliche Verminderung der Funktionalität, und Ansprechbarkeit (Kundenseite kann scripting viel schneller sein als Server-Seite scripting, weil es zu einem entfernten Server und der Seite nicht in Verbindung zu stehen braucht oder Rahmen nicht umgeladen zu werden braucht). Ein anderes Problem mit dem Schrift-Blockieren besteht darin, dass viele Benutzer es nicht verstehen und nicht wissen, wie man ihre Browser richtig sichert. Und doch besteht ein anderer Nachteil darin, dass viele Seiten ohne Kundenseite scripting nicht arbeiten, Benutzer zwingend, Schutz für diese Seite unbrauchbar zu machen und ihre Systeme zur Verwundbarkeit öffnend. Die Firefox Erweiterung von NoScript ermöglicht Benutzern, Schriften auswählend von einer gegebenen Seite zu erlauben, während sie andere auf derselben Seite zurückweist. Zum Beispiel konnte Schriften davon example.com erlaubt werden, während Schriften aus advertisingagency.com, die versuchen, auf derselben Seite zu laufen, zurückgewiesen werden konnten.

Erscheinende Verteidigungstechnologien

Es gibt drei Klassen der XSS Verteidigung, die erscheinen. Diese, schließen die Zufriedene Sicherheitspolitik von Mozilla, Javascript Sandkasten-Werkzeuge und Autoflüchtende Schablonen ein. Diese Mechanismen entwickeln noch, aber versprechen eine Zukunft schwer reduzierten XSS.

Abtastung des Dienstes

Einige Gesellschaften bieten einen periodischen Ansehen-Dienst an, im Wesentlichen einen Angriff von ihrem Server bis einen Kunden vortäuschend, um zu überprüfen, ob der Angriff erfolgreich ist. Wenn der Angriff erfolgreich ist, erhält der Kunde ausführlich berichtete Information darüber, wie es durchgeführt wurde und so eine Chance hat, die Probleme zu befestigen, bevor derselbe Angriff von jemandem anderem versucht wird. Ein Vertrauenssiegel kann auf der Seite gezeigt werden, die ein neues Ansehen passiert. Der Scanner kann die ganze mögliche Verwundbarkeit nicht finden, und deshalb können Seiten mit Vertrauenssiegeln noch für neue Typen des Angriffs verwundbar sein, aber das Ansehen kann einige Probleme entdecken. Nachdem der Kunde sie befestigt, ist die Seite sicherer, als sie den Dienst vorher verwendete. Für Seiten, die ganze Milderung von XSS verlangen, sind Bewertungstechniken wie manuelle Coderezension notwendig. Zusätzlich, wenn javascript auf der Seite durchführt, kann das Siegel mit einer statischen Kopie des Siegels überschrieben werden.

Zusammenhängende Verwundbarkeit

In der Universalen Bösen Seite Scripting (UXSS oder Universaler XSS) wird die Verwundbarkeit im Browser, aber nicht in anderen Websites in XSS ausgenutzt.

Mehrere Klassen der Verwundbarkeit oder Angriffstechniken sind mit XSS verbunden: Quer-Zone scripting Großtaten "Zonen"-Konzepte in bestimmten Browsern und führt gewöhnlich Code mit einem größeren Vorzug durch. HTTP Kopfball-Einspritzung kann verwendet werden, um Quer-Seite scripting Bedingungen wegen flüchtender Probleme auf dem HTTP-Protokoll-Niveau (zusätzlich zum Ermöglichen von Angriffen wie das HTTP-Ansprechaufspalten) zu schaffen.

Quer-Seite-Bitte-Fälschung (CSRF/XSRF) ist fast das Gegenteil von XSS, darin, anstatt das Vertrauen des Benutzers auf eine Seite auszunutzen, der Angreifer (und seine böswillige Seite) nutzt das Vertrauen der Seite auf die Kundensoftware aus, Bitten vorlegend, dass die Seite glaubt, vertreten bewusste und absichtliche Handlungen von beglaubigten Benutzern.

XSS Verwundbarkeit (sogar in anderen Anwendungen, die auf demselben Gebiet laufen), erlaubt Angreifern, Quer-Seite-Bitte-Fälschung (CSRF/XSRF) Verhinderungen zu umgehen.

Letzt nutzt SQL Einspritzung eine Verwundbarkeit in der Datenbankschicht einer Anwendung aus. Als Benutzer eingegeben hat, wird falsch gefiltert irgendwelche SQL Behauptungen können durch die Anwendung durchgeführt werden.

Referenzen

Siehe auch

• Internetsicherheit
• Browser-Sicherheit
• Dieselbe Ursprung-Politik
• Metasploit Projekt, ein Durchdringen-Probewerkzeug der offenen Quelle, das Tests auf XSS einschließt
• w3af, ein Webanwendungssicherheitsscanner der offenen Quelle
• NoScript und NotScripts, freie Erweiterungen der offenen Quelle für Mozilla Firefox und Google Chrome (beziehungsweise), die Ausführung von Schriften blockieren
• XSSer: Automatisch - Fachwerk, um zu entdecken, nutzen Sie aus und melden Sie XSS Verwundbarkeit
• Quer-Dokumentennachrichtenübermittlung

Links

• BUGTRAQ-VERWUNDBARER SEITE-SPURENLESER (CSS Verwundbarkeit)
• Sicherheit von WhiteHat － Vulnerabilties Weißbuch
• OWASP: XSS, für XSS prüfend, Code für XSS nachprüfend
• XSSed: Datenbank von Websites, die verwundbar sind, um Angriffe von Scripting quer-zulegen
• Einfache XSS Erklärung
• Die Webanwendungssicherheit die Quer-Seite des Konsortiums Scripting Drohungsklassifikationszugang
• Blitz-Zeichentrickfilm der Quer-Seite Scripting Angriff
• BreakTheSecurity - das Umleiten der XSS Filter
• Der XSS Filter für Java hat Webanwendungen gestützt