Moin Moin!

Der saubere Weg ist der Content-Disposition-Header, siehe RFC2616. "Content-Disposition: attachment" teilt dem Browser mit, dass der Server die jeweilige Resource nicht angezeigt, sondern gespeichert haben möchte.

Hm. Wikipedia ist

... ein großer Haufen Text mit stark variierender Qualität. Aus welchem Artikel zitierst Du hier?

da (in Bezug auf "sauber") anderer Ansicht: "Mit diesem nicht standardisierten und als gefährlich eingestuften Feld kann der Server für bestimmte MIME-Typen Downloadfenster erzeugen und einen Dateinamen vorschlagen."...

Das ist ja großartiger Murks.

1. Der Server kann das Herunterladen für jede x-beliebige Resource vorschlagen, unabhängig vom MIME-Typ. Entscheidend ist der Content-Disposition-Header.

2. Wer hat das "Feld" als "gefährlich" eingestuft? Welches Feld übrigens? C-D ist ein HTTP-Header, kein Feld, um mal ein paar Erbsen zu zählen.

3. Nicht standardisiert? Hmmm, tatsächlich. In RFC2616 steht unter "15.5 Content-Disposition Issues" folgendes: "RFC 1806 [35], from which the often implemented Content-Disposition (see section 19.5.1) header in HTTP is derived, has a number of very serious security considerations. Content-Disposition is not part of the HTTP standard, but since it is widely implemented, we are documenting its use and risks for implementors. See RFC 2183 [49] (which updates RFC 1806) for details." Die Risiken beziehen sich tatsächlich nur auf die Dateinamen, siehe unten.

4. Was bitteschön ist gefährlich daran, eine Resource zum Speichern vorzuschlagen? Der Server KANN einen abweichenden Dateinamen VORSCHLAGEN, muß er aber nicht. In wie weit sich der Client (Browser) daran hält, ist dessen Problem. Kein halbwegs sauberer Browser wird Pfadangaben vom Server annehmen, allerhöchstens den Dateinamen. Und kein halbwebs sauberes Betriebssystem wird einen Standard-Benutzer systemrelevante Dateien überschreiben lassen.

Die Angriffsmöglichkeiten in RFC2183 beziehen sich auf Unixe, und sind ziemlich blauäugig:

+    Creating startup files (e.g., ".login").

Möglich, lästig, und letztlich nur möglich, wenn der Client (Mailer oder Browser) den vorgeschlagenen Namen nicht genügend filtert. Von einem Unix-Client erwarte ich, dass führende Punkte aus dem vorgeschlagenen Dateinamen entfernt werden.

+    Creating or overwriting system files (e.g., "/etc/passwd").

Wieder ein Filter-Problem. /etc/ im vorgeschlagenen Namen sollte ignoriert werden. Außerdem sollte /etc/passwd von Usern nicht überschrieben werden können. Wenn doch, hat der root gepennt. Und root sollte weder als root mailen noch als root surfen. Also Mumpitz.

+    Overwriting any existing file.

Nochmal ein Filter-Problem. Verzeichnisangaben haben ignoriert zu werden. So kann nur eine Datei im zum Download ausgewählten Verzeichnis überschrieben werden, soweit der User auf der Datei Schreibrechte hat. In aller Regel fragt der Client, ob überschrieben werden soll. Auf systemrelevante Dateien hat der User keine Schreibrechte zu haben.

+    Placing executable files into any command search path (e.g., "~/bin/more").

Wieder ein Filter-Problem. Verzeichnisnamen im vorgeschlagenen Dateinamen haben ignoriert zu werden. Und selbst wenn nicht: Kein vernünftiger Client wird Dateien mit gesetzten Executable-Bits ablegen. Und ohne Executable-Bits ignorieren Unixe im Suchpfad abgelegte Dateien. Ähnliche Situation unter Windows: User sollten nicht in Programmverzeichnisse schreiben können.

+    Sending the file to a pipe (e.g., "| sh").

Das ist nur möglich, wenn nicht ausreichend gefiltert wird UND auch noch die Shell mit ungefilterten Daten aufgerufen wird.

Letztlich ist diese Panikmache schlecht aus den RFCs abgeschrieben. Content-Disposition ist der de-facto-Standard, und alle relevanten Clients filtern mindestens die Pfadangaben aus dem Dateinamen. Natürlich kann man sich einen HTTP- oder Mail-Client stricken, der Dateinamen aus dem C-D-Header nicht filtert, so riesige Lücken reißt, und das System von außen angreifbar macht. Ist das dann aber der Fehler der RFCs oder desjenigen, der den Client gebastelt hat?

Weiter oben in der RFC2183, im Kapitel 2.3, steht übrigens nochmal ausdrücklich, dass Clients den Dateinamen gründlich zu filtern haben: "It is important that the receiving MUA not blindly use the suggested filename. The suggested filename SHOULD be checked (and possibly changed) to see that it conforms to local filesystem conventions, does not overwrite an existing file, and does not present a security problem (see Security Considerations below). The receiving MUA SHOULD NOT respect any directory path information that may seem to be present in the filename parameter.  The filename should be treated as a terminal component only."

Alexander