document.domain can be hooked using Object.defineProperty




4 years ago
3 years ago


(Reporter: ahamed.nafeez, Unassigned)



23 Branch
Windows 8

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [reporter-external][don't open bug])



4 years ago
User Agent: Mozilla/5.0 (Windows NT 6.2; rv:23.0) Gecko/20100101 Firefox/23.0 (Beta/Release)
Build ID: 20130814063812

Steps to reproduce:

Object.defineProperty(document, 'domain', {
	'get': function(){return ''}


alert("My document.domain is " + document.domain);


Actual results:

The alert in fact returned, ''

Expected results:

document.domain is commonly used for security in client-side code. A code might check whether the current domain is good before they do security sensitive actions.

Its a security concern to allow document.domain to be hooked.
Whiteboard: [reporter-external]
Component: Untriaged → DOM
Product: Firefox → Core
We could make this unforgeable, I guess.  That would need a spec change here.  Is it unforgeable in any other browser?
Flags: needinfo?(annevk)

Comment 2

4 years ago
Well, it is unforgeable in other browsers as well. Except Safari, when I tested.

This is an issue for websites who entirely trust on document.domain for a few security checks.

Comment 3

4 years ago
Oh Sorry, I meant it is forgeable in other browsers as well. Only Safari, couldn't forge document.domain.

Comment 4

4 years ago
In what kind of context would you check document.domain? That does not seem secure at all. document.domain is a security risk, you should really not be using it.
Flags: needinfo?(annevk)

Comment 5

4 years ago
I agree with you in a way. But there are a lot of developers who rely on this for checking cross-domain security. The usage is primarily for checking, isWhitelisted(document.domain, "") and a plethora of other usage scenarios. I'm also aware of a widely used CSRF framework which uses this to check the current domain.

Nonetheless, I agree. Nobody asked the developer to trust document.domain. But, I would really like to know the problems if document.domain is made Un-Foregable. Could you please throw some light there?

Comment 6

4 years ago
We rather not make properties unforgeable unless there's an actual problem or legacy reason.
If almost all browser behave this way then it seems like something we ought to let framework authors know rather than hide this away. This doesn't seem like an immediate risk to Firefox users if we unhide it so can we?

Again I'm going to confirm that at least we have a different assumption than many web authors: we need a resolution, even if that's WONTFIX.
Ever confirmed: true

Comment 10

4 years ago
Given that only Safari makes this unforgeable this does not seem like a security issue. It might be worth discussing this on the WHATWG list to see what people think.
Keywords: sec-other
(In reply to Anne (:annevk) from comment #10)
> Given that only Safari makes this unforgeable this does not seem like a
> security issue. It might be worth discussing this on the WHATWG list to see
> what people think.

The fact that browsers do different things leads to WEB security issues when content authors make assumptions based on the undefined behavior of only one user agent. It then becomes a security issue for USERS who trust those sites with their data.

A public conversation about the differences on the WHATWG list would be a good idea. This is the kind of security issue that gets better for users with publicity, not worse. (we can keep the bug itself hidden for now, though, if bholley prefers).

Comment 13

4 years ago
I had not tested IE10 before. IE10 also has configurable set to false for this property.
But has it on the proto, so it can still be shadowed, which means it being non-configurable is pointless.

Comment 15

4 years ago
There is no interest in changing the specification at this time and frankly I don't really see the point in doing that either:

This bug can be opened up to the public.
Last Resolved: 4 years ago
Resolution: --- → INVALID
Whiteboard: [reporter-external] → [reporter-external][don't open bug]
Group: core-security
You need to log in before you can comment on or make changes to this bug.