Intercept calls to 'document.cookie'?

C

ChristophW

Hey guys,

I've been pulling my hair with this problem. I have an application
that hosts multiple IE controls in one process, and all of them are
absolutely isolated from each other (I handle downloading files,
cookies and the like manually under the hood to create this
isolation). The only thing where these windows still interfer is when
some Javascript writes to 'document.cookie'. Since cookies are shared
across all browsers in a process, I have a nasty isolation breach.

I had thought about deriving an object from 'document', overriding the
'cookie' property and defining a variable named 'document' but then I
realized that IE7 and lower does not support properties yet. I also
went as far as textually replacing 'document.cookie' in downloaded
HTML and JS source code with alternative code. That worked until users
of my app browsed scrambled JavaScript code where the simple
replacement fails (basically, the problem that I cannot identify all
occurrences of 'document.cookie' statically).

I'm wondering whether JavaScript that was loaded by a page could
dynamically be monitored and rewritten when statements are executed?
Or is it possible to get notified when new functions and class
prototypes are created? I guess this would require somehow hooking
deep into the JS engine or so. Just some thoughts but I'm open to any
other ideas :)

If it is of any help, the only JS variants I need to support are for
IE6 and IE7.

Thanks a lot, Christoph
 
T

Thomas 'PointedEars' Lahn

ChristophW said:
I've been pulling my hair with this problem. I have an application
that hosts multiple IE controls in one process, and all of them are
absolutely isolated from each other (I handle downloading files,
cookies and the like manually under the hood to create this
isolation). The only thing where these windows still interfer is when
some Javascript writes to 'document.cookie'. Since cookies are shared
across all browsers in a process, I have a nasty isolation breach.

You mean across all windows of a browser session.
I had thought about deriving an object from 'document', overriding the
'cookie' property and defining a variable named 'document' but then I
realized that IE7 and lower does not support properties yet.
Nonsense.

I also went as far as textually replacing 'document.cookie' in downloaded
HTML and JS source code with alternative code. That worked until users
of my app browsed scrambled JavaScript code where the simple
replacement fails (basically, the problem that I cannot identify all
occurrences of 'document.cookie' statically).

Properly identifying the source of your problem first would have been a good
idea.

The source of your problem is not document.cookie, but how cookies are set.
You need to find a discriminator between the different applications. This
can be as simple as a different cookie name (for example, a prefix), but you
may also employ the `path' or the `domain' parameter of the cookie, provided
that your applications are on different paths or subdomains of your
second-level domain (which is likely).
I'm wondering whether JavaScript that was loaded by a page could
dynamically be monitored and rewritten when statements are executed?
Or is it possible to get notified when new functions and class
prototypes are created? I guess this would require somehow hooking
deep into the JS engine or so. Just some thoughts but I'm open to any
other ideas :)

Can't be done.
If it is of any help, the only JS variants I need to support are for
IE6 and IE7.

My suggestion above works everywhere. It is also the only reasonable way to
deal with the problem.


PointedEars
 
C

ChristophW

Hello PointedEars,

thanks for your reply
The source of your problem is not document.cookie, but how cookies are set.
 You need to find a discriminator between the different applications.  This
can be as simple as a different cookie name (for example, a prefix), but you
may also employ the `path' or the `domain' parameter of the cookie, provided
that your applications are on different paths or subdomains of your
second-level domain (which is likely).

The 'specialty' of my app is that a user can have multiple WebBrowser
controls, which are (at least until recently) completely isolated from
each other. So you could use the same web app in two windows within
the same process, and session cookies having the same domain, name and
path would not interfer at all. I already went long ways to accomplish
this. As a matter of fact, these cookies are stored only temporarily
in the app's memory and InternetGet/SetCookie is not used and never
invoked.

But now with cookies that are dynamically set and retrieved, the
HtmlDocument implementation of course invokes these methods. So a
JavaScript expecting to find a cookie won't find it. And session
cookies created and set through document.cookie by one browser
instance will be overwritten by another one browser instance. So
unfortunately, your proposed solution does not work in my case because
there is absolutely no discriminating element. Neither the JavaScript
that is executed nor the cookie names are under my control.

Sop if anybody else has some ideas what JavaScript tricks could be
pulled, please let me know.

Thanks, Christoph
 
T

Thomas 'PointedEars' Lahn

ChristophW said:
Hello PointedEars,

thanks for your reply

You are welcome. Please provide an attribution line for each level of
quoted material.
The source of your problem is not document.cookie, but how cookies are set.
You need to find a discriminator between the different applications. This
can be as simple as a different cookie name (for example, a prefix), but you
may also employ the `path' or the `domain' parameter of the cookie, provided
that your applications are on different paths or subdomains of your
second-level domain (which is likely).

The 'specialty' of my app is that a user can have multiple WebBrowser
controls, which are (at least until recently) completely isolated from
each other. So you could use the same web app in two windows within
the same process, and session cookies having the same domain, name and [1]^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
path would not interfer at all. I already went long ways to accomplish ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
this. As a matter of fact, these cookies are stored only temporarily
in the app's memory and InternetGet/SetCookie is not used and never
invoked.

You may not invoke it directly, but if a resource being navigated to sets a
cookie (through the Set-Cookie HTTP header or document.cookie) they
(whatever they are exactly) are most certainly invoked.
But now with cookies that are dynamically set and retrieved, the
HtmlDocument implementation of course invokes these methods. So a
JavaScript expecting to find a cookie won't find it.

If I'm not mistaken, that is quite the opposite of what you stated before:
And session cookies created and set through document.cookie by one browser
instance will be overwritten by another one browser instance.

Works as designed; however, if I'm not mistaken, that is quite the opposite
of what you said above.[^1]
So unfortunately, your proposed solution does not work in my case because
there is absolutely no discriminating element. Neither the JavaScript
that is executed nor the cookie names are under my control.

Sop if anybody else has some ideas what JavaScript tricks could be
pulled, please let me know.

As I said, there can be no tricks, short of rewriting the DOM API. Sandbox
code is not allowed to modify built-in properties in such a way. The
solution, which would be off-topic here, is within the "WebBrowser" controls
(there are several available, you could have been more precise); they should
have a feature (property/attribute/whatever) that allows to share cookies or
not to share them which you need to use. Or, you need to rethink your design.


PointedEars
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top