Closed Bug 726294 Opened 13 years ago Closed 12 years ago

MDN XSS in Attachments, unknown extensions sent as text/html

Categories

(developer.mozilla.org Graveyard :: User management, task)

Product:
developer.mozilla.org Graveyard
Component:
User management
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: mateusz.goik, Assigned: groovecoder)

References

Details

(Keywords: sec-high, wsec-xss, Whiteboard: [infrasec:xss][ws:high]) 

User Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0) Gecko/20100101 Firefox/10.0
Build ID: 20120129021758

Steps to reproduce:

Upload file: a.h"tml

https://developer.mozilla.org/User:test123bbb#pageFiles


Actual results:

https://developer.mozilla.org/@api/deki/files/6097/=a.h%2522tml


Expected results:

https://developer.mozilla.org/@api/deki/files/6096/=a.html
files with other names are also executed (a.testsetset)
https://developer.mozilla.org/@api/deki/files/6100/=a.testsetset
Attachments (files) were deleted, so:
PoC:
Add attachments:
File name: index.test
content:

<html>
<body>
<script>
alert(document.cookie);
</script>
</body>
</html

Click the newly added file and... and we see the cookies
developer.mozilla.org is a wiki actively edited by dozens of people. They probably saw your pages as vandalism and deleted them (they won't have permission to see this security bug).
attachments with .html extensions are sent with content-type text/plain, but unknown types (such as index.test from comment 2) are sent with Content-Type: text/html.

The server also sends "X-Content-Type-Options: nosniff" for IE, and while that's helpful for text/plain using it for text/html pages is pointless.

I don't know if this is an issue with the wiki software or our configuration of the server.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: XSS in Attachments → MDN XSS in Attachments, unknown extensions sent as text/html
Assignee: nobody → lcrouch
Whiteboard: [infrasec:xss][ws:high]
hey luke,  any progress on figuring out a fix for this?  MDN doesn't qualify for the bounty program since its not on the list of bounty sites, but this does look pretty serious.
(In reply to chris hofmann from comment #7)
> hey luke,  any progress on figuring out a fix for this?  MDN doesn't qualify
> for the bounty program since its not on the list of bounty sites, but this
> does look pretty serious.

Copied over from bug 688160:

As far as I know, we haven't gotten any response from the vendor (ie. MindTouch), and our support contract generally prohibits us from fixing the vendor's software ourselves.

In the meantime, we've been rewriting the wiki from scratch in-house. We're getting close, but not there yet. The ultimate fix - or at least, the enabler to fix things like this - will be to replace the vendor's software entirely (bug 756263)
Depends on: 756263
Version: MDN → unspecified
Component: Administration → User management
Fixed when we switched to Kuma.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Adding keywords to bugs for metrics, no action required.  Sorry about bugmail spam.
Keywords: wsec-xss
For bugs that are resolved, we remove the security flag. These haven't had their flag removed, so I'm removing it now.
Group: websites-security
Product: developer.mozilla.org → developer.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.