933413 - report-uri directive of Content-Security-Policy does not follow RFC-3986

Status: RESOLVED WORKSFORME

(Core :: DOM: Security, defect)

Description

[Scott]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.101 Safari/537.36

Steps to reproduce:

Specifically a report-uri in a valid CSP policy using a different port from the originating document.  

Exp.

CSP policy is loaded on http://www.example.com and the following is sent in a response:

Content-Security-Policy: default-src 'self'; report-uri http://othersite.com:8001/csp.php


Actual results:

Warning message is displayed in Console:

Content Security Policy: can't use report URI with different port from originating document:


Expected results:

The report should have been sent to the host and port specified in the report-url.  

According to both the CSP 1.0 final document and CSP 1.1 draft document, RFC-3968 is how report-uri syntax should interpreted.  The following was pulled from the CSP 1.0 specification:  

The report-uri directive specifies a URI to which the user agent sends reports about policy violation. The syntax for the name and value of the directive are described by the following ABNF grammar:

directive-name    = "report-uri"
directive-value   = uri-reference *( 1*WSP uri-reference )
uri-reference     = <URI-reference from RFC 3986>


If we look at RFC 3968, it says that a URI can have a port value.  I read the whole section on report-uri in CSP 1.0 and there is no mention that the report-uri must match the same port.  Since it is not in the specification, it should not behave the way it is currently.  THis is making it impossible for me to setup a report aggregator on a non standard report for all the sites I manage that use CSP.

Comment 1

[Liz Henry (:lizzard) (relman/hg->git project)]

Scott or anyone else, I just came across this issue while cleaning up some Firefox 28 unconfirmed bugs. Is this still the case? I could go set up a site and dig into the current CSP but it seems best to ask people who likely already know.

Comment 2

[Ian Melven :imelven]

This might be a dupe of bug 843311 which is fixed in 29.

Comment 3

[Scott]

Hey Ian,

It's similar to bug 84331 except with this issue it's not the SCHEME mismatch that's causing the issue, it's the port number. 

If you are sending CSP violations to a host that is listening on a different port number, the reports do not get sent.

Comment 4

[Sid Stamm [:geekboy or :sstamm]]

The patch for bug 843311 removed port restrictions, too.  Is this still a problem in nightly?
https://hg.mozilla.org/mozilla-central/rev/84802a40e62d#l1.35
https://hg.mozilla.org/mozilla-central/rev/84802a40e62d#l1.107

Comment 5

[Liz Henry (:lizzard) (relman/hg->git project)]

HI there. This bug is still showing up in my triage queues as UNCONFIRMED. Sid, is there anyone who we should need-info into this bug to move it along and get it resolved one way or the other? Thanks!

Comment 6

[Sid Stamm [:geekboy or :sstamm]]

Scott, is this still a problem on nightly?

Comment 7

[Liz Henry (:lizzard) (relman/hg->git project)]

Matt, could you take a look at this to see if it's still a problem in Nightly? (Given that I think Sid thinks it would be a problem if it were a problem.)  :)

Comment 8

[Matt Wobensmith [:mwobensmith][:matt:]]

The error appears in Fx28 but not in Fx29 and onwards. As Sid says in comment 4 - it was fixed in that patch.

Scott, try this again and confirm. Do you still see an error message in Fx29, and does the report get sent when its destination host contains a different port?

Comment 9

[Sid Stamm [:geekboy or :sstamm]]

I'm gonna close this WORKSFORME since Matt indicates it is already fixed.  Scott, please ping us or reopen this bug if it's still a problem.