Tricky (?) cookie question

[Mikalee]

Alright...here's the scenario...any advice would be greatly appreciated.

Let's imagine there are 3 different sites on 3 different domains. A user accesses the first site (called siteA) and searches for an item they'd like to buy.

Actually what happens when they are searching is that siteB is called within a frame and all the searches are done there. Once the user has decided they are interested in an item, they click on a 'conact' link beside the search results in siteB and a form pops up for them to fill out - which is actually a part of siteC.

I have control of siteA and siteC, but not siteB. Is there any way for me to set a cookie (or anything that would work) when the user first accesses siteA so that when they fill out the form in siteC in can be included in a hidden field and the user can be tracked all the way from siteA?

From the little I know of cookies, they are domain-specific and could therefore not be passed from siteA to siteC. If I am wrong, please correct me...if you have any other ideas please let me know.

Thank you.

[jason]

Cookies are indeed domain specific, so you won't be able to pass them between domains. What you'd have to do is pass the unique identifier to site B and have site B in turn pass it to site C. If you don't have control of site B this will be difficult.

You could try passing the key to site B in the query string. For example, call site B with http://www.siteb.com/someproduct.html?siteakey=12345678. Since most web scripts will ignore this if they don't have a need for that key, site B probably won't care that its there (although this isn't guaranteed). The user's browser will probably (depending on how you do it) pass the URL of site B as the HTTP_REFERER variable to site C. Since the key is part of the URL, it should be included in the referrer string that C gets, so you could parse that looking for the value. This isn't a failsave though: not all browsers will return a referrer and if site B does any kind of redirect the value could be lost. Site B might even fail because of unexpected data being sent to it (a reasonable security precaution that isn't often put to practice). But its an idea...use it at your own risk.

--Jason

[Mikalee]

Thanks Jason. Wouldn't the sitekey be lost on siteB is the user browsed a few pages before clicking on a link to siteC? Even for a browser that supports it?

I've been trying to do some research on this and it definitely doesn't seem to be an easy task. The most plausible solution I found was to use XSS (cross site scripting) - which is usually used for hacking. But, if I use XSS on siteC to run a script in the link they click to read their cookies in siteA then I could match them up.

I don't know how safe it would be to use this sort of method though for 2 reasons. 1) The site will be vulnerable for other hackers (though it's not really useful information), and 2) XSS may not last very long as it's usually used for hacking (I think).

Hopefully someone else has come across this before and will be able to shed some light!

Thanks again,
Mike

[jason]

Thanks Jason. Wouldn't the sitekey be lost on siteB is the user browsed a few pages before clicking on a link to siteC? Even for a browser that supports it?

Yes.

The most plausible solution I found was to use XSS (cross site scripting) - which is usually used for hacking.

2) XSS may not last very long as it's usually used for hacking (I think).

XSS was more of a security oversight in browsers than a feature. Some people have implemented useful applications for it, but browser vendors are quick to disable the ability to do XSS whenever it is found, so I wouldn't rely on using it.

Why can't site A do the work of Site C? If it did you wouldn't be having these problems--just store the data you need in a session (or cookie) and it would be available to the current Site C page without a problem.

I don't know how safe it would be to use this sort of method though for 2 reasons. 1) The site will be vulnerable for other hackers (though it's not really useful information)...

The fact you implement a feature using XSS on your site doesn't make your site open to an XSS attack any more than choosing what to wear each morning does. Any site is potentially vulnerable to XSS attacks--all someone has to do is open a page of your site in a frame and then use JavaScript to tell that page what to do. The harm of XSS comes from hackers sending bad data to scripts that don't check for it. It doesn't matter if XSS is used to do this or some other method, like sending bad data in the URL's query string.

XSS is not a "feature" of browsers, though, so you shouldn't rely on it. Most browsers have already blocked the ability to do XSS.

Here's an idea: since you are already using a frame on site A to load the site B page, just create another frame with no size (height/width = 0) and load a page from Site C where you simply pass the ID from A(i.e. sitec.com/setvar.php?var=12345). Use that page to either store the value in a session (if you are using PHP) or to set a cookie with JavaScript. Then the form site C will be able to retrieve the value and you won't need to use cross site scripting.

--Jason

[Mikalee]

Here's an idea: since you are already using a frame on site A to load the site B page, just create another frame with no size (height/width = 0) and load a page from Site C where you simply pass the ID from A(i.e. sitec.com/setvar.php?var=12345). Use that page to either store the value in a session (if you are using PHP) or to set a cookie with JavaScript. Then the form site C will be able to retrieve the value and you won't need to use cross site scripting.

--Jason

That sounds like it could work! I'll look into implementing it (when the project comes around). Thanks again Jason...much appreciated.

Mike

[jason]

Brainstorming is fun! You're welcome.

--Jason