X-XSS-Protection: allow report URL containing semicolon
Reported by
yurn...@gmail.com,
Mar 25 2018
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36 Steps to reproduce the problem: Response headers contain: X-XSS-Protection: 1; mode=block; report="http://foo.com/bar.jsp;JSESSIONID=1234567" What is the expected behavior? Parse report URL as http://foo.com/bar.jsp;JSESSIONID=1234567 What went wrong? Error in developer console: Error parsing header X-XSS-Protection: 1; mode=block; report="http://foo.com/bar.jsp;JSESSIONID=1234567": unrecognized directive at character position 46. The default protections will be applied. Did this work before? N/A Does this work in other browsers? N/A Chrome version: 65.0.3325.181 Channel: stable OS Version: 10.0 Flash Version: If report URL doesn't contain special characters, header can be written without escape-sequence: X-XSS-Protection: 1; mode=block; report=http://foo.com/bar.jsp But if your header contains special characters, for example, semicolon (which separates key=value pairs), you need to escape value. As per RFC2616, value can be escaped as quoted-string. So I'm quoting my URL: X-XSS-Protection: 1; mode=block; report="http://foo.com/bar.jsp;JSESSIONID=1234567" But then Chromium informs me (in developer console) that it couldn't parse header because it didn't follow RFC2616 and instead of parsing quoted value as quoted-string it parsed it as a plain string, found semicolon inside it and treated as a key=value separator: Error parsing header X-XSS-Protection: 1; mode=block; report="http://foo.com/bar.jsp;JSESSIONID=1234567": unrecognized directive at character position 46. The default protections will be applied.
,
Mar 26 2018
ParseXSSProtectionHeader tokenizes the URL using semicolon as a delimiter. If you URL-encode the semicolon (using %3b) does the report submit as expected?
,
Mar 27 2018
Thanks for the report! As Eric suggests, URL-encoding the report URL should do the trick today. I suppose we could change the parser to accept strings. That shouldn't be terribly difficult, if someone's interested in doing it.
,
Mar 27 2018
In this case semicolon is a delimiter of special path parameters (the most widely known is JSESSIONID holding session identifier for Java EE). Unfortunately, URL-escaping for semicolon as path-parameter delimiter breaks it. That's the same if you escape & as a query parameter delimiter - it would break query parameter. Imagine you have normal query parameters: foo.com?bar=1&foobar=2. So there you have two parameters: bar="1" and foobar="2". What would happen if you escape ampersand? In our example: foo.com?bar=1%26foobar=2. This would give just one parameter: bar="1%26foobar=2". So escaping a delimiter is required for parameter values containing this delimiter. So, URL-escaped parameter delimiter stops being parameter delimiter. It applies both to normal query parameters (delimiter is '&') and to path parameters (delimiter is ';').
,
Mar 27 2018
> ParseXSSProtectionHeader tokenizes the URL using semicolon as a delimiter. This is against best-practice of RFC2616 (https://tools.ietf.org/html/rfc2616) which says that in complex header values semicolon separated token value may be either a token or quoted-string: ";" token [ "=" ( token | quoted-string ) ]
,
Mar 27 2018
We should probably fix this, eventually, given the report of at least one real-world server that parses paths in this manner. It's not a high priority, though.
,
Mar 27 2018
Any Java-based web-server parses paths in this manner. The most popular one is Apache Tomcat. Also JBoss/WildFly, Jetty, Glassfish, WebLogic, WebSphere, etc.
,
Mar 27 2018
Yeah, esp. given https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/network/HeaderFieldTokenizer.h, using our own hand-rolled tokenizer for this one header seems wrong and error-prone. I'll try banging this out just for the code savings, if nothing else.
,
Mar 30 2018
,
Apr 6 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/92a1603f408da31134838379b7fc7933245b553c commit 92a1603f408da31134838379b7fc7933245b553c Author: Tom Sepez <tsepez@chromium.org> Date: Fri Apr 06 16:55:44 2018 Parse X-XSS-Protection header with HeaderFieldTokenizer Bug: 825557 Change-Id: Ibde6fc555aa9e35e1896a2eb5ecccdc80869c8ce Reviewed-on: https://chromium-review.googlesource.com/985026 Commit-Queue: Tom Sepez <tsepez@chromium.org> Reviewed-by: Mike West <mkwst@chromium.org> Cr-Commit-Position: refs/heads/master@{#548819} [modify] https://crrev.com/92a1603f408da31134838379b7fc7933245b553c/third_party/WebKit/LayoutTests/http/tests/security/xssAuditor/malformed-xss-protection-header-1-expected.txt [modify] https://crrev.com/92a1603f408da31134838379b7fc7933245b553c/third_party/WebKit/Source/platform/network/HTTPParsers.cpp [modify] https://crrev.com/92a1603f408da31134838379b7fc7933245b553c/third_party/WebKit/Source/platform/network/HTTPParsersTest.cpp
,
Apr 6 2018
,
Apr 6 2018
Thanks! |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by ajha@chromium.org
, Mar 26 2018