Bug 15874 – Filenames in Content-Disposition header are interpreted insecurely

• Status: RESOLVED
• Resolution: INVALID
• Component: WebKit Misc.

[Sean Harding]

WebKit in Safari 3 interprets the "filename" parameter of Content-Distribution headers in HTTP responses incorrectly, opening a potential security vulnerability. It retains paths given in the filename header, allowing writing downloaded files to any directory on the system to which the user has write permission without any confirmation from the user. Example problem header:

Content-Disposition: attachment; filename=../../../../../../../../hi-there

This is diffused somewhat by the fact that Safari appends "-[number]" to the name, and it apparently will not overwrite an existing file. However, it's quite conceivable that this could still result in a serious security vulnerability. Files downloads should be restricted to the configured download folder (and potentially subfolders thereof).

From RFC 2183:

  "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.  Portable
   specification of directory paths might possibly be done in the future
   via a separate Content-Disposition parameter, but no provision is
   made for it in this draft."

[Mark Rowe (bdash)]

Content-Disposition is not handled by WebKit.  A different framework on the system is responsible for this.

[Mark Rowe (bdash)]

<rdar://problem/5584575>

[Mark Rowe (bdash)]

Thanks for the bug report.  I've pulled the bug into Radar so the appropriate team can deal with it.

[David Kilzer (:ddkilzer)]

Bug 15964 may be related.

[Mark Rowe (bdash)]

*** Bug 15964 has been marked as a duplicate of this bug. ***