Früher gab es eine "Sicherheitsanfälligkeit", bei der das Image eine HTTP 401 Unauthenticated -Antwort senden konnte, die einen Anmeldebildschirm für den Benutzer auslöste. Wenn Sie dies als Forum-Avatar festlegen, wird ein Anmelde-Popup für jeden angezeigt, der eine Seite besucht, auf der Ihr Avatar angezeigt wird. Viele Leute werden dann versuchen, sich mit einer Kombination aus Benutzername und Passwort anzumelden, wahrscheinlich die für ihr Forum-Konto.

Ein Freund von mir hat dies vor einigen Jahren gefunden, aber heutzutage scheint es nicht so zu sein mehr arbeiten. Zumindest konnte ich es vor ein paar Monaten nicht einfach reproduzieren. Bearbeiten: Ich habe mich geirrt, dieser Angriff ist immer noch möglich! / edit

Bei XSS-Angriffen auf diese Weise sind Sie sicher. Der Browser wird oder sollte dies immer als Bild interpretieren, unabhängig davon, was es enthält oder welche Header er sendet. Sie können das Bild basierend auf der Anforderung anpassen (indem Sie der Forensoftware ein kleines Bild bereitstellen, indem Sie das Bild vorab überprüfen, damit es nicht verkleinert wird, und dann für alle anderen groß). Oder füttere den Browser mit vielen GIF-Daten, bis der Speicher knapp wird oder so. Soweit ich weiß, gibt es hier jedoch keine wirklich großen Sicherheitslücken, die die Ausführung von Remotecode ermöglichen.

Für was Sie nur mäßig sicher sind, sind CSRF-Angriffe. Das Bild kann eine HTTP 302 Temporär verschoben -Antwort ausgeben und eine Verknüpfung zu einem neuen Speicherort herstellen. Zum Beispiel könnte es auf eine bestimmte URL wie https://accounts.google.com/logout verweisen und Sie von Google abmelden (dies hat vor einigen Monaten funktioniert). . Oder etwas böswilliger: http://example.com/guestbook.php?action=post&message=spam-url.example.com .

Es können nur GET-Anforderungen ausgeführt werden so weit ich weiß. Oder wenn das Bild ursprünglich als POST-Anfrage geladen wurde, könnte es vermutlich auch den POST umleiten, aber die POST-Daten nicht ändern. Das ist also ziemlich sicher.

Last but not least können Informationen von Besuchern wie z. B. deren IP-Adresse abgerufen werden, wenn der Angreifer URLs von beispielsweise Forum-Avataren (z. B. in SMF-Foren) kontrolliert. Ich habe vor einiger Zeit ein Tool geschrieben, das die Seite action = who von SMF verwendet, um IP-Adressen mit Benutzernamen zu verknüpfen. Als ich anfing, dies den Benutzern anzuzeigen (siehe "Hallo $ Benutzername mit IP: $ IP" im Bild), brach die Hölle los. "Wie kannst du das wissen?!" Sie waren meistens Technikfreaks im frühen bis mittleren Teenageralter, also wussten sie, was eine IP-Adresse war, aber sie wussten nicht, dass ich sie damit nicht hacken konnte . Es wird jedoch zumindest in den Niederlanden als persönlich identifizierbare Information angesehen, so dass die Administratoren über diese Praxis nicht ganz glücklich waren. Wenn Sie es jedoch nicht anzeigen, wird es niemand erfahren.

Hinweis: Wenn dieser Beitrag hastig geschrieben erscheint, ist dies der Fall. Ich bin auch kaum wach. Vielleicht räume ich es morgen auf, wenn es zu viel Geschichten erzählt und nicht genug konkrete Fakten und Schwachstellen genannt werden. Hoffe das hat trotzdem geholfen!

Das IMG-Tag versucht, die Daten als Bild zu interpretieren, sodass kein Javascript ausgeführt wird.

Es ist möglich, ein Bild zu senden, das nach der Dekodierung enorm viel Speicher benötigt ("PNG-Bombe"), und es ist möglich, dass die Grafikroutinen selbst für schädliche Inhalte anfällig sind (ein sorgfältig ausgearbeitetes Bild, das beim Dekodieren die Ausführung von eingebettetem Code auslöst). Es gab eine solche Sicherheitslücke vor fast zehn Jahren, und obwohl dies unwahrscheinlich ist, könnte eine andere herausspringen.

