New issue
Advanced search Search tips

Issue 686317 link

Starred by 3 users
Status: WontFix
Owner: ----
Closed: Feb 2017
Cc:
ajha@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

Content-Security-Policy-Report-Only frame-ancestors is case sensitive

Reported by j...@dashplatform.com, Jan 28 2017 
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36

Steps to reproduce the problem:
1. Create a page with a Content-Security-Policy-Report-Only header
2. set frame-ancestors to something case sensitive, example www.Foo.com
3. Try to frame your page from www.foo.com

What is the expected behavior?
There should be no CSP violation and no report

What went wrong?
It appears that Chrome is comparing the allowed URL to the actual URL using a case sensitive compare. URLs should not be case sensitive. This does not happen in the latest version of Firefox.

Did this work before? N/A 

Chrome version: 55.0.2883.95  Channel: n/a
OS Version: OS X 10.12.2
Flash Version: Shockwave Flash 24.0 r0

Here is my example (going to the page http://thenzone.com/calendar/)

Note that I hope to fix this problem by updating the CSP to NOT have any upper case letters...

{  
   "csp-report":{  
      "document-uri":"https://apps.dashplatform.com/dash/?cid=nzone&action=schedule_location&noheader=1&FacilityID=1",
      "referrer":"",
      "violated-directive":"frame-ancestors 'self' http://*.theNzone.com https://*.theNzone.com",
      "effective-directive":"frame-ancestors",
      "original-policy":"frame-ancestors 'self' http://*.theNzone.com https://*.theNzone.com; report-uri https://4f34b619bf945bdf2a28673761d10490.report-uri.io/r/default/csp/reportOnly",
      "blocked-uri":"https://apps.dashplatform.com/dash/?cid=nzone&action=schedule_location&noheader=1&FacilityID=1",
      "status-code":0
   }
}

Comment 1 by nyerramilli@chromium.org, Feb 1 2017

Labels: Needs-Milestone

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

Cc: ajha@chromium.org
Components: Blink>SecurityFeature
Labels: Needs-Feedback
Tested this on Mac OS 10.12.2 on the latest(56.0.2927.87) and the reported version: 55.0.2883.5. Upon entering 'theNzone.com/calendar/' into the omnibox and hitting ENTER the URLs converts to 'thenzone.com/calendar/'.


jeff@: Could you please confirm the expected behavior here. As on Firefox as well the URL converts to thenzone.com/calendar/ 

Labelling with respective bug component for help in further triaging.

Comment 3 by j...@dashplatform.com, Feb 9 2017 

Hi

SUMMARY
I'm an idiot, there is probably no bug here. No action necessary. Sorry for the distraction.

DETAILS
The issue is not with case-sensitive comparison. I should have done a better job isolating this issue before entering a bug report. I also should have kept a link around so I could add details after I figured that out and not distracted you folks. I had to wait for an email to be able to follow up with this confession.

The issue turned out to be that the specified frame ancestors of http://*.theNzone.com https://*.theNzone.com" did not match http://thenzone.com and that triggered the report. I'm not sure what the CSP spec says on that match and whether *.foo.com should match foo.com. Rather than spend a lot of time researching if Chrome is following the spec (other browsers are far worse at dealing with frame-ancestors by the way) I fixed the problem by adding code to set frame-ancestors to all permutations of scheme and the pattern <domain>, *.<domain>, <any specified prefix>.<domain>

Here is a bit more background. Our customer enter their website in our system as www.theNzone.com (note the cap N). We should not allow caps by the way. There is 301 redirect on www.thenzone.com to thenzone.com. Initially, we were only specifying the customer website in frame-ancestors (with both http and https schemes) and that generated the above report.

To see a live instance of this, go to www.theNzone.com/calendar and search for the framing of https://apps.dashplatform.com/dash/index.php?...

Comment 4 by l...@chromium.org, Feb 13 2017

Components: -Platform>DevTools
Thanks for the report.  Removing the DevTools label.
Project Member

Comment 5 by sheriffbot@chromium.org, Feb 21 2017

Labels: -Needs-Feedback Needs-Review
Owner: ajha@chromium.org
Thank you for providing more feedback. Adding requester "ajha@chromium.org" for another review and adding "Needs-Review" label for tracking.

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

Comment 6 by kkaluri@chromium.org, Feb 22 2017

Labels: Needs-Feedback
Owner: ----
jeff@ for further triage could you please help us with the screen-cast for this  issue.

Thank You...

Comment 7 by j...@dashplatform.com, Feb 22 2017 

kkaluri@ I would be happy to help with screen cast. I'm available most days and times. If you give me two options, I'm sure I can make one work.

Comment 8 by j...@dashplatform.com, Feb 22 2017 

PS - I'm in the Seattle area so I'm on PST

Comment 9 by mkwst@chromium.org, Feb 23 2017

Status: WontFix (was: Unconfirmed)
jeff@: Just `domain.com` and `*.domain.com` should be enough. If I could go back in time and just make `*.whatever` match the apex as well as subdomains, I think I would, but this is the behavior that we settled on.

Thanks for the report! I'm closing this out, as I believe the behavior is as intended. If the case-sensitivity is indeed an issue (it doesn't look like it should be based on the code), please re-open. :)

Comment 10 by j...@dashplatform.com, Feb 23 2017 

mkwst@
Makes sense, if there is a simple workaround, no need to fix. There is no case-sensitivity issue, that was my buffoonery. Keep up the great work folks, Chrome rocks!!
►

Sign in to add a comment