Firefox del> (behoben in Nightly 59.0a1), Safari del> (behoben in Safari Technology Preview 54), Edge und Internet Explorer zeigen ein Authentifizierungsdialogfeld an, wenn Sie ein Bild anfordern und der Server fordert Sie auf, sich mit der HTTP Basic-Authentifizierung zu authentifizieren. Auf diese Weise kann ein Angreifer einen Authentifizierungsdialog anzeigen, wenn der Browser eines Benutzers versucht, das Bild zu laden:

• Firefox . Ab Nightly 59.0a1 behoben, aber die Warnung in der neuesten stabilen Version:

  

• Safari . Ab Safari Technology Preview 54 behoben, aber das Modal ist in der neuesten stabilen Version noch vorhanden. Beachten Sie, dass es sich um einen modalen Dialog handelt und der Rest der Website ausgegraut ist. "Ihre Anmeldeinformationen werden sicher gesendet" ist auch technisch zutreffend, kann jedoch einem unachtsamen Benutzer den falschen Eindruck vermitteln:

  

• IE11 . Ein natives Windows-Dialogfeld sperrt den gesamten Browser:

  

Wenn Sie den Bereich erstellen eine wirklich lange Zeichenfolge von a \ ta \ ta \ t ... a \ t , IE11 wird vollständig gesperrt.

Ein gut gewählter Domainname und Bereich kann Benutzer dazu verleiten, ihre Benutzernamen und Passwörter an den Server eines Angreifers zu senden, oder Ihre Website vollständig unzugänglich machen.

Wie Anders sagt: Blender macht einen sehr guten Punkt in Bezug auf Authentifizierungsdialoge, und multithr3at3d hat Recht mit den on-Attributen. Darüber hinaus fügt Anders Argumente über das a -Tag hinzu und Matija hat einen guten Link zum Ausnutzen von Bibliotheken, die das Rendern ausführen.

Dennoch niemand Ich habe bereits über SVG gesprochen.

Nehmen wir zunächst an, dass alle Ein- und Ausgaben ordnungsgemäß bereinigt sind, sodass Tricks mit onerror / onload möglich sind nicht möglich. Und dass wir nicht an CSRF interessiert sind. Wir sind hinter XSS her.

Das erste Problem mit <img src = ist, dass es nicht der gleichen Ursprungsrichtlinie folgt. Aber das ist wahrscheinlich weniger gefährlich als es sich anhört.

Was der Browser tut, um ein < img >-Tag zu rendern

< img src = "http: // domain / image .png "> ist ziemlich sicher, da der Browser keinen Parser (z. B. einen XML- oder HTML-Parser) aufruft und weiß, dass ein Bild (gif, jpeg, png) kommt.

Der Browser führt die HTTP-Anforderung aus und liest einfach die MIME des Eingangs (im Header Conetent-Type , z. B. image / png ). Wenn die Antwort keinen Inhaltstyp enthält, erraten mehrere Browser basierend auf der Erweiterung, raten jedoch nur Bild-MIMEs: image / jpeg , image / png oder image / gif (tiff, bmp und ppm sind zweifelhaft, einige Browser unterstützen sie möglicherweise nur eingeschränkt). Einige Browser versuchen möglicherweise sogar, das Bildformat anhand magischer Zahlen zu erraten, versuchen jedoch nicht, esoterische Formate zu erraten.

Wenn der Browser mit dem (möglicherweise erratenen) MIME übereinstimmen kann, wird das richtige Rendering geladen Bibliothek, Rendering-Bibliotheken können einen Überlauf haben, aber das ist eine andere Geschichte. Wenn das MIME nicht mit einer Bildwiedergabebibliothek übereinstimmt, wird das Bild verworfen. Wenn der Aufruf der Rendering-Bibliothek fehlschlägt, wird das Bild ebenfalls verworfen.

Der Browser befindet sich niemals in der Nähe eines Ausführungskontexts (Skriptkontexts). Die meisten Browser geben den Ausführungskontext nur über den Javascript-Parser ein und können den Javascript-Parser nur über die -Anwendung / Javascript MIME oder über den XML- oder HTML-Parser erreichen (da sie möglicherweise eingebettete Skripte haben).

Um XSS auszuführen, benötigen wir einen Ausführungskontext. Gibt SVG ein.

Verwenden von < img src = "domain / blah / blah / tricky.svg" >

Autsch, autsch autsch. SVG ist ein XML-basiertes Vektorgrafikformat und ruft daher den XML-Parser im Browser auf. Darüber hinaus hat SVG das <script> -Tag! Ja, Sie können Javascript direkt in SVG einbetten.

