These forums are currently read-only due to receiving more spam than actual discussion. Sorry.

It is currently Sat Dec 02, 2017 4:03 pm Advanced search

CSP feedback

Do you think the HTML spec should do something differently? You can discuss spec feedback here, but you should send it to the WHATWG mailing list or file a bug in the W3C bugzilla for it to be considered.

CSP feedback

Postby RobLev » Wed Jul 20, 2011 2:26 pm

Hello,

Firstly, I'm new to these forums, this is my first post, so apologies in advance for any mistakes I might make.


I've been thinking for some time about XSS attacks and ways to mitigate them, and two observations struck me:

(1) XSS attacks nearly always occur in the <body> block of a html document, and not the <head> block. This is because the attack surface of the <body> is generally larger than the <head> block, and user-generated content is usually (but not always) placed in the <body> of a document.

(2) With the rise of Javascript frameworks like JQuery, it is becoming best practice to separate the code from the content. All legitimate code can be placed in the <head> block without too much effort, for many sites.

So I came to the conclusion that adding a simple html mechanism to allow an author to tell a user-agent that scripts should only be executed from the <head> block would give a powerful weapon to authors to prevent XSS exploits. Authors would write their own scripts, include them in their <head> block, and instruct the user-agent that any scripts in the <body> block should be ignored. This would be easy implement on the user-agent side and easy to use on the author side. And it would degrade gracefully in older user-agents.

Excited with this idea, I set out to find the right people to contact to get this moving, which eventually led me to WHATWG. I did some research on the mailing list archives, and realised that other people have had my ideas first (many years ago), and are well on the way to implementing them. Oh well, never mind! So I've read about sandboxing on IFrames, and the CSP unofficial draft, and clearly these efforts are solving bigger problems in a more comprehensive way, which largely encompass my ideas. Well done to all involved on these major efforts.

But... there are a few things that strike me.

Firstly, whatever is done to mitigate XSS should be really really simple to use and understand by authors. I'm not sure that CSP hits the sweet spot between usability and security; I am worried it is going to be too difficult to use for the mass market, and hence fail in part of its mission.

For me, the instruction to inform a user-agent that a script should be ignored in the body should look something like:

Code: Select all
<head>
<security request="NoBodyScripts"></security>
</head>


this would be intuitive to most authors, and would stop an awful lot of attacks.

How can I achieve the same effect with CSP? I may have it wrong, but the only way I can see to implement this with CSP would be to do something like:

Code: Select all
<head>
<meta http-equiv="X-Content-Security-Policy" script-nonce="[a strong dynamic random token]">
</head>

...and include this nonce with every script on the page.


Secondly, creating and implementing a protocol such as CSP is only part of the story to really eliminate XSS in the wild. The social aspect needs to be thought through. I think the best way to encourage authors to use it would be to show some consistent visual feedback given to users that their site has implemented "Web Security" and that the user-agent is enforcing it. This would then start a virtuous feedback cycle where more sites implement the security, putting pressure on more user-agents to implement it etc.

Users are already used to a padlock symbol showing a secure socket connection; a similar common symbol could be recommended to user-agents to display to users when CSP is invoked. This should be part of the spec, in my opinion.

Anyway, hope this wasn't too off topic for a first post!
thanks,
-rob
RobLev
<h6>
 
Posts: 2
Joined: Wed Jul 20, 2011 11:33 am

Re: CSP feedback

Postby Xdega » Wed Jul 20, 2011 7:06 pm

Great post. I definitely agree that XSS is a severe security risk in this growing JS day and age. But it is also a relatively well known security issue vs say CSRF/XSRF (Cross-site Request Forgery).

I do believe that proper coding should be where the solution lies, sanitizing any form of input so XSS is never possible as output.

I would definitely recommend you bringing up your ideas to the mailing list. There are several people that use the mailing list and not the forums.
Xdega
<h2>
 
Posts: 124
Joined: Tue Mar 01, 2011 6:30 pm
Location: USA

Re: CSP feedback

Postby RobLev » Thu Jul 28, 2011 10:11 pm

Thanks,
I have posted onto the mailing list as you advised.

Proper sanitation of user input will solve all XSS problems, but it is a fragile solution; it relies on every website correctly sanitising every source of user input all the time. Having a second line of defence (i.e. scripts not working in the body) seems sensible to me.

It's analogous to the problem of buffer overruns, where the correct solution is for all C-style programs to correctly allocate memory for buffers. But because a single buffer overrun can have such a terrible security impact, more levels of defence are introduced such as address space layout randomisation. We know that we cannot expect perfect security from all code paths.
RobLev
<h6>
 
Posts: 2
Joined: Wed Jul 20, 2011 11:33 am


Return to Feedback on the Specs

Who is online

Users browsing this forum: No registered users and 1 guest