Created attachment 205040 [details] trying to steal bugzilla cookies, ignore checking what cookies are accessible from bugzilla.mozilla.org
looks like malicous attachments may access all cookies from b.m.o, which eventually may be potentially used to access restricted bugs. a potential solution is attachments to be served from a useless domain with virtual web server.
So given that XBL runs with page privileges, we're OK here. If it did not, this binding would need some serious thought; adding blocking of bug 59701. In my opinion this bug should not be security-sensitive so that people working on bug 59701 can see this. If someone feels that the material in comment 2 and comment 3 means that this bug should stay security-sensitive (given that the bugzilla bugs on that issue are, I can see people feeling that way), then we should probably close this bug out and file a new open bug on on the real issue at hand.
question: in content/xbl/src/nsXBLBinding.cpp nsXBLBinding::DoInitJSClass // Make a new object prototyped by parent_proto and parented by global. proto = ::JS_InitClass(cx, // context global, i would like to try to get this "global" object via js. can someone provide a testcase for this (probably involving __parent__) because i couldn't do it.
That global is the inner of the window object (that is, it's the global object for the document in which the element the binding is being attached to lives). You can just walk the __parent__ chain on the bound node to get to that global.
(In reply to comment #7) > That global is the inner of the window object (that is, it's the global object > for the document in which the element the binding is being attached to lives). > You can just walk the __parent__ chain on the bound node to get to that global. But the __parent__ getter censors the inner object, returning the outer for it. /be
another question: can someone please tell me the codepath for this: <script> alert(window.QueryInterface(Components.interfaces.nsISupportsWeakReference).GetWeakReference()); </script> QueryInterfaces passes, returning window object, but then something throws a js exception.
You need UniversalXPConnect permissions to use weak references.
(In reply to comment #10) > You need UniversalXPConnect permissions to use weak references. > i was interested in which methods get invoked by this example.
is this bug attacking firefox xbl, toolkit xbl, or some gecko core module? if any of the latter, could we please move it?
(In reply to comment #12) > is this bug attacking firefox xbl, toolkit xbl, or some gecko core module? if > any of the latter, could we please move it? > i am not sure it is a real attack, so the bug may be invalid.
tb._fireCommand="var er=new Error();alert('Error.stack='+er.stack)"; gives interesting stack. on 1.5: Error()@0 @chrome://global/... on trunk: Error()@0 @0
Does anyone object to hiding comments 2 and 3, and then opening this bug, now that we have the ability to hide comments?
(In reply to comment #16) > Does anyone object to hiding comments 2 and 3, and then opening this bug, now > that we have the ability to hide comments? > i don't object. just for the record comment 2 and comment 3 are mine according to bugmail.
No objection. Gerv