New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 801598 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Buried. Ping if important.
Closed: Jan 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

Loading resources with wrong content-type as style is possible although nosniff is sent with the resource

Reported by x.schin...@googlemail.com, Jan 12 2018

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36

Steps to reproduce the problem:
1. Add <link onerror="alert('error')" rel="stylesheet" href="<URL to resource which is sent with nosniff-header and wrong content type>"> to the header of some HTML-page
2. Navigate to this page in Chrome
3. No popup is shown

What is the expected behavior?
Loading a style with wrong content-type should be blocked when the header "X-Content-Type-Options: nosniff" is sent with the resource.
Firefox triggers the error event and therefore the popup is shown.

What went wrong?
error event is not triggered when loading a resource with wrong Content-Type header although "X-Content-Type-Options: nosniff" is sent

Did this work before? N/A 

Chrome version: 63.0.3239.132  Channel: stable
OS Version: 10.0
Flash Version:
 
Labels: Needs-Triage-M63

Comment 2 by tkent@chromium.org, Jan 15 2018

Components: -Blink Blink>CSS Blink>SecurityFeature
Cc: sc00335...@techmahindra.com
Labels: Needs-Feedback Triaged-ET
x.schindel@ Thanks for the issue.

Tested this issue on Windows 10 and Mac OS 10.12.6 using the latest Canary 65.0.3321.0 and Stable 63.0.3239.132 and unable to reproduce this issue by following the below steps.

1. Launched Chrome and opened the html file which has <link onerror="alert('error')" rel="stylesheet" href="<URL to resource which is sent with nosniff-header and wrong content type>"> appended to the content.
2. Can observe the error popup seen. Same behavior is observed in firefox.
Attached is the screen cast for reference.

Request you to please check and confirm if anything is missed from our end in reproducing the issue.

Also request you to please retry the issue on a new chrome profile without any flags/extensions and update the thread with the observations.

Thanks..


801598.webm
2.5 MB View Download
You need to use a 'real' URL instead of the placeholder "<URL to resource which is sent with nosniff-header and wrong content type>", e.g. http://www.nwebsec.com/HttpHeaders/SecurityHeaders/XContentTypeOptions/NoSniff. For this URL no error popup comes up.
Project Member

Comment 5 by sheriffbot@chromium.org, Jan 16 2018

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding requester "sc00335628@techmahindra.com" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 6 by mkwst@chromium.org, Jan 16 2018

Owner: mkwst@chromium.org
Status: Assigned (was: Unconfirmed)
We shipped `nosniff` for CSS along with 64, which is in beta right now. Would you mind testing your code against Canary? I suspect you'll find that it's working there. If not, we can take a closer look.

Comment 7 by shend@chromium.org, Jan 17 2018

Labels: Hotlist-Interop
Tested with Canary: works fine / as expected there.

Comment 9 by mkwst@chromium.org, Jan 22 2018

Status: Fixed (was: Assigned)
Thanks! Closing this out, as the behavior will be released on the usual schedule.

Sign in to add a comment