Bug 15874
| Summary: | Filenames in Content-Disposition header are interpreted insecurely | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Sean Harding <sharding> |
| Component: | WebKit Misc. | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED INVALID | ||
| Severity: | Normal | CC: | joakim, mrowe |
| Priority: | P2 | Keywords: | InRadar |
| Version: | 523.x (Safari 3) | ||
| Hardware: | Mac | ||
| OS: | OS X 10.5 | ||
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."
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
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. ***