Misleading security state for data urls
Reported by
jleedev@gmail.com,
Feb 13 2017
|
||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.37 Safari/537.36 Steps to reproduce the problem: Type data:text/html,Text<b>Bold</b> in the omnibox and hit enter to navigate to a data URI. Then hit CTRL+Shift+I to open the Dev tools and look at the Security tab. What is the expected behavior? about:blank and plain http give "This page is not secure." with no further elaboration. Absent a password or credit card field, data urls should do the same. What went wrong? All data urls now give "This page includes a password or credit card input over HTTP.", which is wrong on two counts. All data urls say "Not Secure" in the omnibox, which makes sense for HTML pages but is a bit odd for images and the like. This is similar to the distinction made for passive mixed content. Did this work before? Yes Chrome version: 57.0.2987.37 Channel: beta OS Version: OS X 10.12.3 Flash Version: Marking all data urls as verbosely non-secure makes sense given the phishing usage, but it would be nice to restrict that to HTML pages.
,
Feb 13 2017
Thanks for the report. The DevTools security panel is showing a misleading message about password/credit card input, which should be fixed. Showing "Not Secure" in the omnibox for data urls seems to serve to differentiate "Not trustworthy" data urls from "Potentially trustworthy" ones like about:blank, see spec: https://w3c.github.io/webappsec-secure-contexts/#is-url-trustworthy To your other point about using the non-secure label solely for HTML pages, there's discussion about possibly deprecating the ability to navigate to data urls. You can keep track of it here: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/GbVcuwg_QjM
,
Feb 14 2017
@ luoe: Gentle ping, do we have any update on this issue. Thanks.!
,
Feb 15 2017
I can reproduce this on stable 56.0.2924.87 Mac, so this might not be a regression. I would still like to fix the message.
,
Feb 20 2017
Removed the Needs-Triage-M57 as per the above comment # 4 and marked to M58. luoe@: Please let us know the Steps & urls to verify once its Fixed so as to verify from TE end if it can be verified.
,
Feb 21 2017
@lgarron, is updating the message text to something like "This page is an untrustworthy or includes a password or credit card input over HTTP...." the only change required?
,
Feb 21 2017
This is one of the edge cases we have. > @lgarron, is updating the message text to something like "This page is an untrustworthy or includes a password or credit card input over HTTP...." the only change required? Not quite; I'll leave this to elawrence@
,
Feb 21 2017
@elawrence, wdyt?
,
Mar 1 2017
,
Mar 1 2017
The regression was introduced here: https://codereview.chromium.org/2648353005/ The problem is that we started using security_state::HTTP_SHOW_WARNING for data: URIs while leaving in place logic that expected it only for password and credit card input fields (https://cs.chromium.org/chromium/src/components/security_state/content/content_utils.cc?type=cs&q=IDS_PRIVATE_USER_DATA_INPUT_DESCRIPTION+package:%5Echromium$&l=187). The straightforward fix for this is to update that function so that it checks specifically for the private data bits: if ((security_info.security_level == security_state::HTTP_SHOW_WARNING) && (security_info.displayed_password_field_on_http || security_info.displayed_credit_card_field_on_http))
,
Mar 1 2017
,
Mar 3 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/abcf7eeec655ec47740a7676a4c61e164e69189d commit abcf7eeec655ec47740a7676a4c61e164e69189d Author: elawrence <elawrence@chromium.org> Date: Fri Mar 03 00:01:36 2017 Ensure GetSecurityStyle sets correct explanations for HTTP_SHOW_WARNING When the security level is HTTP_SHOW_WARNING, we may add an explanation to the Developer Tools console. We must ensure that we only add the Form Not Secure explanation if the markup displayed a sensitive input field. Also remove adjacent dead code related to the completed field trial; Form Not Secure is always on now. BUG= 691412 TEST=SecurityStateTabHelperTest.* TBR=sdefresne@chromium.org Review-Url: https://codereview.chromium.org/2727353002 Cr-Commit-Position: refs/heads/master@{#454443} [modify] https://crrev.com/abcf7eeec655ec47740a7676a4c61e164e69189d/chrome/browser/ssl/security_state_tab_helper_browser_tests.cc [modify] https://crrev.com/abcf7eeec655ec47740a7676a4c61e164e69189d/components/components_chromium_strings.grd [modify] https://crrev.com/abcf7eeec655ec47740a7676a4c61e164e69189d/components/components_google_chrome_strings.grd [modify] https://crrev.com/abcf7eeec655ec47740a7676a4c61e164e69189d/components/security_state/content/content_utils.cc [modify] https://crrev.com/abcf7eeec655ec47740a7676a4c61e164e69189d/components/security_state/content/content_utils_unittest.cc
,
Mar 3 2017
,
Mar 7 2017
Verified this issue on Windows 10, Ubuntu 14.04 and Mac 10.12.3 with chrome dev #58.0.3029.6 Followed the steps as mentioned in the comment #0 and in dev-tools -> Security Audits, observed "This page is not secure." is displayed. Attaching the screen-cast for reference. Adding TE-Verified labels |
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by ajha@chromium.org
, Feb 13 2017