Frage:
Hacker hat das Hochladen von Bildern verwendet, um PHP-Code auf meine Website zu bringen
Williamz902
2017-01-04 16:04:26 UTC
view on stackexchange narkive permalink

Ich arbeite an einer Website - im Moment befindet sie sich in einem frühen Teststadium, ist noch nicht gestartet und enthält nur Testdaten - Gott sei Dank.

Zunächst hat ein Hacker das Passwort für herausgefunden Melden Sie sich auf den Verwaltungsseiten der Websites * sup> an. Ich glaube, sie haben einen Key Logger auf dem Computer eines Freundes verwendet, der sich auf der Website angemeldet hat, um mir Feedback zu geben.

Zweitens haben sie ein Bild-Upload-Feld verwendet, um eine PHP-Datei hochzuladen. Ich habe streng geprüft, dass nur JPG- und PNG-Dateien akzeptiert werden - alles andere hätte abgelehnt werden sollen. Sicherlich gibt es keine Möglichkeit, eine JPG-Datei hochzuladen und dann die Erweiterung zu ändern, sobald die Datei gespeichert ist.

Zum Glück generiere ich auch neue Dateinamen, wenn eine Datei an mich gesendet wird, also denke ich nicht Sie konnten die Datei finden, um den Code auszuführen.

Ich kann einfach nicht herausfinden, wie die Website eine PHP-Datei durchgelassen hat. Was ist los mit meiner Sicherheit? Der Validierungsfunktionscode lautet wie folgt:

  Funktion ValidateChange_Logo (theForm) {var regexp; if (theForm.FileUpload1.value == "") {alert ("Sie haben keine neue Logodatei ausgewählt oder Ihre Datei wird nicht unterstützt."); theForm.FileUpload1.focus (); falsch zurückgeben; } var extension = theForm.FileUpload1.value.substr (theForm.FileUpload1.value.lastIndexOf ('.')); if ((extension.toLowerCase ()! = ".jpg") && (extension.toLowerCase ()! = ".png")) {alert ("Sie haben keine neue Logodatei ausgewählt oder Ihre Datei wird nicht unterstützt. "); theForm.FileUpload1.focus (); falsch zurückgeben; } return true;}  

Sobald die Datei auf dem Server angekommen ist, verwende ich den folgenden Code, um die Erweiterung beizubehalten und einen neuen zufälligen Namen zu generieren. Es ist etwas chaotisch, aber es funktioniert gut.

  // Dateierweiterung verarbeiten und beibehalten $ fileExt = $ _FILES [logo] [name]; $ reverse = strrev ($ fileExt); $ extension0 = substr ($ umgekehrt, 0, 1); $ extension1 = substr ($ umgekehrt, 1, 1); $ extension2 = substr ($ umgekehrt, 2, 1); $ fileExtension = ".". $ extension2. $ extension1 . $ extension0;
$ newName = rand (1000000, 9999999). $ fileExtension;  

Ich habe gerade mit einem Namen wie logo.php; .jpg getestet und obwohl das Bild nicht von der Website geöffnet werden kann, ist es korrekt Der Name wurde in 123456.jpg geändert. Für logo.php / .jpg lässt Windows einen solchen Dateinamen nicht zu.


* Geschützte Seiten auf der Website, die einfache Funktionen ermöglichen: B. ein Bild hochladen, das dann zu einem neuen Logo für die Website wird. Die FTP-Details unterscheiden sich vollständig von dem Kennwort, mit dem Sie sich auf den geschützten Seiten der Website anmelden. Ebenso wie Datenbank- und cPanel-Anmeldeinformationen. Ich habe sichergestellt, dass die Benutzer nicht einmal die Ordner- und Dateistruktur der Site anzeigen können. Es gibt buchstäblich keine Möglichkeit, eine .jpg- oder .png-Erweiterung in .php auf dieser Site umzubenennen, wenn Sie keine FTP-Details haben. Sup>

