Opened at 2010-08-01T04:56:48Z
Last modified at 2011-05-20T22:28:52Z
#1142 new defect
Unlikely XSS Potential in File Names in WUI
Reported by: | chrisp | Owned by: | nobody |
---|---|---|---|
Priority: | major | Milestone: | undecided |
Component: | code-frontend-web | Version: | 1.7.1 |
Keywords: | security xss html names wui | Cc: | |
Launchpad Bug: |
Description
I have a file named "zumby-bumby ; mail blaggy@… < /etc/hosts" in the pubgrid root (http://pubgrid.tahoe-lafs.org/uri/URI%3ADIR2%3Actmtx2awdo4xt77x5xxaz6nyxm%3An5t546ddvd6xlv4v6se6sjympbdbvo7orwizuzl42urm73sxazqa/).
When you try to rename it, you get the message:
"No such child: zumby-bumby ; mail blaggy@… < /etc/hosts"
served as text/plain. IE will render text/plain as HTML if it detects HTML in the plain text. Pathetic, but true. To attack this, the attacker would have to convince the user to add a maliciously-named file to their directory, so it's more social engineering than automatable attack, but still.
Change History (3)
comment:1 Changed at 2010-08-04T23:27:51Z by warner
comment:2 Changed at 2011-05-20T22:28:31Z by davidsarah
- Keywords security xss html names added
comment:3 Changed at 2011-05-20T22:28:52Z by davidsarah
- Component changed from unknown to code-frontend-web
- Keywords wui added
Do we know what their HTML-detector looks like? Is is looking at the start of the body, or in the middle? Specifically, would a text/plain response that says "No such child: <html><body><div>yay XSS</div></body></html>" get picked up as HTML?
If it's really stupid and looks in the middle, I suppose our defense is to return a text/html error message in which the filename has been safely encoded. (the CLI tools use a "Accept: text/plain, application/octet-stream" header, and I imagine IE accepts text/html, so we can have the server continue to give text/plain to the CLI tools).