Kann etwas “Schlimmes” über img src passieren?

Lesezeit: 8 Minuten

Benutzer-Avatar
guten Abend

Ich weiß, ich weiß, der Titel ist ziemlich schlecht, aber ich werde versuchen zu erklären, was ich hier meine. Also bitte ich meine Mitglieder, ihre Fotos zu zeigen. Sie laden es irgendwo hoch, fügen dann die URL ihrer Fotos in die Eingabe ein und ich speichere es in meiner Datenbank (MYSQL). Dann ist das Foto auf ihren Profilen zu sehen. Ich bekomme die URL aus der Datenbank und mache so etwas: <img src="https://stackoverflow.com/questions/3114301/<?=$photo;?>" height="123px" width="123px">"> wo $photo ist eine URL aus MYSQL. Ist es absolut sicher? Kann jemand zum Beispiel eine .php-Datei hochladen und meine Website beschädigen? Muss ich überprüfen, ob die URL-Endung .gif, .png, .jpg ist?
Vielen Dank.

Bearbeiten: Ja, natürlich würde ich meine Website vor SQL-Injections und XSS-Angriffen schützen. Aber gibt es eine Möglichkeit, meiner Website auf andere Weise Schaden zuzufügen?

  • Verwenden Sie vor dem Einfügen in die Datenbank imagemagik, um zu überprüfen, ob das Foto ein echtes Bild ist und nichts anderes, und Sie sollten in Ordnung sein.

    – Byron Whitlock

    24. Juni 2010 um 22:24 Uhr

  • “Ist es absolut sicher?” Es ist völlig unsicher 🙂 Alle Arten von xss-Angriffen sind hier möglich, wenn nicht andere. @Byron Das ist ein guter Weg, vorausgesetzt, dass imagemagick sicher ist, aber wenn es sich nicht um eine Banking-Site handelt, ist dies keine echte Bedrohung.

    – kubal5003

    24. Juni 2010 um 22:26 Uhr


  • <img src="<?=htmlspecialchars($photo);?>" height="123px" width="123px">">. Dies schützt jedoch nicht vor XSRF (z. B. wenn ein Benutzer eine Datei eingibt /logout.php da die Bild-URI wahrscheinlich eine schlechte Sache wäre)

    – Frank Bauer

    25. Juni 2010 um 0:54 Uhr

  • @Byron: Selbst wenn das Bild bei der Skriptprüfung gültig wäre, wäre es trivial, das Foto später beim Bildhost durch etwas Bösartiges zu ersetzen.

    – Markus B

    25. Juni 2010 um 2:23 Uhr

  • @Marc, stimmt. Ich dachte, er würde die Bildquelle in die Datenbank herunterladen und Bytes bedienen.

    – Byron Whitlock

    25. Juni 2010 um 20:39 Uhr

Benutzer-Avatar
pkaeding

Was Sie beschrieben haben, ist möglicherweise anfällig für einen XSS-Angriff (Cross-Site-Scripting). Im Wesentlichen kann ein schändlicher Benutzer in der Lage sein, Javascript-Code einzuschleusen, der schlimme Dinge tun könnte, während er als Ihre Website ausgeführt wird.

Ein Beispiel für diesen Angriffsvektor finden Sie unter: http://jarlsberg.appspot.com/part2#2__stored_xss_via_html_attribute

BEARBEITEN: Es hört sich so an, als ob Sie sich bereits vor SQL-Injektionen und XSS schützen und sich fragen, ob es eine Möglichkeit gibt, wie jemand PHP-Code in Ihre Website einschleusen kann. Ich glaube nicht, dass dies möglich ist, da Ihr serverseitiger Code diese Zeichenfolge nicht ausführt. Sie weisen den Client-Browser einfach an, ein Bild von einer URL herunterzuladen.

Es ist möglich, dass jemand einen Link zu einer Bilddatei erstellt, die mit einem Virus infiziert ist, wodurch andere Besucher Ihrer Website infiziert werden, die Website selbst jedoch nicht beeinträchtigt wird.

  • Es freut mich, dass ich helfen konnte. Wenn Sie der Meinung sind, dass dies Ihre Frage am besten beantwortet, markieren Sie sie bitte als “akzeptiert”, indem Sie auf das Häkchen daneben klicken.

    – pkaeding

    25. Juni 2010 um 0:19 Uhr

Nein, es ist überhaupt nicht sicher, XSS-Angriffe können über Bild-Tags ausgeführt werden.

