New issue
Advanced search Search tips

Issue 835807 link

Starred by 1 user
Status: WontFix
Owner:
tsepez@chromium.org
Closed: Apr 2018
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

FORM POST with input type="text" and value contains iframe

Reported by vajon...@gmail.com, Apr 23 2018 
UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36

Steps to reproduce the problem:
1. Insert a value that looks like this "<iframe ... ></iframe>" in input text or textarea.
2. Submit the POST to a new page display with the "<iframe ... ></iframe>" embedded.
3. As a result: ERR_BLOCKED_BY_XSS_AUDITOR

What is the expected behavior?
1. Insert a value that looks like this "<iframe ... ></iframe>" in input text or textarea.
2. Submit the POST to a new display with the "<iframe ... ></iframe>" embedded.
3. Displays the page with "<iframe ... ></iframe>" included.

Works with Mozilla Firefox and Microsoft Edge 

What went wrong?
1. As a result: ERR_BLOCKED_BY_XSS_AUDITOR
2. Using "reload this page" button.
3. Views the page with the requested result but PHP defined $_SESSION is damaged.

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 65.0.3325.181  Channel: stable
OS Version: 10.0
Flash Version: 

If you need more info contact vajonny0@gmail.com

Comment 1 by phistuck@gmail.com, Apr 23 2018

Components: Blink>SecurityFeature>XSSAuditor
Is the new page trying to basically render the input text, or is it an iFrame unrelated to the input?
For the former, I believe this is by design and you will have to explicitly disable the XSS auditor by adding this header to your response headers -
X-XSS-Protection: 0
See https://www.virtuesecurity.com/blog/understanding-xss-auditor/ for details.

For the latter, it might be a mis-detection. If those strings (the input iFrame code and the rendered iFrame code) do not happen to be the same, it might indeed be a bug.


If you confirmed that this is a mis-detection, please, share a test case (an online URL is preferred) that can be investigated.

Comment 2 by susan.boorgula@chromium.org, Apr 23 2018

Labels: Needs-Triage-M65

Comment 3 by jochen@chromium.org, Apr 24 2018

Owner: tsepez@chromium.org
Status: Assigned (was: Unconfirmed)

Comment 4 by vajon...@gmail.com, Apr 24 2018 

A live example at: http://forum.virtual-haus.com/video_emb/

at the moment:
//header("X-XSS-Protection: 0;");

Comment 5 by phistuck@gmail.com, Apr 24 2018 

I do not think there is anything to do here, it does not seem to be a bug.
You are simply rendering whatever it is that the user is typing, even if they type <script>alert('')</script>.
I think you will have to add the header and be done with it, because this is exactly what the XSS auditor is designed to block.

@tsepez, any thoughts?

Comment 6 by vajon...@gmail.com, Apr 24 2018 

OK, thanks!
I will use it without XSS auditor for now ...

Comment 7 by tsepez@chromium.org, Apr 26 2018

Status: WontFix (was: Assigned)
►

Sign in to add a comment