Benutzer laden Profilbilder hoch; der Server speichert sie im Web-Root und liefert sie zurück. Was ist das Risiko?

„Es sind nur Profilbilder" ist die Annahme, die ein Upload-Formular in eine Remote-Shell verwandelt. Sobald Benutzer eine Datei in ein Verzeichnis schreiben können, das der Webserver ausliefert und ausführt, wird die Upload-Funktion zu einem Code-Auslieferungskanal.

Warum das gefährlich ist

Läuft auf dem Server PHP, JSP, ASPX usw., lädt ein Angreifer avatar.php statt eines PNG hoch und ruft es dann ab — der Server führt es aus und gewährt Remote Code Execution (RCE) sowie einen Brückenkopf auf dem Host. Selbst ohne Skript-Engine führt eine hochgeladene HTML- oder SVG-Datei, die von Ihrem Origin ausgeliefert wird, JavaScript im Browser Ihrer Benutzer aus und ergibt Stored-XSS und Sitzungsdiebstahl. Angreifer umgehen naive Prüfungen mit doppelten Endungen (shell.php.png), Null-Bytes, gefälschten Content-Type-Headern oder Polyglot-Dateien, deren Magic Bytes wie ein Bild aussehen, deren Ende aber aktiver Code ist.

Die richtige Lösung

Schichten Sie die Abwehr:

• Validieren Sie den echten Inhalt, nicht nur die Endung oder den vom Client gelieferten Content-Type — prüfen Sie die Magic Bytes und kodieren Sie das Bild idealerweise neu, sodass jede eingebettete Nutzlast entfernt wird.
• Speichern Sie Uploads außerhalb des Web-Roots oder in Object Storage / einem separaten Origin, der keinen Code ausführen kann und mit einem harmlosen Content-Type plus Content-Disposition: attachment ausliefert.
• Randomisieren Sie Dateinamen, damit Angreifer Pfade weder vorhersagen noch überschreiben können, und entfernen Sie den Originalnamen.
• Beschränken Sie Größe und Typ und führen Sie bei Bedarf AV/Scanning aus.

Warum die anderen Antworten falsch sind

„Kein Risiko — es sind nur Bilder" ist genau der blinde Fleck, der die Schwachstelle ausliefert; der angegebene Dateityp wird vom Angreifer kontrolliert. „Langsamere Ladezeiten" und „übermäßiger Speicherverbrauch" sind reale Betriebsanliegen, betreffen aber Kapazität, nicht Kompromittierung — ein Interviewer, der fragt „Was ist das Risiko?", erwartet, dass Sie RCE / Stored-XSS nennen sowie die Speicher- und Validierungskontrollen, die verhindern, dass eine hochgeladene Datei je ausgeführt oder als Markup interpretiert wird.