Ein einfaches Beispiel wäre:

<IMG SRC=j&#X41vascript:alert('test2')>

http://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29

  • Dies setzt voraus, dass Benutzer die Kontrolle darüber haben, wie ihr Image benannt wird, wenn es bereitgestellt wird.

    – Samantha Branham

    24. Juni 2010 um 22:42 Uhr

  • Auf welchen Browsern soll dieses Warnfeld funktionieren? In IE oder Firefox passiert nichts, wenn ich es versuche?

    – Martin Schmidt

    24. Juni 2010 um 22:45 Uhr

  • Schnelles Beispiel hier: jsbin.com/avuda es funktioniert nicht in Firefox, IE 8 oder Chrome

    – Earlz

    24. Juni 2010 um 23:13 Uhr


  • @Stuart: Die Frage besagt, dass der Benutzer einen URI und keine Datei bereitstellt, sodass er die vollständige Kontrolle hat.

    – QUentin

    24. Juni 2010 um 23:14 Uhr

  • @Martin: Neuere Versionen der meisten Browser lehnen Javascript-URIs für Bilder jetzt ausdrücklich ab – es gibt jedoch immer noch anfällige.

    – QUentin

    24. Juni 2010 um 23:15 Uhr

Eines solltest du beachten – ich könnte dir mein “XUltra highres” Bild mit ca. 200 MB verlinken. Ich denke, dies könnte das Ladeerlebnis Ihrer Website beeinträchtigen (je nach Design). Neben “Skriptangriffen” ist es daher immer problematisch, Benutzern das Verlinken von Inhalten auf Ihrer Website zu ermöglichen.

Benutzer-Avatar
JAL

Ein paar Dinge, die Sie tun müssen, sind zu überprüfen, ob es sich um ein echtes Bild in einem akzeptierten Format (normalerweise jpg, png und gif) handelt, und den Dateinamen zu bereinigen und zu ändern.

Du kannst den … benutzen PHP getimagesize-Funktion um zu überprüfen, ob es sich um ein gültiges Bild handelt und welches Format. Sie erhalten beim Hochladen der Datei den angeblichen MIME-Typ, der jedoch für die Validierung nutzlos ist. Folgendes sollte also funktionieren, da die getimagesize-Funktion auch Bilder validiert und den Exif-Typ zurückgibt.

$image_info=getimagesize($tempname);

$allowed_types=array(IMAGETYPE_PNG,IMAGETYPE_JPEG,IMAGETYPE_GIF);//these are actually the integers 1, 2 and 3

if(in_array($image_info[2],$allowed_types)){
   //image is a valid image. You can also check the height and width.
   }

Bei Ihrer Upload-Verarbeitung ist es eine gute Idee, Ihrer Datei einen neuen eindeutigen Namen zu geben, den Sie gewählt haben, und dann müssen Sie sich keine Sorgen machen, dass sie etwas Seltsames mit dem Dateinamen machen.

Bearbeiten: Mir ist aufgefallen, dass Sie sich auf Benutzer beziehen, die eine URL für ein Bild angeben.

Die Antwort, die ich gegeben habe, bezog sich auf das Akzeptieren, Speichern und Anzeigen von Bildern, die Benutzer auf Ihren Server hochladen.

Die gleichen Prinzipien gelten jedoch für die Anzeige einer URL eines Bildes. Sie können das Bild über cURL oder fopen abrufen, in einer temporären Datei speichern und dann wie oben beschrieben prüfen, ob es sich wirklich um ein Bild handelt. Dies kann auch dazu führen, dass der Benutzer auf ein nicht vorhandenes oder ungültiges Bild verlinkt, sodass Sie ihn warnen können. Setzen Sie außerdem eine Dateigrößen-/Abmessungsbeschränkung durch – Sie möchten nicht, dass jemand auf ein 5-GB-Bild in seinem Profil verlinkt (obwohl dies sein eigenes Bandbreitenproblem wäre), da dies Ihren anderen Benutzern Unannehmlichkeiten bereiten könnte. Der Benutzer könnte die Datei später jedoch jederzeit in etwas anderes ändern. Sie könnten einmal alle x Stunden nachsehen und Leute warnen, die etwas Verdächtiges tun, aber das scheint Ihrerseits ein großer Aufwand zu sein.

