It's unclear that there's any meaningful security implication here (an attacker would need the ability to control the name of nodes on the page), although it does reflect a difference in cross-browser behavior and thus might be interesting as an interop issue. 

Firefox 59 matches Chrome, while IE11 and Edge do not allow hiding of the document.cookie property.

Thanks for your report. What an attacker can do in that case?

I see two scenarios, none of which has any security implications:

1) web-site controlled by an attacker: an attacker can do pretty much everything that JS allows them to do

2) XSS on 3rd party site: an attacker is able to execute JS in a victim's browser in a context of 3rd party web-site, most likely an attacker will read / write victim's data on that web-site?


Adding Needs-Feedback label. Please share if you have thoughts regarding security implications.

 https://crbug.com/257210#c12  points toward "Won't Fix" but we should perhaps let someone on the DOM team ensure that there isn't some new spec that calls for something different.

saurabh.banawar, could you reply to #2?

Re 2:

I think this a genuine security issue.

Regarding your question that what can an attacker do:

1. Let us assume that a 3rd party application takes user input and properly encodes it in order to ensure that there is no XSS.
2. If this user input is then entered in the form tag in the name attribute.
3. Also if this user input is stored in the DB and every time the page is rendered to all the user of the web app, the payload i.e. name="cookie" gets shown on the web page.
4. Now, if the client side legitimate JavaScript wants to fetch cookies using document.cookie API, the it will fail (how it fails is proved in my PoC). Thus the JS will paralyze and will not be able to support web app feature like submitting cookies to the website in an AJAX call or submitting cookies using an CORS request when with.credentials = true.

Thus, this is an attack scenario in which web applications of 3rd party can be targeted by an attacker.

SOLUTION:
The solution is very easy. That is to make the JS parser give priority to main cookies and to not confuse it with attacker entered name="cookie".


Thank you,
Saurabh

The scenario described in #6 seems both improbable and also does not describe a security issue. Unless there's a DOM specification that the cookie attribute should be unforgeable, I don't think we can take a change here.

We need to either assign a specific owner on the DOM team so they can see the issue and can help triage the spec question, or change this to Type=Bug and let it get triaged via their normal process.

Agree with elawrence@ in #7. Change type from bug-security to bug.

As far as I know there's no discussion about making document.cookie
marked [Unforgeable] in the IDL.

As far as the security team replied that this is not a security issue,
dom-team won't take any action on this.

saurabh.banawar, the code in OP looks like just a page author accidentally
made the form name as "cookie", and document.cookie is shadowed. Such a
page doesn't work as you said. So how can it be a security attack, such
as sending user's cookie to third-party site?

Unless someone is sure that this is a security issue, we will take no action
on this.