Kommentare sind nicht für eine ausführliche Diskussion gedacht.Diese Konversation wurde [in den Chat verschoben] (http://chat.stackexchange.com/rooms/51538/discussion-on-question-by-williamz902-hacker-used-picture-upload-to-get-php-code).
Kurze Antwort: Die clientseitige Validierung kann einfach durch Einstellen eines Proxys umgangen werden.Sie können einfach zuerst a.jpg einreichen und alle Prüfungen bestehen.Die Anfrage wird dann am Proxy abgefangen und in a.php geändert.Sie müssen die Validierung auf der Serverseite durchführen.
Elf antworten:
Anders
2017-01-04 16:12:38 UTC
view on stackexchange narkive permalink

Clientseitige Validierung

Der von Ihnen angegebene Validierungscode ist in JavaScript. Dies deutet darauf hin, dass Sie Code für die Validierung auf dem Client verwenden.

Regel Nummer eins beim Sichern von Webanwendungen lautet, dem Client niemals zu vertrauen . Der Client steht unter der vollen Kontrolle des Benutzers - oder in diesem Fall des Angreifers. Sie können nicht sicher sein, ob ein Code, den Sie an den Client senden, für irgendetwas verwendet wird, und keine Blöcke, die Sie auf dem Client platzieren, haben einen Sicherheitswert. Die Validierung auf dem Client dient lediglich dazu, eine reibungslose Benutzererfahrung zu gewährleisten und keine sicherheitsrelevanten Einschränkungen durchzusetzen.

Ein Angreifer kann dieses JavaScript-Element in seinem Browser einfach ändern oder Skripte vollständig deaktivieren oder einfach Senden Sie die Datei nicht über einen Browser, sondern erstellen Sie eine eigene POST-Anfrage mit einem Tool wie curl.

Sie müssen alles auf dem Server erneut validieren. Das bedeutet, dass Ihr PHP dies überprüfen muss dass die Dateien vom richtigen Typ sind, was Ihr aktueller Code nicht tut.

Wie das geht, ist ein weites Problem, das meiner Meinung nach außerhalb des Rahmens Ihrer Frage liegt, aber diese Frage sind gute Orte, um mit dem Lesen zu beginnen. Möglicherweise möchten Sie auch Ihre .htaccess -Dateien ansehen.

Abrufen der Erweiterung

Kein Sicherheitsproblem Vielleicht, aber dies ist ein besserer Weg, dies zu tun:

  $ ext = pathinfo ($ filename, PATHINFO_EXTENSION);  

Magische PHP-Funktionen

Wenn ich Daten aus Bearbeitungsfeldern speichere, verwende ich alle drei PHP-Funktionen, um sie zu bereinigen:

  $ cleanName = strip_tags ($ _ POST [Name]); // HTML-Tags entfernen $ bereinigtName = htmlspecialchars ($ bereinigtName); // Sonderzeichen zulassen, aber sicher aufbewahren. $ bereinigter Name = mysqli_real_escape_string ($ connectionName, $ bereinigter Name);  

Dies ist keine gute Strategie. Die Tatsache, dass Sie dies im Zusammenhang mit der Validierung von Dateierweiterungen erwähnen, macht mir Sorgen, dass Sie nur ein paar sicherheitsrelevante Funktionen auf Ihre Eingabe werfen, in der Hoffnung, dass dies das Problem lösen wird.

Zum Beispiel sollten Sie es sein Verwenden Sie vorbereitete Anweisungen und entkommen Sie nicht, um sich vor SQLi zu schützen. Das Escaping von HTML-Tags und Sonderzeichen, um XSS zu verhindern, muss nach dem Abrufen der Daten aus der Datenbank erfolgen. Wie dies zu tun ist, hängt davon ab, wo Sie diese Daten einfügen. Und so weiter und so fort.

Fazit

Ich sage das nicht als gemein, aber Sie scheinen hier viele Fehler zu machen. Es würde mich nicht wundern, wenn es andere Schwachstellen gibt. Wenn Ihre App vertrauliche Informationen verarbeitet, kann ich nur empfehlen, dass Sie jemanden mit Sicherheitserfahrung einen Blick darauf werfen, bevor Sie sie in die Produktion aufnehmen.

Ein einfaches Beispiel: Öffnen Sie Ihre Website in Chrome.Drücken Sie f12, um die Entwicklertools zu öffnen.Wählen Sie die Registerkarte Quellen.Sie sehen alle Ihre JavaScripts, aufgereiht und gut bearbeitbar.Finden Sie Ihre Validierungsfunktion.Löschen Sie es und ersetzen Sie es durch return true.
/ \ Nicht nur in Chrome
Kommentare sind nicht für eine ausführliche Diskussion gedacht.Diese Konversation wurde [in den Chat verschoben] (http://chat.stackexchange.com/rooms/51233/discussion-on-answer-by-anders-hacker-used-picture-upload-to-get-php-code-in-m).
Eine wichtige Sache, die hervorgehoben werden muss, ist "** alles neu validieren" - nur weil Sie auf dem Server validieren, heißt das nicht, dass Sie nicht im Browser sein sollten.Verwenden Sie es nur nicht für * Sicherheit *.Auf diese Weise können Ihre Benutzer Dinge wie "Oh, ich habe ein A in meine Telefonnummer eingegeben, whoops" wissen, bevor Sie das Formular senden.
Richtig, die Validierung auf Benutzerseite sollte nur verwendet werden, um die Anzahl der Anforderungen zu verringern und damit die Geschwindigkeit zu erhöhen.
Und um die Dinge noch interessanter zu machen, gibt es immer Polyglots ... http://blog.portswigger.net/2016/12/bypassing-csp-using-polyglot-jpegs.html
Wenn Sie nur Javascript verwenden, bedeutet Validierung überhaupt keine Validierung.es erlaubt per curl zu posten
@Cryptopat etwas etwas Node.js.
"Ich denke, sie haben einen Key Logger auf dem Computer eines Freundes verwendet." Nein, dies kommt sehr selten vor, da viele Websites voller Schwachstellen sind, die leichter auszunutzen sind.
Ich würde keinen Dateityp anhand der Dateierweiterung überprüfen.Es gibt Tools, mit denen Sie den Inhalt einer Datei überprüfen und wissen lassen können, um welchen Dateityp es sich handelt ("Datei" unter Linux ist ein Beispiel).
@YoMismo Da die Erweiterung bestimmt, was ausgeführt wird und nicht vom Server, würde ich es definitiv überprüfen.Aber Ihr Vorschlag könnte eine gute Ergänzung dazu sein.
@Anders, Es kann Einschränkungen beim Hochladen bestimmter Dateien (ausführbare Dateien) geben, andere jedoch nicht (Bilder), wenn Sie nur Dateierweiterungen anstelle des Inhalts überprüfen, den möglicherweise jemand in der Lage ist, eine ausführbare Datei hochzuladen.Dies kann dazu führen, dass diese Datei ausgeführt wird, wenn andere Sicherheitslücken entdeckt werden.Und unter anderen Betriebssystemen als Windows hat eine ausführbare Datei nichts mit Dateierweiterungen zu tun.
@YoMismo Mit der Standardkonfiguration bestimmt die Erweiterung `.php` sehr stark, ob eine Datei ausgeführt wird oder nicht, sei es unter Linux oder nicht.Es ist schlecht zu sagen, nicht zu überprüfen, was tatsächlich in der Datei enthalten ist. Wenn Sie nicht auch die Erweiterung überprüfen, haben Sie ein Problem.
thel3l
2017-01-04 16:12:29 UTC
view on stackexchange narkive permalink

Wenn jemand eine Datei-Upload-Funktion ausgenutzt hat, stellen Sie zunächst sicher, dass Sie die Datei sowohl auf dem Client als auch Server . Das Umgehen des clientseitigen JavaScript-Schutzes ist trivial.

Stellen Sie zweitens sicher, dass Sie diese Ideen von OWASP durchgehen und implementieren.

Dies sollte den größten Teil Ihrer Probleme abdecken Probleme. Stellen Sie außerdem sicher, dass Sie keine anderen nicht gepatchten Fehler auf Ihrem Server haben (z. B. veraltete Plugins, ausnutzbare Server usw.).

Können Sie die "OWASP" -Ideen näher erläutern? Es ist nicht unbedingt gut, Leute von * hier * wegzuschicken.Selbst wenn Sie einige Inhalte oder Ideen hierher bringen, würde sich diese Antwort erheblich verbessern.
Ich stimme @Mooz, zu. OWASP ist auch ein Wiki, d. H. Viele dieser Ideen können später bearbeitet werden, und einige davon können dem OP in dieser speziellen Situation helfen.Wenn Sie sich darauf konzentrieren, die Ideen / Implementierungen hinzuzufügen, die dem OP helfen können, kann ich zustimmen ... Derzeit ist Ihre Antwort nur eine Kopie früherer Vorschläge / Kommentare (sogar der einfache Vorschlag, [PHP im Upload-Verzeichnis zu deaktivieren] (http): //security.stackexchange.com/a/147396/121288) ist nützlicher als ein Link zu einer langen Liste von Ideen auf einer anderen Website).
@CPHPython - Mein schlechtes.Ich werde es reparieren.Danke für die Warnung.
Eine Validierung der Eingabe auf der Clientseite ist nicht erforderlich. Sie ist nur dann gedacht, wenn Sie Benutzern die Möglichkeit bieten möchten, frühzeitig Fehlermeldungen zu erhalten. Aus Sicherheitsgründen ist eine clientseitige Validierung jedoch wertlos.
gowenfawr
2017-01-04 23:44:46 UTC
view on stackexchange narkive permalink

Es ist sehr wichtig zu beachten, dass PHP so konzipiert wurde, dass es in andere Inhalte eingebettet wird . Insbesondere wurde es so konzipiert, dass es in HTML-Seiten eingebettet wird und eine weitgehend statische Seite mit kleinen Bits dynamisch aktualisierter Daten ergänzt.

Und ganz einfach, ist es egal, was es ist eingebettet in . Der PHP-Interpreter durchsucht jeden beliebigen Dateityp und führt alle PHP-Inhalte aus, die ordnungsgemäß mit Skript-Tags gekennzeichnet sind.

Das historische Problem, das dies verursacht hat, besteht darin, dass Bild-Uploads PHP enthalten können. Und wenn der Webserver bereit ist, diese Dateien über den PHP-Interpreter zu filtern, wird dieser Code ausgeführt. Weitere Informationen finden Sie im Fiasko des Wordpress-Plugins "Tim Thumb".

Die richtige Lösung besteht darin, sicherzustellen, dass Ihr Webserver niemals nicht vertrauenswürdigen Inhalt als etwas behandelt, das über PHP ausgeführt werden sollte. Der Versuch, die Eingabe zu filtern, ist eine Möglichkeit, aber wie Sie festgestellt haben, begrenzt und fehleranfällig.

Es ist viel besser zu überprüfen, ob sowohl der Speicherort als auch die Dateierweiterung verwendet werden, um zu definieren, was PHP tun wird Uploads und andere nicht vertrauenswürdige Inhalte in Speicherorte und Erweiterungen zu trennen, die nicht verarbeitet werden. (Wie Sie dies tun, ist von Server zu Server unterschiedlich und leidet unter dem Problem "Dinge zum Laufen zu bringen bedeutet normalerweise, die Sicherheit auf eine Weise zu lockern, die Sie nicht kennen".)

Seltsamerweise wurde diese Natur von der timthumb PHP Image Resizer-Bibliothek verwendet (ohne zu sagen, dass es eine gute oder eine schlechte Sache ist).Im Wesentlichen die Zeichenfolge `
@LukeA.
Ich werde den Autor nicht beurteilen, aber als der Zero-Day von Joomla 3.4.8 herauskam, bekam ich einen MASSIVEN Schrecken, als mein hauseigener Heuristik-Scanner ein öffnendes PHP-Tag in über 10.000 Bildern auf 3 Servern auftauchte.Einer dieser Momente, in denen Sie spüren können, wie das Blut aus Ihrem Gesicht fließt.
Die Tatsache, dass Sie Skripte hochladen können, die vom Interpreter ausgeführt werden sollen, hängt jedoch nicht mit PHP zusammen, das sich selbst einbetten lässt.Genau wie bei PHP können Sie Python- oder Ruby-Skripte hochladen.Das Problem ist jedoch, dass PHP und Apache (standardmäßig) die Verzeichnisstruktur des Servers öffentlich verfügbar machen und Sie über HTTP auf jede gewünschte Datei auf dem Server zugreifen können.
medskill
2017-01-06 00:20:41 UTC
view on stackexchange narkive permalink

Sie können PHP in Ihrem Upload-Verzeichnis mit .htaccess deaktivieren, damit Ihr Server keinen PHP-Code im Verzeichnis und in seinen Unterverzeichnissen ausführt.

Erstellen Sie damit eine .htaccess-Datei in Ihrem Upload-Verzeichnis Regel:

  php_flag engine off  

Bitte beachten Sie, dass die .htaccess-Regel nur funktioniert, wenn Ihr PHP-Server in mod_php code ausgeführt wird > Modus.

Bearbeiten: Natürlich habe ich vergessen zu erwähnen, dass .htaccess nur in Apache funktioniert.

Beachten Sie, dass `.htaccess` nur für Apache gilt.
iainpb
2017-01-04 19:19:48 UTC
view on stackexchange narkive permalink

Sie überprüfen nur die Erweiterung, dies korreliert nicht unbedingt mit dem tatsächlichen Dateityp. Auf der Serverseite können Sie beispielsweise exif_imagetype verwenden, um zu überprüfen, ob es sich bei der Datei um ein Bild handelt. Verwendung des Exif-Bildtyps: http://php.net/manual/en/function.exif-imagetype.php

Dies mag eine gute Idee sein, aber denken Sie daran, dass (a) es möglich sein könnte, eine Datei zu erstellen, die sowohl als Image als auch als PHP gültig ist, und (b) eine PHP-Datei mit der Erweiterung ".png" nicht viel Schaden anrichtetauf Ihrem Server, da es nicht ausgeführt wird.
@Anders, aber es ist immer noch bösartiger Code, und alles, was es braucht, um Dinge zu zerstören, ist jemand / etwas, der ihm sagt, dass er "foo.png" als PHP-Datei ausführen soll.Obwohl es unwahrscheinlich ist, möchte ich lieber keine Taschenbomben in * meiner * Tasche haben, auch wenn ich der einzige mit einem Zünder bin.
@Anders Es sei denn, Ihr Server ist so konfiguriert, dass Dateien anhand ihres Inhalts und nicht anhand der Erweiterung interpretiert werden.Sicherheit ist schwer ...
@Delioth Einverstanden, ich war ein bisschen zu kategorisch.Ich hätte sagen sollen, dass es nicht so gefährlich ist, nicht dass es ohne Risiko ist.
LostBoy
2017-01-05 03:14:44 UTC
view on stackexchange narkive permalink

Ein möglicher Teil einer Lösung besteht darin, das Bild beizubehalten, aber auch mit PHP eine Kopie in der Größe zu erstellen, damit Sie sicherstellen können, dass Sie ein Bild erhalten, und die Größe des Bilds verringern können Original Bild. Dies hat mehrere positive Auswirkungen:

  • Lässt das Originalbild niemals für die Anzeige verwendet werden, damit es sicherer ist.
  • Spart Speicherplatz auf Ihrem Server (was möglicherweise ein Problem darstellt oder nicht )
  • Bessere Ladezeit für Website-Besucher, da sie nicht auf das Laden eines 10-MB-Images warten würden. Stattdessen haben sie ein 300-KB-Image bei einer angemessenen Ladegröße.

Der Hauptpunkt ist, dass Sie Benutzerdaten niemals vertrauen können. Überprüfen Sie alles, Datei-Uploads, Eingaben und Cookies, um sicherzustellen, dass die Daten keine Probleme verursachen können.

akman
2017-01-06 18:24:02 UTC
view on stackexchange narkive permalink

Ich stimme der akzeptierten Antwort voll und ganz zu, aber ich würde vorschlagen, ein bisschen mehr zu tun, als nur mit dem Dateinamen herumzuspielen. Sie sollten die ursprüngliche / hochgeladene Datei mit PHP mithilfe von GD oder Imagick erneut komprimieren und das neue Bild verwenden. Auf diese Weise zerstören Sie jeden injizierten Code (um ehrlich zu sein, gibt es in 90% der Fälle Möglichkeiten, den Code die Komprimierung zu überstehen, aber es ist viel Arbeit).

Sie könnten auch Verwenden Sie .htaccess -Dateien, um zu verhindern, dass im Upload-Verzeichnis PHP-Code ausgeführt wird (ich kenne IIS nicht und es gibt wahrscheinlich eine entsprechende .webconfig).

  <FilesMatch \ .php $ > SetHandler-Anwendung / x-httpd-php< / FilesMatch>  

Auf diese Weise wird die hochgeladene Datei nur ausgeführt, wenn die "endgültige Erweiterung" PHP ist, also image.php.jpg nicht ausgeführt werden.

Einige Ressourcen:

* "Auf diese Weise wird die hochgeladene Datei nur ausgeführt, wenn die" endgültige Erweiterung "PHP ist, sodass image.php.jpg nicht ausgeführt wird." * - Vermutlich für den Site-Typ, den das OP beschreibtDeaktivieren Sie einfach den PHP-Großhandel im Upload-Verzeichnis und sorgen Sie sich nicht um die Dateierweiterung.Wenn es aus irgendeinem Grund jemandem gelungen ist, eine Datei mit der Endung ".php" hochzuladen, möchten Sie dennoch nicht, dass sie ausgeführt wird
@anotherdave wahr!Der Hauptteil besteht darin, das Bild zu komprimieren ... der zweite Teil ist nur ein Extra, das je nach Bedarf konfiguriert werden kann
Daniel
2017-01-06 16:00:10 UTC
view on stackexchange narkive permalink

Ich muss nur eine kleine Sache hinzufügen, die nicht berührt wurde: die Verwendung einer White-List-Strategie.

Wie andere bereits betont haben, ist es sicherlich keine gute Sache, sich ausschließlich auf die clientseitige Validierung zu verlassen. Sie haben auch eine Black-List-Strategie angewendet, die bedeutet, dass Sie nach Dingen suchen, von denen Sie wissen / denken, dass sie schlecht sind, und alles andere berücksichtigen. Eine viel robustere Strategie besteht darin, zu überprüfen, ob Dinge in Ordnung sind, und alles andere abzulehnen.

Manchmal ist dies ein Kompromiss mit dem Feedback der Benutzer, z. B. wenn unerfahrene Benutzer wissen, was sie tun müssen, um eine erfolgreich hochzuladen Bild.

Nach meiner Erfahrung schließen sich die beiden Strategien nicht unbedingt gegenseitig aus, solange sie für unterschiedliche Zwecke verwendet werden: clientseitige Blacklist-Validierung für Benutzerfeedback und serverseitige Whitelist-Validierung für Sicherheit.

a coder
2017-01-08 19:04:23 UTC
view on stackexchange narkive permalink

Ich erlaube das Hochladen von Bildern, gehe aber davon aus, dass jeder mit Trojaner-Code geladen ist. Ich platziere das hochgeladene Bild beim Hochladen vorübergehend über dem Webstamm, konvertiere es dann mit ImageMagick in BMP, dann in JPG und verschiebe es dort, wo die Webanwendung es verwenden kann. Dadurch wird eingebetteter PHP-Code effektiv entfernt.

Wie @Sneftel im folgenden Kommentar ausführt, führt die Durchführung dieser Konvertierung in einem JPG zu einer gewissen Verschlechterung des Bildes. Für meinen Zweck ist dies ein akzeptabler Kompromiss.

Die Konvertierung in ein BMP und dann in ein JPG, insbesondere wenn die Eingabe ein JPG war, führt zu einem spürbaren Qualitätsverlust.Das Umpacken des Bildes ist keine schlechte Idee, aber Sie sollten es so tun, dass das Bild nicht beeinträchtigt wird.
Für unsere Zwecke war eine leichte Bildverschlechterung kein Problem.
Ich verwende das in RHEL 7 enthaltene Paket, das derzeit ImageMagick 6.7 ist
Tomek Leszczynski
2017-01-08 01:46:23 UTC
view on stackexchange narkive permalink

Überprüfen Sie ein Bild-EXIF-Tag oder verwenden Sie eine strpos-Funktion, um einen PHP-Code im Bildinhalt zu finden. Beispiel:

  $ imageFile = file_get_contents ($ your_image_temp_path); // BEACHTUNG! Ein temporärer Pfad für Bilder wird aus Sicherheitsgründen wirklich benötigt! $ HazardSyntax = ['<?', '<? Php', '? >']; $ error = ''; foreach ($ gefährlicheSyntax als $ Wert) {$ find = strpos ($ value, $ imageFile); if ($ find! == true) {unlink ($ your_image_temp_path); $ error = 'Wir haben einen gefährlichen Code in Ihrem Bild gefunden'; }} if (! empty ($ error)) {die ($ error);}  
Was lässt Sie denken, dass eine bestimmte Bilddatei nicht die Zeichen '
Grey
2017-01-06 14:37:36 UTC
view on stackexchange narkive permalink

Zusätzlich zur akzeptierten Antwort würde ich vorschlagen, die in PHP integrierte Funktion getImageSize zu verwenden, um den MIME-Typ abzurufen und sicherzustellen, dass sich eine PHP-Datei nicht unter einer Image-Dateierweiterung versteckt.

Können Sie in Ihrer Antwort genauer beschreiben, wie Sie sicherstellen, dass keine PHP-Tags vorhanden sind, indem Sie den MIME-Typ konsultieren?Tun Sie etwas Ähnliches wie [Beispiel 1] (http://php.net/manual/en/function.getimagesize.php#example-3471) und setzen Sie den Header "Inhaltstyp" mit einem der [verfügbaren Typen] zurück(http://php.net/manual/en/function.image-type-to-mime-type.php)?
@CPHPython Dieser Kommentar sollte zusätzlich zu der akzeptierten Antwort verklagt werden, um sicherzustellen, dass keine PHP-Dateitypen (oder andere falsche Dateitypen) hochgeladen werden, indem nur die Erweiterung geändert wird (z. B. eine PHP-Datei mit dem Namen image.jpeg).Es bietet keine Sicherheit gegen Code im Dateinamen.


Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...