Sie können auch Dateinamenregeln erzwingen, z. B. kein Unicode in Dateinamen, und der Name darf keine <>”””# – enthalten, was Zeichen sind, die selten in legitimen Bild-URLs vorkommen.

Angenommen, Sie bereinigen bereits für SQL-Injection. Sie müssen den Benutzer daran hindern, Folgendes zu tun:

<img src="http://usmilitary/launchAllNukes?When=Now" />

oder:

<img src""<script>//Evil code</script>" height="123px" width="123px" />

  • Was das erste Beispiel betrifft, gibt es keine Möglichkeit, solche Dinge zu validieren, ohne auf die Website zu gehen und zu sehen, was dort ist. Das und jeder, der als Antwort auf eine GET-Abfrage irreversible und folgenreiche Dinge tut, verdient, was er bekommt. (Es gibt Regeln, die besagen, dass Sie dafür POST verwenden sollten.) Das zweite Beispiel würde durch einfaches HTML-Escapen der “URL” vor der Ausgabe verhindert werden.

    – chao

    24. Juni 2010 um 22:38 Uhr

  • @cHao Stimmt. Mein Punkt ist, dass er zuerst die URL mit SQL-Escapezeichen versehen muss, bevor er sie in die DB einfügt, dann mit HTML-Escapezeichen, bevor er sie auf der HTML-Seite ausgibt, und schließlich könnten Sie in Betracht ziehen, zuerst die URL zu testen, um sicherzustellen, dass sie ein Bild zurückgibt (möglicherweise machen sicher, dass es eine angemessene Größe hat). Sie haben natürlich Recht, dass es in der Verantwortung der Zielsite liegt, sicherzustellen, dass sie nur Änderungen an POST vornimmt, nicht an GET, aber nicht alle tun das, so dass theoretisch etwas Schlimmes mit diesem Prozess passieren kann.

    – Adam

    24. Juni 2010 um 22:49 Uhr

Benutzer-Avatar
Byron Whitlock

Verwenden Sie vor dem Einfügen in die Datenbank imagemagik, um zu überprüfen, ob das Foto ein echtes Bild ist und nichts anderes, und Sie sollten in Ordnung sein.

  • Was das erste Beispiel betrifft, gibt es keine Möglichkeit, solche Dinge zu validieren, ohne auf die Website zu gehen und zu sehen, was dort ist. Das und jeder, der als Antwort auf eine GET-Abfrage irreversible und folgenreiche Dinge tut, verdient, was er bekommt. (Es gibt Regeln, die besagen, dass Sie dafür POST verwenden sollten.) Das zweite Beispiel würde durch einfaches HTML-Escapen der “URL” vor der Ausgabe verhindert werden.

    – chao

    24. Juni 2010 um 22:38 Uhr

  • @cHao Stimmt. Mein Punkt ist, dass er zuerst die URL mit SQL-Escapezeichen versehen muss, bevor er sie in die DB einfügt, dann mit HTML-Escapezeichen, bevor er sie auf der HTML-Seite ausgibt, und schließlich könnten Sie in Betracht ziehen, zuerst die URL zu testen, um sicherzustellen, dass sie ein Bild zurückgibt (möglicherweise machen sicher, dass es eine angemessene Größe hat). Sie haben natürlich Recht, dass es in der Verantwortung der Zielsite liegt, sicherzustellen, dass sie nur Änderungen an POST vornimmt, nicht an GET, aber nicht alle tun das, so dass theoretisch etwas Schlimmes mit diesem Prozess passieren kann.

    – Adam

    24. Juni 2010 um 22:49 Uhr

Benutzer-Avatar
Siqi Lin

Wenn Sie Benutzern erlauben, eine beliebige URL als Profilbild anzugeben, könnte ein Angreifer dies ausnutzen, um einen Denial-of-Service-Angriff auf eine kleinere Website zu ermöglichen. Seine Auswirkung auf die anvisierte Website ist gleichbedeutend mit einem Schrägstrich. Beispielsweise könnte ein Angreifer die URL seines Profilbilds in eine große Ressource ändern, die auf der angegriffenen Website gehostet wird. Jedes Mal, wenn ein Besucher Ihrer Website das Profil des Angreifers sieht, verschwendet die angegriffene Website Bandbreite, um die Ressource für den Besucher bereitzustellen.

Eine Lösung hierfür wäre, nur Profilbild-URLs zuzulassen, die auf Bild-Hosting-Sites verlinken.

1032740cookie-checkKann etwas “Schlimmes” über img src passieren?

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy