New issue
Advanced search Search tips

Issue 608494 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Oct 2017
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug-Security
Team-Security-UX



Sign in to add a comment

MixedContentChecker::handleCertificateErrors() does not downgrade lock icon for active broken-https subresource loads in iframes

Project Member Reported by est...@chromium.org, May 2 2016

Issue description

Suppose https://a.com frames https://b.com which loads a script from https://expired.badssl.com (for which a user has previously clicked through an SSL warning). MixedContentChecker::handleCertificateErrors() will notify the browser about a broken-https subresource load on the subresource's effective frame (in this case, https://b.com), so the browser will mark b.com as having run insecure content. If b.com were the top-level frame, this would mean that the page would get marked with a red slashy lock icon. However, since b.com is not the top-level frame, a.com goes unmarked and the lock icon doesn't change.

When a subresource loads over broken-https, we should mark all ancestors in the frame tree as having run insecure content, so that all the origins in the frame tree get marked with a red slashy lock icon.
 
Labels: Hotlist-User-Journey-CCardInfo

Comment 2 by ta...@google.com, Jul 13 2016

Labels: OS-Chrome

Comment 3 by est...@chromium.org, Jul 13 2016

Labels: -OS-Chrome OS-All
Project Member

Comment 4 by sheriffbot@chromium.org, Sep 1 2016

Labels: -M-52 M-53
Labels: ConnectionInfo
Project Member

Comment 6 by sheriffbot@chromium.org, Oct 13 2016

Labels: -M-53 M-54
Components: -Security>UX Internals>PageSecurityState
Components: Internals>Permissions>CrowdConsent
Components: -Internals>Permissions>CrowdConsent
Labels: -ConnectionInfo
Project Member

Comment 11 by sheriffbot@chromium.org, Dec 2 2016

Labels: -M-54 M-55
Project Member

Comment 12 by sheriffbot@chromium.org, Jan 26 2017

Labels: -M-55 M-56
Project Member

Comment 13 by sheriffbot@chromium.org, Mar 10 2017

Labels: -M-56 M-57
Project Member

Comment 14 by sheriffbot@chromium.org, Apr 20 2017

Labels: -M-57 M-58
Project Member

Comment 15 by sheriffbot@chromium.org, Jun 6 2017

Labels: -M-58 M-59
Project Member

Comment 16 by sheriffbot@chromium.org, Jul 26 2017

Labels: -M-59 M-60
Project Member

Comment 17 by sheriffbot@chromium.org, Sep 6 2017

Labels: -M-60 M-61
Status: Fixed (was: Assigned)
This seems to have gotten fixed in a refactor in which we started using the top-level frame's origin.
Project Member

Comment 19 by sheriffbot@chromium.org, Oct 7 2017

Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
Project Member

Comment 20 by sheriffbot@chromium.org, Jan 13 2018

Labels: -Restrict-View-SecurityNotify allpublic
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