Grundsätzlich gibt es zwei Möglichkeiten, wie eine hochgeladene Datei schädlich sein kann: durch Ausführen (als Skript oder Binärdatei) oder durch Ausführen / Verwenden in einer Anwendung und Missbrauch eines Exploits darin (z. B. eine hochgeladene MP3, die dann geöffnet wird)

Mit anderen Worten, es hängt alles davon ab, was nach dem Hochladen mit der Datei passiert. Wenn jemand ein Perl-Skript hochladen kann, der Server die hochgeladenen Dateien jedoch nie ausführt oder Perl nicht installiert hat, kann nie etwas passieren. Im Allgemeinen: Wenn Sie sicherstellen, dass die hochgeladene Datei niemals ausgeführt oder interpretiert wird, sind Sie sicher.

Das Umbenennen der Dateien hilft nur bei einer Sache: Auf einigen Betriebssystemen können einige Dateierweiterungen mit a verknüpft sein bestimmte Anwendung. Wenn Sie die Datei umbenennen, können Sie verhindern, dass die Datei mit einer verknüpften Anwendung geöffnet wird. Abhängig vom System und Setup werden die hochgeladenen Dateien möglicherweise weiterhin mit einer anfälligen Anwendung geöffnet. Um im obigen Beispiel zu bleiben: Wenn eine hochgeladene Datei mit einem MP3-Player geöffnet wird, selbst wenn Sie sie in song.png umbenennen, kann sie dennoch eine Schwachstelle im Player ausnutzen (außer wenn Der Player verfügt über eine eigene Überprüfungsebene und akzeptiert z. B. nur .mp3 -Dateien.

Die umbenannten Dateien sind keine Bilder, nur aufgrund der Umbenennung. Auf Unix- und ähnlichen Systemen gibt es sogar den Befehl file , um den Typ / MIME-Typ einer Datei zu analysieren.

Fazit: In meinen Augen gibt es nur eine Möglichkeit machen. Seien Sie in Ihrem Setup sehr genau darüber, was mit den hochgeladenen Dateien geschehen kann und wird. Alle Bibliotheken, Erweiterungen oder Anwendungen, die diese Dateien akzeptieren, sollten immer auf die neueste Version aktualisiert werden.

Nein. Das Umbenennen einer Datei erhöht nicht die Sicherheit.

Er sagt zu mir, dass durch das Erstellen von Bildern aller Dateien dem Server kein Schaden zugefügt werden kann.

zum Beispiel wird evilscript.evil zu evilscript.png

Wenn Sie evilscript.evil in evilscript.png umbenennen, ziehen Sie an verwandle es nicht in ein Bild. Sie ändern nur den Namen. Im Allgemeinen ist ein Dateiname nicht relevant. Es ist nur ein Name, der einem Datenblock gegeben wird, nichts weiter.

Wenn Sie ein hochgeladenes Skript ausführen können, können Sie dies wahrscheinlich unabhängig von seinem Namen tun. Wenn Sie dies nicht können, schadet das Hochladen eines schädlichen Skripts dem System nicht, da das Skript ohnehin nicht ausgeführt wird.

Es kann jedoch verhindern, dass eine Datei versehentlich ausgeführt wird. Der einzige Schutz, den das Umbenennen bieten kann, ist der Schutz vor versehentlichem Start durch den Windows Explorer (oder eine Shell, die ebenfalls Dateierweiterungen verwendet). Das Umbenennen von virus.exe in virus.exe ~ hilft also tatsächlich, wenn Sie versehentlich auf Enter kbd> tippen.

Unix Shells verwenden Dateiformate anstelle von Erweiterungen. Beispielsweise können Sie ein Skript als evilscript.png speichern und mit einer Linux-Shell ausführen, sofern die Datei über die Berechtigung "Ausführen" verfügt. In Bezug auf die Sicherheit ist es im Allgemeinen besser, die Dateiberechtigungen anstelle der Dateinamen zu steuern.

Das Überprüfen der einzigen Erweiterung einer hochgeladenen Datei reicht nicht aus. Beispiel: Überprüfen Sie die Antwort auf diese Frage.

Ein Vorschlag: Es gibt einen zuverlässigeren Weg, dies herauszufinden der Typ einer Datei. Wenn Ihr Freund den Server auf einem Unix-Computer ausführt, können Sie den Befehl ' file' verwenden, mit dem der Inhalt der Datei überprüft wird, um das Format zu bestimmen.

Es gibt zwei Probleme: Schutz vor direkten Angriffen auf den Server und Schutz vor Angriffen auf andere Clients (was wiederum zu Angriffen auf den Server führen kann)

Zuerst der Server, wenn ein Client a anfordert Datei muss der Server entscheiden, ob er sie bereitstellen oder irgendwie ausführen soll. Diese Entscheidung kann von verschiedenen Faktoren abhängen, darunter.

1. Die Dateierweiterung
2. Das Verzeichnis, in dem sich die Datei befindet
3. Ob das ausführbare Bit gesetzt ist.
ol>

Mir sind keine Webserver bekannt, die auf der Serverseite eine Inhaltsprüfung durchführen, aber ich kann nicht ausschließen, dass einer existiert.

Idealerweise würden Sie auf dem Server keine vom Benutzer bereitgestellten Dateien in einem Verzeichnis ablegen, in dem die Skriptausführung an erster Stelle zulässig ist. Die Einschränkung der Dateierweiterung ist jedoch wahrscheinlich eine sinnvolle "Tiefenverteidigungsrichtlinie", falls a Die Datei landet versehentlich am falschen Ort.

Wenn der Server die Datei bereitstellt, muss er entscheiden, welcher MIME-Typ gesendet werden soll. Afaict-Server wählen den MIME-Typ normalerweise basierend auf der Dateierweiterung. Der Client muss dann entscheiden, was mit der Datei geschehen soll. Dies sollte auf dem vom Server gesendeten MIME-Typ basieren. In der Praxis kann es jedoch stattdessen auf der Dateierweiterung oder der Überprüfung des Dateiinhalts basieren.

Wenn der Browser die Datei als behandelt Typ, der clientseitiges Scripting beinhalten kann, dann wird die Domäne wichtig, von der aus die Datei bereitgestellt wird. Wenn die Datei von Ihrer Hauptdomäne bereitgestellt wird, kann das Skript wahrscheinlich die von Ihnen gesetzten Cookies lesen und sie verwenden, um sich als Benutzer auszugeben.

Ich glaube, dass eine Einschränkung der Dateierweiterung Teil der Sicherheitsstrategie sein sollte, aber es sollte nicht alles sein. Die Speicherung in Verzeichnissen, die die Ausführung von Skripten verbieten, die Durchsetzung von Inhalten, die der Erweiterung entsprechen, und die Verwendung eines separaten Domänennamens sollten als Teil der gesamten Verteidigungsstrategie betrachtet werden.

Dies ist sicher.

Man kann jederzeit ausführbaren Code in ein Bild schmuggeln:

• Laden Sie einfach Ihren PHP-Code mit einer anderen Erweiterung hoch
• Fügen Sie es in Metadaten wie EXIF ​​ein.
• Verwenden Sie speziell farbige Pixel, sodass ihre binäre Darstellung Ihr gewünschter PHP-Code ist, der die Neucodierung überlebt (ich habe dies tatsächlich gesehen eine im wirklichen Leben, ausgenutzt mit: https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/).

Sie sollten also bereits davon ausgehen, dass der Inhalt Ihrer Datei nicht sicher ist, wenn er vom Benutzer bereitgestellt wird. Selbst wenn Sie das Bild neu codieren und Formate konvertieren, ist es immer noch ein Bild, also führen Sie es nicht blutig aus . Wenn Ihr Webserver (wie Apache oder Nginx) ihn über den PHP-Interpreter ausführt, wird jemand einen Weg finden, PHP auszulösen, um etwas Böses zu tun. Indem Sie die Erweiterung als eine der wenigen Erweiterungen auf der Whitelist erzwingen, können Sie Ihrem Webserver mitteilen, dass es sich um ein Image handelt (nicht ausführbar) und dass es nicht über den Interpreter übertragen werden soll.

Es gibt natürlich solche , einige damit verbundene Risiken, die Sie beachten sollten:

• Ihr Benutzer fügt möglicherweise Null-Bytes oder andere lustige Dinge in den Dateinamen ein, sodass er schließlich seine Erweiterung auswählen kann.
• Ihr Benutzer versucht möglicherweise, die Pfadüberquerung zu verwenden, wenn Sie ihn den Dateinamen auswählen lassen, wodurch er möglicherweise alle möglichen Aktionen ausführen kann.
• Möglicherweise machen Sie einen Fehler in der Konfiguration des Webservers, und alles wird durchlaufen der Interpreter unabhängig von der Erweiterung (ich habe dies bereits gesehen: Es ist ein stiller Fehler, da PHP buchstäblich alles ausgibt, was es nicht erkennt, sodass Bilder vor und nach der PHP-Interpretation gleich aussehen).
• Die Datei enthält möglicherweise einen Exploit für einen bestimmten Decoder, z. B. wenn Sie wissen, dass der Administrator Ihr Bild möglicherweise anzeigt und einen Browser verwendet, der Wenn Sie einen anfälligen PNG-Viewer haben, können Sie ein PNG-Bild hochladen, das diese Sicherheitsanfälligkeit ausnutzt.

Die ersten beiden sind leicht zu lösen: Lassen Sie den Benutzer niemals seinen Dateinamen wählen oder zumindest eine Reihe von Zeichen auf die Whitelist setzen, die definitiv sicher sind, wie z. B. ^ [a-zA-Z0-9 _-] * $ (alphanumerisch, Unterstrich und Bindestrich).

Der dritte kann überprüft werden, indem irgendwo eine Datei mit dem Namen "test.png" abgelegt und <? php echo "test1" abgelegt wird. drin. Wenn Sie die Datei über Curl anfordern, sollte der vollständige Code angezeigt werden. Wenn Sie nur "test1" sehen, ist es anfällig.

Schließlich ist der letzte schwer zu überprüfen und liegt etwas außerhalb des Bereichs. Sie könnten einen Virenscanner auf der Serverseite verwenden, aber Virenscanner erfassen nur einige häufige Fälle und können normalerweise nicht alle Varianten einer Sicherheitsanfälligkeit erkennen, wenn sie überhaupt über die Sicherheitsanfälligkeit Bescheid wissen. Der Benutzer sollte im Idealfall sein System aktualisieren und keine anfällige Software ausführen. Wenn Sie sich jedoch in einer Hochsicherheitsumgebung befinden, sollten Sie die Tiefenverteidigung anwenden und beispielsweise das Bild neu codieren, möglicherweise nur Benutzer Bilder in einer virtuellen Maschine anzeigen lassen usw. Dies ist jedoch für diese Frage nicht möglich

Zusammenfassung: Es gibt einige verwandte Angriffe, von denen Sie nicht gezeigt haben, dass sie gemindert werden. Wenn Sie jedoch nur das Code-Snippet als veröffentlicht betrachten, ist dieser Teil sicher.