I know people who actually implement this are going to have their heads screwed on around the right way, but having a page where you know you can generate server processing, and that is potentially not going to have much security around it screams out to me to be a good place to start an attack from.
Especially as the spec is a bit vague about exactly what happens when (no head specified for example, doesn't say about including cookies or any other information). Also, fiesta.cc's CSP Report URI returns a response that says to keep the connection open.
And, if you manage to get a script injected to a popular page, the site itself acts as a distribution system to enable distribution to multiple users.
Something about this says it's not been thoroughly thought through to me.
On that page you'll notice it mentions "request-headers". That was in FF4 and FF5, but was removed in FF6 because of something I reported.
The headers sent in the report included "Proxy-Authorization", so it was possible to steal web proxy credentials by forcing a policy violation on your site. Chromes implementation didn't include the headers from the start. For more info:
I know people who actually implement this are going to have their heads screwed on around the right way, but having a page where you know you can generate server processing, and that is potentially not going to have much security around it screams out to me to be a good place to start an attack from.
Especially as the spec is a bit vague about exactly what happens when (no head specified for example, doesn't say about including cookies or any other information). Also, fiesta.cc's CSP Report URI returns a response that says to keep the connection open.
And, if you manage to get a script injected to a popular page, the site itself acts as a distribution system to enable distribution to multiple users.
Something about this says it's not been thoroughly thought through to me.