Dies ist nicht so gefährlich, wie es zunächst klingt. Browser, die SVG in <img> -Tags unterstützen, unterstützen keine Skripterstellung im Kontext. Idealerweise sollten Sie SVG in <embed> oder <object> -Tags verwenden, bei denen die Skripterstellung von Browsern unterstützt wird. Tun Sie dies jedoch nicht für vom Benutzer bereitgestellte Inhalte!

Ich würde argumentieren, dass das Zulassen von SVG in <img src = gefährlich sein kann:

• Ein XML-Parser wird verwendet, um die SVG zu analysieren, unabhängig davon, ob sie sich im Tag <img> oder <object> befindet. Der Parser ist sicherlich mit einigen Parametern optimiert, um <script> -Tags im <img> -Kontext zu ignorieren. Das ist jedoch ziemlich hässlich, da ein Tag in einem bestimmten Kontext auf die schwarze Liste gesetzt wird. Und Blacklisting ist eine schlechte Sicherheit.

• <script> ist nicht der einzige Weg, um einen Ausführungskontext in SVG zu erreichen, es gibt auch den onmouseover (und Familien-) Ereignisse in SVG. Dies ist wiederum schwierig auf die schwarze Liste zu setzen.

• Der XML-Parser in Browsern hatte in der Vergangenheit Probleme, insbesondere bei XML-Kommentaren zu Skriptblöcken. SVG kann ähnliche Probleme aufweisen.

• SVG unterstützt XML-Namespaces vollständig. Wieder Autsch. xlink: href ist ein vollständig gültiges Konstrukt in SVG und der Browser im XML-Parser-Kontext wird ihm wahrscheinlich folgen.

Ja, SVG wird geöffnet mehrere mögliche Vektoren, um einen Ausführungskontext zu erreichen. Darüber hinaus ist es eine relativ neue Technologie und daher nicht gut gehärtet. Es würde mich nicht wundern, CVEs zur SVG-Handhabung zu sehen. Zum Beispiel hatte ImageMagick Probleme mit SVG.

<img src = http: //evil.com ist kein allzu großes Problem, aber <img src = ein Fehler = 'XSS') > kann verwendet werden, um beliebiges JavaScript einzufügen. Tatsächlich kann jedes HTML-Tag in Kombination mit einem "on" -Ereignisattribut (z. B. onerror, onclick, ontouchstart usw.) verwendet werden, um uneingeschränkte JavaScript-Nutzdaten auszuführen.

Okay, wie wäre es damit: (Sie sollten wahrscheinlich zurücktreten.)

  <img src = "file: //uhoh.gif" >  

Oh, ich weiß, richtig? Was für ein Monster!

Nun, es könnte sein, wenn Sie SMB verwenden ...

Es ist ein Fehler, der seit 18 Jahren besteht! dieser Schwachstellenbericht aus dem Jahr 1997. Hier ist dieselbe Schwachstelle bei BlackHat im Jahr 2015.

Dies betrifft Internet Explorer, einschließlich Microsoft Edge. Dies sollte der Fall sein Beachten Sie, dass dies keine Auswirkungen auf Chrome- oder Mozilla-Browser hat. Der IE versucht, sich automatisch bei der Website des Angreifers zu authentifizieren, indem er den Benutzernamen und das gehashte NTLM-Kennwort an den Remote-Server weiterleitet, und zwar sogar über das Internet (!!).

Ich komme daher zu dem Schluss, dass absolut niemand jemals ein IMG-Tag verwenden sollte.

Ja, aber ist es XSS? Nein, es startet nicht unbedingt einen XSS-Angriff oder stellt einen solchen dar, den ich kenne. Obwohl es von einem gestartet werden kann, ist es keine Voraussetzung. Zählt netzwerkübergreifend?

Ich denke, mit "img XSS" meinen Sie "Site, die beliebige Werte für das Attribut src =" " von <img / > -Elementen zulässt.

... in diesem Fall besteht das Hauptrisiko der Cross Site Request Forgery (CSRF), da ein Angreifer ein Ziel dazu bringen kann, eine willkürliche GET -Anforderung zu stellen, wobei das kanonische Beispiel "schlecht" ist -codierte Bank-Website macht Geldtransfers mit GET -Anfragen "-Vulnerability.

Es muss sich jedoch nicht unbedingt um eine Cross Site -Anforderungsfälschung handeln - I. Stellen Sie sich vor, der Haupttyp der Website, der vom Benutzer bereitgestellte <img / > -Elemente ermöglicht, ist ein Webforum - und Webforen haben in der Regel Administrator-Kontrollfelder auf derselben Website - wenn also "nützlich" Administrator- oder Moderatoraktionen könnten über GET aufgerufen werden, dann ist dies eine andere Möglichkeit - dies fällt jedoch immer noch unter das CSRF-Dach.

