New issue
Advanced search Search tips

Issue 690028 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: Feb 2017
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 3
Type: Bug



Sign in to add a comment

XSS Auditor Bypass via IFRAME srcdoc attribute

Reported by mishra.d...@gmail.com, Feb 8 2017

Issue description

UserAgent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0

Steps to reproduce the problem:
1.HTML injection on src parameter

Code : <iframe src=""srcdoc="<script>alert('tab')</script>">

Works for me in Chrome Beta in Linux.

What is the expected behavior?

What went wrong?
This  bug  is  based  on  a  misuse  of  srcdoc  attribute  of  iframe
tag,  included  in  html5 definition.  To  perform an  XSS  attack  on
Google  Chrome  Browser  using this  bug,  the website must  include an
 iframe  and must be able to read any attribute of this element from
http parameters (GET/POST) without applying any charset filter. Then, in
the iframe parameter,  the  srcdoc  attribute  may be included with
javascript  code. Chrome can not filter it and will be executed.

Did this work before? N/A 

Chrome version: <Copy from: 'ab57.0.2987.21 (Official Build) beta (64-bit)out:version'>  Channel: beta
OS Version: 
Flash Version: Shockwave Flash 24.0 r0

 
Components: Blink>SecurityFeature
Labels: -Type-Bug-Security -Restrict-View-SecurityTeam Type-Bug
Summary: XSS Auditor Bypass via IFRAME srcdoc attribute (was: XSS filter bypass in Chrome Beta.)
Thanks for the report!

Chrome does not track XSS Auditor bypasses as security vulnerabilities. 

https://www.chromium.org/Home/chromium-security/security-faq#TOC-Are-XSS-filter-bypasses-considered-security-bugs-


Comment 2 by ajha@chromium.org, Feb 14 2017

Labels: Needs-Triage-M57

Comment 3 by mkwst@chromium.org, Feb 14 2017

Labels: -Pri-2 Pri-3
Owner: tsepez@chromium.org
Status: Available (was: Unconfirmed)
Tom, WDYT?

Comment 4 by tsepez@chromium.org, Feb 14 2017

I'd need to know how the payload is encoded in the URL in addition to what appears to be the page content reported in the original description.  I will try a few permutations to see if I can reproduce it, but srcdoc is expected to be handled by XSSAuditor, which leads me to believe that there may be some other unexepcted server-side transformation going on ...

Comment 5 by tsepez@chromium.org, Feb 14 2017

Status: WontFix (was: Available)
In fact, we test this exact case via

https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/http/tests/security/xssAuditor/iframe-srcdoc-property-blocked.html

In this case, the payload is encoded as:

   q=%22srcdoc=%22<script>alert(0)</script>

So I'd need to see the exact URL to make any progress. 

Marking as wontfix for now, but please do re-open if you can provide me with more details. 
   

Hi Tom , 

I believe if the payload are not encoded as well the tab gets xss.

Code :
<!DOCTYPE html>
<html>
<head>
<script>
if (window.testRunner) {
    testRunner.dumpAsText();
    testRunner.setXSSAuditorEnabled(true);
}
</script>
</head>
<body>
<p>Catch injected srcdoc properties when there is punctuation enabing the auditor</p>
<iframe src=""srcdoc="<script>alert('tab')</script>">
</iframe>
</body>
</html>

Attaching test case for reference , request yoy to please have a look. 

poc.PNG
68.6 KB View Download

Comment 7 by tsepez@chromium.org, Feb 15 2017

The chrome XSSAuditor only filters reflected XSS, e.g. 
  https://en.wikipedia.org/wiki/Cross-site_scripting#Reflected_.28non-persistent.29

So if the payload does not appear in the URL or post paramters, it has no hope of being caught.  This is why I've asked for the URL (or a dump of the POST parameters if that'w where its from) in addition to the page text which you have provided.  You can get the later from the chrome developer tools network tab.

Until then, there isn't anything to go on.  Thanks for your understanding.

Sign in to add a comment