Closed Bug 1403146 Opened 8 years ago Closed 8 years ago

DOMParser allows to set cookies

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Version:
55 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1325923

People

(Reporter: alex, Unassigned)

Details

(Keywords: sec-moderate, sec-other, Whiteboard: potential for sec-high vulns in web apps using this)

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36 Steps to reproduce: I reported some time ago a possible vulnerability in PDF.js, which concerns DOMParser.parseFromString with a user controlled XML structure: https://bugzilla.mozilla.org/show_bug.cgi?id=1386676 This did not concern Firefox but I had another look at the behavior of this parser and discovered the following: <script> meta = `<html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>Title of document</title><meta http-equiv='Set-Cookie' content='pppt=qqq' /> </head> <body> some content </body> </html>` var parser = new DOMParser(); meta = parser.parseFromString(meta, 'application/xml'); </script> This will set the cookie pppt=qqq on the current domain. I checked and Firefox is the only browser with this behavior. As an example, PDF.js is vulnerable by this behavior and therefore a specially crafted PDF can set a cookie (they will remove DOMParser in their next patch). I am sure other applications, which require DOMParser, can be attacked the same way. best regards, insertscript Actual results: Firefox sets the cookie pppt=qqq on the current domain. Expected results: No cookie should be set.
Example URL: http://84.112.235.224/pdfjsexample.php This will actually set a cookie for the domain pdf.js, as it is using the default "file location" of PDF.js, when it is used natively by Firefox. best regards, insertscript
Group: firefox-core-security → dom-core-security
Component: Untriaged → DOM
Product: Firefox → Core
This flaw doesn't exactly hack _Firefox_ so we'll rate it sec-moderate, but it opens the door to potential serious vulnerabilities in web apps depending on how they use this and what sorts of cookies they use.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: sec-moderate
Whiteboard: potential for sec-high vulns in web apps using this
Keywords: sec-other
There is some discussion about killing <meta> SetCookie globally https://github.com/whatwg/html/issues/1950#issuecomment-256273444 But at the very least we should consider DOMParser a "cookie-averse" document and block it in this case specifically. Anne: does that make sense?
Flags: needinfo?(annevk)
Yeah, I don't understand why it isn't already failing now that we fixed the SVG case. I guess we implemented the wrong fix?
Flags: needinfo?(annevk)
This looks like a dup of bug 1325923 to me, but it's hard to tell because nothing here says what versions are claimed to have the problem. Bug 1325923 is fixed on beta 57 and nightly 58. In particular, I stepped through the provided testcase on nightly. As expected, mWindow is null, GetInnerWindow() returns null, IsCookieAverse() returns true, and the cookie is not set. So I assume the report in comment 0 is against a version before 57...
insertscript, what version of Firefox were you testing?
Flags: needinfo?(alex)
With 55.0.3 I think but I just updated to 56.0 and it still works :) best regards
Flags: needinfo?(alex)
Sorry you are correct. The behavior is fixed with Nightly!
Great, thanks for confirming!
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
Hello! Can I already share this information or should I wait until the fixed DOMParser is used in the stable version of Firefox? PDF.js already moved away from DOMParser in the latest version and is using SimpleXMLParser instead. best regards, insertscript
Please wait until Firefox 57 ships, which includes the fix. That should happen mid-November.
Component: DOM → DOM: Core & HTML
Group: dom-core-security
You need to log in before you can comment on or make changes to this bug.