Issue metadata
Sign in to add a comment
|
Security: ping attribute in href is not following spec, leads to information disclosure
Reported by
vinayend...@salesforce.com,
Aug 12 2016
|
||||||||||||||||||||||
Issue descriptionThis template is ONLY for reporting security bugs. If you are reporting a Download Protection Bypass bug, please use the "Security - Download Protection" template. For all other reports, please use a different template. Please see the following link for instructions on filing security bugs: http://www.chromium.org/Home/chromium-security/reporting-security-bugs NOTE: Security bugs are normally made public once a fix has been widely deployed. VULNERABILITY DETAILS Please provide a brief explanation of the security issue. According to the documentation here: https://www.w3.org/TR/2009/WD-html5-20090423/history.html#hyperlink-auditing "Otherwise, the origins are different and the document containing the hyperlink being audited was retrieved over an encrypted connection The request must include a Ping-To HTTP header with, as its value, the address of the target of the hyperlink. The request must neither include a Referer (sic) HTTP header nor include a Ping-From HTTP header." In simple words, if page is https and there is a href which contains a ping attribute. Both ping and page are of different origins, the Ping-From attribute should not be sent. Sending the Ping-From will lead to information disclosure as it exposes the URL of the document to ping URL. The URL might contain sensitive information (eg: sessionid, CSRF token or a sensitive id) VERSION Chrome Version: Version 51.0.2704.103 (64-bit) + Stable Operating System: Mac OSX El Capitan 10.11.6 but may work in all OS REPRODUCTION CASE Please include a demonstration of the security bug, such as an attached HTML or binary file that reproduces the bug when loaded in Chrome. PLEASE make the file as small as possible and remove any content not required to demonstrate the bug. 1. Create a html file with the following code and upload to any HTTPS site. <html> <a href="https://example.com" ping="https://example2.com">test</a> </html> 2. Use a proxy to see traffic 3. Open the page in https and click on "test" 4. In proxy the following is sent POST / HTTP/1.1 Host: example2.com Connection: close Content-Length: 4 Cache-Control: max-age=0 Origin: https://<HTTPS SITE> Ping-From: https://<HTTPS SITE>/<PAGE> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36 Ping-To: https://example.com/ Content-Type: text/ping Accept: */* Accept-Encoding: gzip, deflate, br Accept-Language: en-US,en;q=0.8 PING 5. As you can see "Ping-From" is included as a header and it exposes the sensitive URL from where it was clicked. FOR CRASHES, PLEASE INCLUDE THE FOLLOWING ADDITIONAL INFORMATION Type of crash: [tab, browser, etc.] Crash State: [see link above: stack trace, registers, exception record] Client ID (if relevant): [see link above]
,
Aug 16 2016
,
Sep 21 2016
Hrm, I'm pretty sure the spec changed and I missed it. Seems reasonable and easy to fix, though! Dropping Restrict-View-SecurityTeam, since this is just a case of spec compliance (or lack thereof).
,
Sep 23 2016
Is there going to a be CVE assigned for this? As this leads to information disclosure of the sensitive document to 3rd party ping URL.
,
Sep 23 2016
+mkwst, any opinion on CVE?
,
Sep 27 2016
,
Sep 28 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/4d0b173423eb7a234d237fad04829ed0dd660820 commit 4d0b173423eb7a234d237fad04829ed0dd660820 Author: japhet <japhet@chromium.org> Date: Tue Sep 27 18:33:59 2016 Cross-origin https->https pings should omit Ping-From header https://html.spec.whatwg.org/multipage/semantics.html#hyperlink-auditing part 4 states that a Ping-From header should only be sent for same origin requests or if the document containing the hyperlink is unencrypted. I think this was regressed accidentally in https://trac.webkit.org/changeset/91306 BUG= 637459 TEST=PingLoaderTest.HTTPSToHTTPS Review-Url: https://codereview.chromium.org/2360753002 Cr-Commit-Position: refs/heads/master@{#421277} [modify] https://crrev.com/4d0b173423eb7a234d237fad04829ed0dd660820/third_party/WebKit/Source/core/BUILD.gn [modify] https://crrev.com/4d0b173423eb7a234d237fad04829ed0dd660820/third_party/WebKit/Source/core/loader/PingLoader.cpp [add] https://crrev.com/4d0b173423eb7a234d237fad04829ed0dd660820/third_party/WebKit/Source/core/loader/PingLoaderTest.cpp
,
Oct 4 2016
Hello! Any more changes expected for this, or can we move it to Fixed? Cheers.
,
Oct 4 2016
This is fixed, though OP asked about a CVE, and I'm not familiar with when that's needed.
,
Oct 7 2016
It won't its way towards CVE consideration until it's marked as fixed, so doing that now :-)
,
Oct 8 2016
,
Dec 12 2016
Any update on CVE?
,
Jan 14 2017
This bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by och...@chromium.org
, Aug 15 2016Labels: Security_Severity-Low Security_Impact-Stable OS-All
Owner: japhet@chromium.org
Status: Assigned (was: Unconfirmed)