X-XSS-Protection parser shoud reject '0; mode=block'

X-XSS-Protection parser shoud reject '0; mode=block'

A recent study[1] notes that ~480 sites serve the invalid header
'X-XSS-Protection: 0;mode=block'. We currently accept this header as
disabling the XSSAuditor. This CL changes our behavior to reject any XSS
protection header that begins with 0 and has any other non-whitespace
character after the 0.

[1]: http://www.veracode.com/blog/2013/11/security-headers-on-the-top-1000000-websites-november-2013-report/

BUG=323853

[Mike West, 2013-11-27 12:01:33]

Hey Tom! Mind taking a look at this slight modification to XSSAuditor parsing?

-mike

[Tom Sepez, 2013-11-27 18:09:53]

> -mike
The code LGTM, but I'm not sure what the right behaviour should be. Some folks
have wanted to specify "0; report=..", for example, which we can't support at
the moment.  This change would make that harder.  Also, its less future-proof if
someone wants to add a new directive that might interact with the "0" option.

[Tom Sepez, 2013-11-28 00:04:46]

What about accepting "x-xss-protection: 0;" ?

[Tom Sepez, 2013-11-28 00:09:15]

https://codereview.chromium.org/90993003/diff/1/Source/platform/network/HTTPP...
File Source/platform/network/HTTPParsers.cpp (right):

https://codereview.chromium.org/90993003/diff/1/Source/platform/network/HTTPP...
Source/platform/network/HTTPParsers.cpp:376: return AllowReflectedXSS;
I'm almost inclined to suggest getting rid of the early returns and parse out
all the ;-separated options, and in the end barf if AllowReflectedXSS &&
modeDirectiveSeen and so forth.