[webkit-gtk] Client side security policy?
Michael A. Peters
mpeters at mac.com
Thu Mar 18 15:53:10 PDT 2010
David P. Reed wrote:
> To be honest, I hate the idea that one should disable large parts of
> just makes web designers have to deal with users demanding all forms of
> crippling be supported.
CSP only disables what the web master states (via a header) is not used
and therefore suspicious if it is in the page.
The point is to provide clients with protection against XSS.
video, object, and CSS on my web site only originate from my web site.
So if I have an input validation error or other hole in the software I
comes from a source not listed by my CSP policy and block it.
Furthermore, browsers can report the blockage via post to a specified
URL on my server so that I (the web master) will know there was a policy
violation and can either correct the situation (by allowing the resource
in my CSP or by taking care of the injected XSS).
Web masters that do not send a header don't get anything blocked
regardless of origin. No CSP policy sent in a header means no resources
blocked. So CSP does not disable any emerging standard capabilities.
If CSP is implemented in web kit browsers, that should of course be the
default unless the user specifically wants to tighten down their browser
by setting their own policy of what they allow and from where, which is
functionality provided in FireFox for some time via NoScript, only doing
it as a default CSP policy would allow even better control.
For example, I could set a policy white lising img csss from anywhere
the same server of the page (policy of self) and only block those from
other domains that I haven't white-listed.
These new technologies are nice but at the same time give vectors of
attacking users and doing things with the users browser that the user
does not want done and things that are down right malicious.
More information about the webkit-gtk