UPDATE : Eine andere hat. Und ein anderes, und dieses hat einen CVSS-Wert von 9,3 - " Es gibt einen vollständigen Kompromiss bei der Systemintegrität. Es gibt einen vollständigen Verlust des Systemschutzes, was dazu führt, dass das gesamte System gefährdet wird "

Mit dem Tag HTTP_REFERER kann der Eigentümer der Bildwebsite wissen, welche Seiten besucht wurden, und mithilfe von Tracking-Cookies einige Informationen erhalten Eine Offenlegung ist möglich (z. B. hostet die böswillige Site ein Bild, das von den Sites A, B und C gemeinsam genutzt wird. Der Eigentümer des Bildes kann sehen, dass ein bestimmter Benutzer auf Site A dieselbe Person ist wie ein anderer Benutzer von Site B, da das Image Setzen Sie ein Cookie, wenn es auf Site A verwendet wird, und jetzt kommt dasselbe Cookie von einem Benutzer von Site B) an. Je nach Szenario kann dies unerwünscht sein.

Durch das Einbetten in die Bildteile des Designs der Host-Site kann ein Angreifer den Benutzer dazu verleiten, zu glauben, dass auf der Site Inhalte gehostet werden, die tatsächlich nicht vorhanden sind. Dies erfordert, dass HTML / CSS für eine plötzliche Änderung der Bildgröße anfällig ist. Beispielsweise kann eine Börsen-Site anstelle eines 200 x 80-Banners ein 200 x 600-Banner anzeigen, dessen oberste Zeilen mit dem ursprünglichen Banner identisch sind, und der folgende Teil dient zur Simulation der Börsen-Site und wird über eine Aktie "geschoben" Ticker und reproduziert den gleichen Börsenticker - jedoch mit unterschiedlichen Werten. Ein unachtsamer Benutzer könnte dann dazu verleitet werden, Aktienzahlen zu glauben, die völlig falsch sind. Wenn genügend Benutzer überzeugt sind, kann dies eine Art "Pump and Dump" -Schema ermöglichen.

Eine Variation davon, die Berichten zufolge häufig vorkommt, besteht darin, dass Sie das Bild ohne entsprechende Erlaubnis verknüpfen. Der Websitebesitzer, der die Kosten für das Tragen und Bereitstellen des Bildes an Ihre Betrachter trägt, hat die Möglichkeit, das Bild mit etwas völlig anderem zu wechseln. Dies geschieht manchmal absichtlich im Voraus, dh ein "saftiges" Bild wird in die entsprechenden Foren gesetzt (z. B. ein Brei gegen eine Fußballmannschaft?) Und dann durch etwas mit entgegengesetztem Inhalt ersetzt (dasselbe gilt für die Erzrivalen dieser Mannschaft). . Für zusätzlichen Spaß kann der Trolling-Webmaster die ursprünglichen IP-Adressen aufzeichnen, die das Bild heruntergeladen haben, und weiterhin ihnen das Originalbild senden. Fans von Team A werden also eine Himbeere gegen ihr Team veröffentlichen und nicht verstehen, warum alle lachen - jedes Mal, wenn sie das Bild betrachten, sehen sie, dass es Team B verspottet Dies dient als Warnung: Nehmen Sie nicht an, dass das Bild, das Sie sehen, dasselbe ist, das IHRE BENUTZER sehen .

JavaScript selbst wird nicht ausgeführt, selbst wenn der Remote-Server MIME Inhaltstyp in text / javascript ändert, da die Browser erwartet bereits bestimmte MIME-Typen innerhalb des IMG -Tags. Das bedeutet jedoch nicht, dass sie sicher sind.

