Normally d will just changes to 'hello world'. Now, I want to write a plugin (or modify Firefox/SpiderMonkey code, whichever that's necessary) to intercept the DOM call to `d` to allow/deny the access by my own rules (In the event that it's denied, the getElementById will behave as if element 'd' doesn't exist).
I have downloaded and built Firefox. Now I can't seem to find out which part (file/folder/function) of the source code do I have to look into? Do I also need to download and build SpiderMonkey for this purpose?
You'll probably find that the SDK does what you want (you can use a
page-mod to run your script in the context of web pages).
If you're just trying to affect regular web pages, the task is pretty easy
- just set |document.getElementById = yourFunction|.
If you're trying to make it secure/tamper-proof, you'll find the task to be
significantly more difficult, since a clever adversary can try to find a
reference to the original document.getElementById and |apply| it
|document|. What are you trying to do?
On Mon, Feb 27, 2012 at 10:42 PM, Huy Nguyen <nvquang...@gmail.com> wrote:
> I'm fairly new to Firefox Development and I need some help from the
> Mozilla community.
> Normally d will just changes to 'hello world'. Now, I want to write a
> plugin (or modify Firefox/SpiderMonkey code, whichever that's necessary) to
> intercept the DOM call to `d` to allow/deny the access by my own rules (In
> the event that it's denied, the getElementById will behave as if element
> 'd' doesn't exist).
> I have downloaded and built Firefox. Now I can't seem to find out which
> part (file/folder/function) of the source code do I have to look into? Do I
> also need to download and build SpiderMonkey for this purpose?
On Mon, Feb 27, 2012 at 11:32 PM, Huy Nguyen <nvquang...@gmail.com> wrote:
> Thanks so much for your response, bholley!
> If you're trying to make it secure/tamper-proof, you'll find the task to
>> be significantly more difficult, since a clever adversary can try to find a
>> reference to the original document.getElementById and |apply| it
>> |document|. What are you trying to do?
> I'm trying to make it secure/tamper-proof like you said. If the JS try to
> make any changes to any DOM element, I want to do certain simple checking
> before allowing that to happen.
> The idea I'm trying out is to define a security level to both the script
> scope and the DOM object, and allow DOM access to script that has the level
> higher than the level of DOM object.
> If there's other ways to access the DOM object without using
> document.getElementById then I want to intercept it too. I guess it better
> be done by modifying the actual firefox/spidermonkey code?
Trying to maintain a patch against gecko for something like this is going
to be a world of pain. There's a huge amount of code, and we're changing a
lot of the dom and security stuff in the coming months. I strongly
recommend against pursuing this.
Security polices are, in general, very hard to get right. We spend an
immense amount of engineering effort maintaining the ones we provide
(cross-origin security, mostly). So creating a new one from scratch isn't a
great way to go.
What I'd recommend instead is to try to leverage the existing security
infrastructure Mozilla and the DOM provide in order to do what you want. In
general, this would involve sandboxing the untrusted code, and forcing it
to marshal its DOM access over some restricted API. Cross-origin iframes,
worker threads, and sandboxes all provide some degree of isolation for the
code running in their scope. You could then postMessage() the operations
you want to perform, and evaluate them in the master scope before
proceeding. If you need something synchronous, you can probably make
something work with sandboxes.
On Tue, Feb 28, 2012 at 3:09 PM, Bobby Holley <bobbyhol...@gmail.com> wrote:
> The most supported and painless method to extend Firefox is to create a
> javascript addon using the addon SDK:
> https://addons.mozilla.org/en-US/developers/tools/builder
> You'll probably find that the SDK does what you want (you can use a
> page-mod to run your script in the context of web pages).
> If you're just trying to affect regular web pages, the task is pretty easy
> - just set |document.getElementById = yourFunction|.
> If you're trying to make it secure/tamper-proof, you'll find the task to
> be significantly more difficult, since a clever adversary can try to find a
> reference to the original document.getElementById and |apply| it
> |document|. What are you trying to do?
> Cheers,
> bholley
> On Mon, Feb 27, 2012 at 10:42 PM, Huy Nguyen <nvquang...@gmail.com> wrote:
>> I'm fairly new to Firefox Development and I need some help from the
>> Mozilla community.
>> Normally d will just changes to 'hello world'. Now, I want to write a
>> plugin (or modify Firefox/SpiderMonkey code, whichever that's necessary) to
>> intercept the DOM call to `d` to allow/deny the access by my own rules (In
>> the event that it's denied, the getElementById will behave as if element
>> 'd' doesn't exist).
>> I have downloaded and built Firefox. Now I can't seem to find out which
>> part (file/folder/function) of the source code do I have to look into? Do I
>> also need to download and build SpiderMonkey for this purpose?
This approach has been done by some researchers on different browsers. And
part of my work is to try a very simple version of this out on Firefox, at
the same time trying to understand a little bit more about Firefox
architecture. So be assured that I take your suggestion seriously and this
might not be the final pursue that we go for.
Having said that, I'd really appreciate if you could help me how to
specifically start on that very specific example I stated. Which code,
tutorials or docs do I need to look at? How should I do it given the
current Firefox architecture?
>From what I gathered so far, DOM is a XPCOM component and exposed as JS
objects (by XPConnect) to the JS environment. So I vaguely imagine the
change would be somewhere in either DOM or XPConnect?
On Wed, Feb 29, 2012 at 2:38 AM, Bobby Holley <bobbyhol...@gmail.com> wrote:
> On Mon, Feb 27, 2012 at 11:32 PM, Huy Nguyen <nvquang...@gmail.com> wrote:
>> Thanks so much for your response, bholley!
>> If you're trying to make it secure/tamper-proof, you'll find the task to
>>> be significantly more difficult, since a clever adversary can try to find a
>>> reference to the original document.getElementById and |apply| it
>>> |document|. What are you trying to do?
>> I'm trying to make it secure/tamper-proof like you said. If the JS try to
>> make any changes to any DOM element, I want to do certain simple checking
>> before allowing that to happen.
>> The idea I'm trying out is to define a security level to both the script
>> scope and the DOM object, and allow DOM access to script that has the level
>> higher than the level of DOM object.
>> If there's other ways to access the DOM object without using
>> document.getElementById then I want to intercept it too. I guess it better
>> be done by modifying the actual firefox/spidermonkey code?
> Trying to maintain a patch against gecko for something like this is going
> to be a world of pain. There's a huge amount of code, and we're changing a
> lot of the dom and security stuff in the coming months. I strongly
> recommend against pursuing this.
> Security polices are, in general, very hard to get right. We spend an
> immense amount of engineering effort maintaining the ones we provide
> (cross-origin security, mostly). So creating a new one from scratch isn't a
> great way to go.
> What I'd recommend instead is to try to leverage the existing security
> infrastructure Mozilla and the DOM provide in order to do what you want. In
> general, this would involve sandboxing the untrusted code, and forcing it
> to marshal its DOM access over some restricted API. Cross-origin iframes,
> worker threads, and sandboxes all provide some degree of isolation for the
> code running in their scope. You could then postMessage() the operations
> you want to perform, and evaluate them in the master scope before
> proceeding. If you need something synchronous, you can probably make
> something work with sandboxes.
> Cheers,
> bholley
> On Tue, Feb 28, 2012 at 3:09 PM, Bobby Holley <bobbyhol...@gmail.com>wrote:
>> You'll probably find that the SDK does what you want (you can use a
>> page-mod to run your script in the context of web pages).
>> If you're just trying to affect regular web pages, the task is pretty
>> easy - just set |document.getElementById = yourFunction|.
>> If you're trying to make it secure/tamper-proof, you'll find the task to
>> be significantly more difficult, since a clever adversary can try to find a
>> reference to the original document.getElementById and |apply| it
>> |document|. What are you trying to do?
>> Cheers,
>> bholley
>> On Mon, Feb 27, 2012 at 10:42 PM, Huy Nguyen <nvquang...@gmail.com>wrote:
>>> I'm fairly new to Firefox Development and I need some help from the
>>> Mozilla community.
>>> Normally d will just changes to 'hello world'. Now, I want to write a
>>> plugin (or modify Firefox/SpiderMonkey code, whichever that's necessary) to
>>> intercept the DOM call to `d` to allow/deny the access by my own rules (In
>>> the event that it's denied, the getElementById will behave as if element
>>> 'd' doesn't exist).
>>> I have downloaded and built Firefox. Now I can't seem to find out which
>>> part (file/folder/function) of the source code do I have to look into? Do I
>>> also need to download and build SpiderMonkey for this purpose?
On Wed, Feb 29, 2012 at 8:21 PM, Huy Nguyen <nvquang...@gmail.com> wrote:
> Again thanks so much for your answer, bholley.
> This approach has been done by some researchers on different browsers. And
> part of my work is to try a very simple version of this out on Firefox, at
> the same time trying to understand a little bit more about Firefox
> architecture. So be assured that I take your suggestion seriously and this
> might not be the final pursue that we go for.
> Having said that, I'd really appreciate if you could help me how to
> specifically start on that very specific example I stated. Which code,
> tutorials or docs do I need to look at? How should I do it given the
> current Firefox architecture?
> From what I gathered so far, DOM is a XPCOM component and exposed as JS
> objects (by XPConnect) to the JS environment. So I vaguely imagine the
> change would be somewhere in either DOM or XPConnect?
Sort of, yeah. XPConnect does reflection between JS and XPCOM. For lots of
the DOM, we use special generated stubs called QuickStubs. These still go
partly through XPConnect. In the coming months, we'll be landing new code
to stop using XPConnect for the DOM entirely, in favor of custom
python-generated stubs (based off WebIDL files).
So modifying XPConnect is sort of a dead-end for what you're trying to do.
If you wanted to wait a bit, you might have success instrumenting our code
generation so that you can annotate the WebIDL with your security policies
and have that reflected in the generated bindings. But this stuff is still
months from landing.
If you need something now, your best bet is probably to put this stuff in
the DOM itself. The DOM lives in content/ and dom/ (what goes where is sort
of arbitrary). So, for example, getElementById is defined in
dom/interfaces/core/nsIDOMDocument.idl, and implemented in
content/base/src/nsDocument.cpp.
If you look in the aforementioned file, you'll see a method called
nsDocument::GetElementById. It's annotated with NS_IMETHODIMP, which means
that it implements a method from the interface.
Within that function, you'll need the context of the script that called it.
You could normally do this with nsAXPCNativeCallContext, but quickstubbed
methods don't work with that. So you'll probably need to unquickstub the
methods you're instrumenting in dom_quickstubs.qsconf.
If you try really hard, you can probably get a JSContext out of this whole
process. From there, you can get the currently running script with
js_GetCurrentScript. Note that this doesn't give you the script DOM object
(nsIDOMHTMLScriptElement), which is the thing that has the attributes you
care about. But maybe you could find it somehow. All in all, waiting for
the new DOM codegen bindings to land is probably a better bet.
That's about all the advice I'm willing to give for something that I think
is a bad idea. ;-)
On Thu, Mar 1, 2012 at 1:20 PM, Bobby Holley <bobbyhol...@gmail.com> wrote:
> On Wed, Feb 29, 2012 at 8:21 PM, Huy Nguyen <nvquang...@gmail.com> wrote:
>> Again thanks so much for your answer, bholley.
>> This approach has been done by some researchers on different browsers.
>> And part of my work is to try a very simple version of this out on Firefox,
>> at the same time trying to understand a little bit more about Firefox
>> architecture. So be assured that I take your suggestion seriously and this
>> might not be the final pursue that we go for.
>> Having said that, I'd really appreciate if you could help me how to
>> specifically start on that very specific example I stated. Which code,
>> tutorials or docs do I need to look at? How should I do it given the
>> current Firefox architecture?
>> From what I gathered so far, DOM is a XPCOM component and exposed as JS
>> objects (by XPConnect) to the JS environment. So I vaguely imagine the
>> change would be somewhere in either DOM or XPConnect?
> Sort of, yeah. XPConnect does reflection between JS and XPCOM. For lots of
> the DOM, we use special generated stubs called QuickStubs. These still go
> partly through XPConnect. In the coming months, we'll be landing new code
> to stop using XPConnect for the DOM entirely, in favor of custom
> python-generated stubs (based off WebIDL files).
> So modifying XPConnect is sort of a dead-end for what you're trying to do.
> If you wanted to wait a bit, you might have success instrumenting our code
> generation so that you can annotate the WebIDL with your security policies
> and have that reflected in the generated bindings. But this stuff is still
> months from landing.
> If you need something now, your best bet is probably to put this stuff in
> the DOM itself. The DOM lives in content/ and dom/ (what goes where is sort
> of arbitrary). So, for example, getElementById is defined in
> dom/interfaces/core/nsIDOMDocument.idl, and implemented in
> content/base/src/nsDocument.cpp.
> If you look in the aforementioned file, you'll see a method called
> nsDocument::GetElementById. It's annotated with NS_IMETHODIMP, which means
> that it implements a method from the interface.
> Within that function, you'll need the context of the script that called
> it. You could normally do this with nsAXPCNativeCallContext, but
> quickstubbed methods don't work with that. So you'll probably need to
> unquickstub the methods you're instrumenting in dom_quickstubs.qsconf.
> If you try really hard, you can probably get a JSContext out of this whole
> process. From there, you can get the currently running script with
> js_GetCurrentScript. Note that this doesn't give you the script DOM object
> (nsIDOMHTMLScriptElement), which is the thing that has the attributes you
> care about. But maybe you could find it somehow. All in all, waiting for
> the new DOM codegen bindings to land is probably a better bet.
> That's about all the advice I'm willing to give for something that I think
> is a bad idea. ;-)
Hi, it's me again! I'd really appreciate some more help if you don't mind.
I still haven't got there yet but I found another approach.
Since all C++ objects will be wrapped into XPWrappedNative before passing
back to the JS environment, I'm thinking of intercepting the wrapping
functions and put the logic there. Particularly I'm looking
at XPCConvert::NativeInterface2JSObject. But I don't know how to:
Given the nsISupports object that represent the native object:
a) check if it represents a DOM object
b) then convert it to nsIContent so that I can call nsIContent->GetAttr on
it to get the DOM attribute I want?
I guess my issue is that I haven't fully understood how different parts are
implemented and how they fit together. I know it's probably a bad idea to
change Firefox source code like this, what I want now is just a working
concept. So I'd really appreciate if you could help out!
On Thu, Mar 1, 2012 at 1:37 PM, Huy Nguyen <nvquang...@gmail.com> wrote:
> Thank you so much bholley, I appreciate it a lot!
> On Thu, Mar 1, 2012 at 1:20 PM, Bobby Holley <bobbyhol...@gmail.com>wrote:
>> On Wed, Feb 29, 2012 at 8:21 PM, Huy Nguyen <nvquang...@gmail.com> wrote:
>>> Again thanks so much for your answer, bholley.
>>> This approach has been done by some researchers on different browsers.
>>> And part of my work is to try a very simple version of this out on Firefox,
>>> at the same time trying to understand a little bit more about Firefox
>>> architecture. So be assured that I take your suggestion seriously and this
>>> might not be the final pursue that we go for.
>>> Having said that, I'd really appreciate if you could help me how to
>>> specifically start on that very specific example I stated. Which code,
>>> tutorials or docs do I need to look at? How should I do it given the
>>> current Firefox architecture?
>>> From what I gathered so far, DOM is a XPCOM component and exposed as JS
>>> objects (by XPConnect) to the JS environment. So I vaguely imagine the
>>> change would be somewhere in either DOM or XPConnect?
>> Sort of, yeah. XPConnect does reflection between JS and XPCOM. For lots
>> of the DOM, we use special generated stubs called QuickStubs. These still
>> go partly through XPConnect. In the coming months, we'll be landing new
>> code to stop using XPConnect for the DOM entirely, in favor of custom
>> python-generated stubs (based off WebIDL files).
>> So modifying XPConnect is sort of a dead-end for what you're trying to
>> do. If you wanted to wait a bit, you might have success instrumenting our
>> code generation so that you can annotate the WebIDL with your security
>> policies and have that reflected in the generated bindings. But this stuff
>> is still months from landing.
>> If you need something now, your best bet is probably to put this stuff in
>> the DOM itself. The DOM lives in content/ and dom/ (what goes where is sort
>> of arbitrary). So, for example, getElementById is defined in
>> dom/interfaces/core/nsIDOMDocument.idl, and implemented in
>> content/base/src/nsDocument.cpp.
>> If you look in the aforementioned file, you'll see a method called
>> nsDocument::GetElementById. It's annotated with NS_IMETHODIMP, which means
>> that it implements a method from the interface.
>> Within that function, you'll need the context of the script that called
>> it. You could normally do this with nsAXPCNativeCallContext, but
>> quickstubbed methods don't work with that. So you'll probably need to
>> unquickstub the methods you're instrumenting in dom_quickstubs.qsconf.
>> If you try really hard, you can probably get a JSContext out of this
>> whole process. From there, you can get the currently running script with
>> js_GetCurrentScript. Note that this doesn't give you the script DOM object
>> (nsIDOMHTMLScriptElement), which is the thing that has the attributes you
>> care about. But maybe you could find it somehow. All in all, waiting for
>> the new DOM codegen bindings to land is probably a better bet.
>> That's about all the advice I'm willing to give for something that I
>> think is a bad idea. ;-)
On Sun, Mar 18, 2012 at 1:05 AM, Huy Nguyen <nvquang...@gmail.com> wrote:
> Hi, it's me again! I'd really appreciate some more help if you don't mind.
> I still haven't got there yet but I found another approach.
> Since all C++ objects will be wrapped into XPWrappedNative before passing
> back to the JS environment, I'm thinking of intercepting the wrapping
> functions and put the logic there. Particularly I'm looking
> at XPCConvert::NativeInterface2JSObject.
If that's your approach, you probably want to look at the CanCreateWrapper
security check in XPCWrappedNative::InitTearOff. Note that CanCreateWrapper
lives in caps, and caps is disappearing real soon now.
> But I don't know how to:
> Given the nsISupports object that represent the native object:
> a) check if it represents a DOM object
One more question though. I understand that all the <script>s will get
compiled into some sort of byte codes and it'll execute those bytecodes
directly. Technically, is it even possible to determine which <script>
block the current JS statement is executing in? I searched through the code
and it seems the <script> block is only available in
During the execution of A() below, can we somehow determine that it's
currently in the first <script> block instead of the second script block?
<script>
function A() {
// some processing here
}
</script>
<script>
function B() {
}
</script>
<button onclick='A()'>Click</button>
Thank you!
On Mon, Mar 19, 2012 at 12:08 PM, Bobby Holley <bobbyhol...@gmail.com>wrote:
> On Sun, Mar 18, 2012 at 1:05 AM, Huy Nguyen <nvquang...@gmail.com> wrote:
>> Hi, it's me again! I'd really appreciate some more help if you don't
>> mind. I still haven't got there yet but I found another approach.
>> Since all C++ objects will be wrapped into XPWrappedNative before passing
>> back to the JS environment, I'm thinking of intercepting the wrapping
>> functions and put the logic there. Particularly I'm looking
>> at XPCConvert::NativeInterface2JSObject.
> If that's your approach, you probably want to look at the CanCreateWrapper
> security check in XPCWrappedNative::InitTearOff. Note that CanCreateWrapper
> lives in caps, and caps is disappearing real soon now.
>> But I don't know how to:
>> Given the nsISupports object that represent the native object:
>> a) check if it represents a DOM object
I meant: I searched through the code and it seems the <script> block
variable is only available in nsScriptLoader (which do the compiling of the
JS into bytecode?)
On Mon, Apr 2, 2012 at 6:22 PM, Huy Nguyen <nvquang...@gmail.com> wrote:
> Thank you bholley! I appreciate it a lot.
> One more question though. I understand that all the <script>s will get
> compiled into some sort of byte codes and it'll execute those bytecodes
> directly. Technically, is it even possible to determine which <script>
> block the current JS statement is executing in? I searched through the code
> and it seems the <script> block is only available in
> During the execution of A() below, can we somehow determine that it's
> currently in the first <script> block instead of the second script block?
> <script>
> function A() {
> // some processing here
> }
> </script>
> <script>
> function B() {
> }
> </script>
> <button onclick='A()'>Click</button>
> Thank you!
> On Mon, Mar 19, 2012 at 12:08 PM, Bobby Holley <bobbyhol...@gmail.com>wrote:
>> On Sun, Mar 18, 2012 at 1:05 AM, Huy Nguyen <nvquang...@gmail.com> wrote:
>>> Hi, it's me again! I'd really appreciate some more help if you don't
>>> mind. I still haven't got there yet but I found another approach.
>>> Since all C++ objects will be wrapped into XPWrappedNative before
>>> passing back to the JS environment, I'm thinking of intercepting the
>>> wrapping functions and put the logic there. Particularly I'm looking
>>> at XPCConvert::NativeInterface2JSObject.
>> If that's your approach, you probably want to look at the
>> CanCreateWrapper security check in XPCWrappedNative::InitTearOff. Note that
>> CanCreateWrapper lives in caps, and caps is disappearing real soon now.
>>> But I don't know how to:
>>> Given the nsISupports object that represent the native object:
>>> a) check if it represents a DOM object
Within the JS engine, scripts are represented as JSScripts (see
jsscript.h). So you probably want to tag those somehow when you compile the
script, so that you have the information you need later on.
On Mon, Apr 2, 2012 at 3:25 AM, Huy Nguyen <nvquang...@gmail.com> wrote:
> I meant: I searched through the code and it seems the <script> block
> variable is only available in nsScriptLoader (which do the compiling of the
> JS into bytecode?)
> On Mon, Apr 2, 2012 at 6:22 PM, Huy Nguyen <nvquang...@gmail.com> wrote:
>> Thank you bholley! I appreciate it a lot.
>> One more question though. I understand that all the <script>s will get
>> compiled into some sort of byte codes and it'll execute those bytecodes
>> directly. Technically, is it even possible to determine which <script>
>> block the current JS statement is executing in? I searched through the code
>> and it seems the <script> block is only available in
>> During the execution of A() below, can we somehow determine that it's
>> currently in the first <script> block instead of the second script block?
>> <script>
>> function A() {
>> // some processing here
>> }
>> </script>
>> <script>
>> function B() {
>> }
>> </script>
>> <button onclick='A()'>Click</button>
>> Thank you!
>> On Mon, Mar 19, 2012 at 12:08 PM, Bobby Holley <bobbyhol...@gmail.com>wrote:
>>> On Sun, Mar 18, 2012 at 1:05 AM, Huy Nguyen <nvquang...@gmail.com>wrote:
>>>> Hi, it's me again! I'd really appreciate some more help if you don't
>>>> mind. I still haven't got there yet but I found another approach.
>>>> Since all C++ objects will be wrapped into XPWrappedNative before
>>>> passing back to the JS environment, I'm thinking of intercepting the
>>>> wrapping functions and put the logic there. Particularly I'm looking
>>>> at XPCConvert::NativeInterface2JSObject.
>>> If that's your approach, you probably want to look at the
>>> CanCreateWrapper security check in XPCWrappedNative::InitTearOff. Note that
>>> CanCreateWrapper lives in caps, and caps is disappearing real soon now.
>>>> But I don't know how to:
>>>> Given the nsISupports object that represent the native object:
>>>> a) check if it represents a DOM object
