New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 800188 link

Starred by 3 users
Status: WontFix
Owner:
█ mkwst@chromium.org
Buried. Ping if important.
Closed: Jan 2018
Cc:
█ mkwst@chromium.org
█ rdsmith@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 1
Type: Bug
Team-Security-UX



Sign in to add a comment

Secure-only cookies seem to be allowed on insecure sites on Canary and Chromium

Reported by 93m4qau...@gmail.com, Jan 9 2018 
UserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3315.2 Safari/537.36

Steps to reproduce the problem:
1. Open http://www.chromium.org/developers/how-tos/api-keys.
2. Click on the verbose chip, and then click Cookies.
3. Expand docs.google.com > Cookies and click on the cookie(s) for details.

What is the expected behavior?
Since the page is insecure, there are no cookies from the page that should only be valid on secure sites.

What went wrong?
There is a cookie from docs.google.com that should only be valid on secure sites, even though the page is insecure HTTP. See attached screenshot.

Did this work before? Yes Seems to work fine on stable - 63.0.3239.132

Chrome version: 65.0.3315.2  Channel: n/a
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version:
Secure-only Cookies on Insecure Sites.PNG
146 KB View Download

Comment 1 by krajshree@chromium.org, Jan 9 2018

Components: UI>Browser>Omnibox>SecurityIndicators>VerboseChip Internals>Network
Labels: -Type-Bug-Regression Triaged-ET M-65 Needs-Triage-M65 OS-Linux OS-Mac Type-Bug
Status: Untriaged (was: Unconfirmed)
Able to reproduce the issue on Mac 10.12.6, Win-10 and Ubuntu 14.04 using chrome reported version #65.0.3315.2 and latest stable #63.0.3239.132.
This is a non-regression issue as it is observed from M50 old builds.

Note: From starting M63 builds and older builds, cookies for docs.google.com is sent for any connection.
Attaching screenshot for reference of M-55 build.
Hence, marking it as untriaged to get more inputs from dev team.

Thanks...!!
800188.PNG
175 KB View Download

Comment 2 by cbentzel@chromium.org, Jan 9 2018

Components: -Internals>Network Internals>Network>Cookies

Comment 3 by mmenke@chromium.org, Jan 9 2018

Cc: mkwst@chromium.org rdsmith@chromium.org
Labels: -Pri-2 Pri-1

Comment 4 by mkwst@chromium.org, Jan 9 2018

Owner: mkwst@chromium.org
Status: Assigned (was: Untriaged)
It looks like the scenario you're talking about is the following:

1.  User visits `http://example.com/`
2.  `http://example.com/` embeds `https://secure.com/`
3.  `https://secure.com/` receives cookies.

Is that correct? If so, it's working as intended: the `secure` attribute doesn't walk up the ancestor chain to determine whether the frame is a secure context. It ensures that the cookie isn't sent in the clear over a plaintext connection.

If you're loading `http://secure.com/` and getting cookies marked `secure`, then that's a different story entirely.

Comment 5 by 93m4qau...@gmail.com, Jan 9 2018 

>It looks like the scenario you're talking about is the following:...Is that correct?

Is that the same scenario applicable to the secure-only docs.google.com cookie on the insecure chromium.org page?

Comment 6 by elawrence@chromium.org, Jan 29 2018

Status: WontFix (was: Assigned)
Re #5: Yes, when http://chromium.org loads https://docs.google.com, by-design, https://docs.google.com gets its SECURE cookies. These secure cookies are not accessible to the non-secure cross-origin parent page.

In the area of cookies, the SECURE attribute refers to connection security, not to the page's overall context.
►

Sign in to add a comment