Die Antwort des D weist darauf hin, dass ein GET verwendet werden kann, um Befehle sowohl für cross Site als auch auf derselben auszugeben em> site. Ich möchte diesen Begriff erweitern, da die Aussage "Es ist eine GET -Anforderung - seien Sie vorsichtig" normalerweise nicht dazu beiträgt, warum das ein Problem sein könnte.

Ein Angriff, der ausgeführt werden kann, den andere Antworten nicht abgedeckt haben, ist Denial-of-Service. Beachten Sie Folgendes:

Sie befinden sich in einem Forum und jemand veröffentlicht eine Nachricht mit einem eingebetteten <img src = "/ logout" / > - dies führt zu jedem wird abgemeldet, wenn das Bild geladen wird. Jetzt kann keiner der Benutzer das Forum verwenden, solange er diese Seite sieht.

Dies ist ein relativ triviales Beispiel, aber dennoch ein potenzielles Problem. Um zu zeigen, wie problematisch es sein könnte, stellen Sie sich vor, es handelt sich um eine Nachrichtenseite oder eine andere, auf der Benutzerkommentare auf der Hauptseite angezeigt werden. Nach der Anmeldung werden Sie dorthin weitergeleitet. Jetzt kann sich niemand mehr anmelden, ohne sofort abgemeldet zu sein.

Bisher handelt es sich nicht um Cross-Site-Angriffe. Sie können jedoch relativ einfach in diese umgewandelt werden - stellen Sie sich vor, Facebook oder eine andere beliebte Website lassen eine beliebige Quelle für Bilder zu und Sie veröffentlichen den folgenden <img src = "http://yourdomain.com/logout" / > - Personen werden abgemeldet, ohne dass sie sich auf yourdomain.com befinden müssen. Dies kann von ärgerlich ("Ugh, die Website fragt nach meinem Passwort erneut ") bis zu potenziell problematisch ("Warten Sie, wo sind all meine nicht gespeicherten Arbeiten geblieben?") Reichen.

Es ist durchaus möglich, dass das Bild nicht einmal abgemeldet wird - was ist, wenn es http://yourdomain.com/deleteMyUser ist, das Benutzer dazu bringt, die Website ohne ihre Zustimmung zu "verlassen"? Oder vielleicht der plausibelere http://yourdomain.com/findPrimes?count=9001 , der Ihren Server möglicherweise überlastet, um umfangreiche Berechnungen durchzuführen?

Was mich an dieser Art von Angriff am meisten irritiert, ist, dass es nicht einmal ein Problem mit img -Tags selbst gibt - selbst wenn Ihre Webanwendung mit Bildern vorsichtig ist, die eines anderen möglicherweise nicht. Der Kern des Problems besteht darin, dass der Abmeldelink (oder eine beliebige Ressource, die ein Angreifer ausnutzt) einfach über GET aufgerufen werden kann und das Bild lediglich ein Vektor ist, damit Browser diesen GET code ausgeben >. Das Problem ist, dass es für viele Entwickler nicht offensichtlich ist, dass dies der Fall ist.

Zusätzlich zu allen anderen bereits erwähnten Antworten kann das Bild selbst absichtlich so geändert werden, dass das Parsen den Benutzercomputer ausnutzt und somit die Remotecodeausführung ermöglicht. Siehe Kann das einfache Dekomprimieren eines JPEG-Bildes einen Exploit auslösen?

Blender macht einen sehr guten Punkt in Bezug auf Authentifizierungsdialoge, und korockinout13 hat Recht mit den Attributen on . Ich habe jedoch einen Zusatz.

In einigen Situationen können Sie die Steuerung von Bildern verwenden, um das Layout der Seite zu ändern und Teile der Seite zu fälschen. Es ist nicht sehr leistungsfähig, da ich nichts Dynamisches tun kann, aber es kann manchmal auf clevere Weise verwendet werden.

Zum Beispiel, wenn ich ein img -Tag in das Tag einfügen kann Suchergebnisseite Wenn ich nach einem suche, könnte ich ein Bild mit gefälschten Suchergebnissen darin haben. Auf diese Weise könnte es so aussehen, als würde eine Suche nach "UFO" in den lokalen Nachrichten Geschichten über die großartige Alienlandung von 2016 zurückgeben.

Wenn sich die Sicherheitsanfälligkeit in einem a -Tag befindet Wenn dies eine Aktion ausführt, könnte ich ein Bild einfügen, das andere Teile der Seite nachahmt. Auf diese Weise klickt der Benutzer, wenn er auf "OK" klickt, tatsächlich auf mein Bild, das eine Darstellung einer gefälschten Schaltfläche "OK" enthält, aber tatsächlich Teil des Links "Löschen" ist.

Wenn ich kann Wenn Sie meine eigenen Links mit Bildern erstellen, wird dies noch besser ...

Wie gesagt, nicht der mächtigste Hack der Welt, aber Grund genug, Bilder nicht dort zuzulassen, wo sie nicht benötigt werden.