Ein Thread, den Sie unbedingt lesen sollten, ist . Ist es sicher, externe Bilder an Blogs oder Webinhalte anzuhängen?. Kurz gesagt, Server, von denen Sie externe Bilder verknüpfen, können weiterhin alle Daten aus der HTTP-Anforderung lesen, die vom Browser des Endbenutzers an sie gesendet wurde (nämlich IP-Adresse der Anforderung, Zeichenfolge des Benutzeragenten, Protokollversion und Nicht-HTTPS-Ursprung Fordern Sie auch andere Anforderungsheader an, darunter die URL-Zeichenfolge referer und natürlich nicht gesicherte HTTP-Cookies.

Der Remote-Server kann auch Bilder dynamisch generieren und möglicherweise andere Anlass zur Sorge geben ( Unangemessener Inhalt, Angst vor Täuschung durch Hinzufügen von Endbenutzeranforderungsinformationen wie IP-Adresse, ...) oder einfach die Benutzeraktivität auf Ihren Servern verfolgen, indem Sie die zuvor beschriebenen HTTP-Anforderungsheader überprüfen oder die Nachverfolgung durch Dritte löschen Cookies mit ihrer Antwort. Die URL-Darstellung in der referer -String von nicht gesicherten HTTP-Anforderungen wird häufig vernachlässigt und kann die Webadressen Ihres Servers offenlegen, die Sie möglicherweise nicht wirklich mögen (CMS-Speicherort, URL-Sitzungsdaten, ...). . Gleiches gilt für nicht sichere Cookies, die nicht auf eine einzelne Domain (Speicherort) beschränkt sind und von Dritten gelesen und sogar überschrieben werden können.

Außerdem kann sich bösartiger Code durch gestaltete Bilder auf verbreiten Client-Systeme, die nicht richtig gepatcht wurden. Einer der bekanntesten Exploits dieser Art war der GDI + -Fehler, der die Ausführung von Remotecode unter nicht gepatchten früheren Windows-Versionen ermöglichen konnte. Es gibt auch andere ähnliche Exploits, von denen einige immer noch nicht auf allen Systemen richtig behandelt werden.

Bei einigen der neuesten Exploits ist das Auslösen von Java-Code (nicht JavaScript) aus einem speziell gestalteten SVG-Bild in einigen Browsern möglich. ^{[1] [2] sup>:}

Exploit-DB - Auslösen von Java-Code aus einem SVG-Image:

SVG ist Ein XML-basiertes Dateiformat für statische oder animierte Bilder. Einige SVG-Spezifikationen (wie SVG 1.1 und SVG Tiny 1.2) ermöglichen das Auslösen von Java-Code, wenn die SVG-Datei geöffnet wird.

und

Metasploit - Squiggle 1.7 SVG-Browser-Java-Code-Ausführung:

Dieses Modul missbraucht die SVG-Unterstützung, um Java-Code im Squiggle-Browser auszuführen, der im Batik-Framework 1.7 über a enthalten ist gestaltete SVG-Datei, die auf eine JAR-Datei verweist. Um eine willkürliche Codeausführung zu erreichen, muss der Browser die folgenden Bedingungen erfüllen: (1) Er muss mindestens SVG Version 1.1 oder neuer unterstützen, (2) Er muss Java-Code unterstützen und (3) Die Prüfung "Sicheres Scripting erzwingen" muss durchgeführt werden deaktiviert sein. Das Modul wurde gegen Windows- und Linux-Plattformen getestet.

Weitere Informationen zu möglichen SVG-Exploits finden Sie unter Exploits oder andere Sicherheitsrisiken beim SVG-Upload? Thread.

Kurz gesagt, es ist nicht zu sicher und hängt wahrscheinlich von Ihrem Vertrauen in die Remote-Server ab, von denen Sie Bilder verknüpfen, um dies nicht auszunutzen.

Ja, Sie sind in Sicherheit.

Natürlich kann die Seite, die Sie erhalten, wenn Sie mit der rechten Maustaste klicken> Bild anzeigen , schädlich sein, aber im Kontext Ihrer Website wird kein Skript ausgeführt.

Vergessen Sie außerdem nicht, dass der Eigentümer der Website des Bildes Ihre Besucher auf allen Seiten verfolgen kann, auf denen das Bild eingebettet ist.

Eine IMG-Anforderung ist eine GET-Anforderung an einen beliebigen Server. Dies kann unsicher sein.

Die Serverantwort kann Cookies löschen oder überschreiben, die den Betrieb Ihres Browsers beeinträchtigen können.

Weitere Informationen

Stackoverflow wurde einmal von diesem Fehler befallen, bei dem auf die REST-API zum Abmelden über eine einfache GET-Anforderung zugegriffen werden konnte.

Ich denke, das Szenario sah folgendermaßen aus:

1. Ein Spammer hat Spam auf einer bestimmten Seite gepostet.
2. Auf dieser Seite wurde ein Get für / users / eingefügt. Abmelden in einem IMG-Tag
3. Die Authentifizierungscookies für den Benutzer wurden über die HTTP-Header entfernt.
4. Jedes Mal, wenn ein Administrator oder Moderator versuchte, den SPAM zu entfernen, wurden sie protokolliert out.
ol>

Dies ist ein Teil des Grundes, warum es eine Abmeldeseite gibt, wenn Sie auf SO auf "abmelden" klicken.

Nebenbei: Obwohl SO eine HTTP-Site (kein "s" / SSL) ist, denke ich, dass sichere Cookies anfällig sind