Cross-Domain Cookies

[Alan Little]

If I load a JS file from a different domain, the browser requests it via
HTTP, so I assume it sends any relevant cookie headers for that domain;
why then can I not access them? E.g. suppose I have this in a file on
domain1.com:

<SCRIPT TYPE="text/javascript" src="http://www.domain2.com/cookie.js">
</SCRIPT>

and in cookie.js I have

alert(document.cookie);

It seems to me it should show me the cookies for domain2, no? But it
shows me the cookies for domain1. Is there a way to get it to do what I
want?

--
Alan Little
Phorm PHP Form Processor
http://www.phorm.com/

[Hywel Jenkins]

In article <Xn**************************@216.196.97.131>, alan@n-o-s-p-
a-m-phorm.com says...

If I load a JS file from a different domain, the browser requests it via
HTTP, so I assume it sends any relevant cookie headers for that domain;
why then can I not access them? E.g. suppose I have this in a file on
domain1.com:

<SCRIPT TYPE="text/javascript" src="http://www.domain2.com/cookie.js">
</SCRIPT>

and in cookie.js I have

alert(document.cookie);

It seems to me it should show me the cookies for domain2, no? But it
shows me the cookies for domain1. Is there a way to get it to do what I
want?

One would hope not - what's to stop unscrupulous developers from trying
to grab cookie data from other sites without your knowledge?

--
Hywel http://kibo.org.uk/
I do not eat quiche.

[Matthew Hagston]

"Alan Little" <al**@n-o-s-p-a-m-phorm.com> wrote in message
news:Xn**************************@216.196.97.131.. .

If I load a JS file from a different domain, the browser requests it via
HTTP, so I assume it sends any relevant cookie headers for that domain;
why then can I not access them? E.g. suppose I have this in a file on
domain1.com:

<SCRIPT TYPE="text/javascript" src="http://www.domain2.com/cookie.js">
</SCRIPT>

and in cookie.js I have

alert(document.cookie);

It seems to me it should show me the cookies for domain2, no? But it
shows me the cookies for domain1. Is there a way to get it to do what I
want?

--
Alan Little
Phorm PHP Form Processor
http://www.phorm.com/

I do not belive this is possible for just this reasons that Mr. Jenkins
stated. If by chance you own both domains you would have to make a php
script on the second domain to read it's own cookie then transfer the data
that way. As far as directly reading it across another domain, you should
not be able to do it.

--
Matthew Hagston

[Alan Little]

Carved in mystic runes upon the very living rock, the last words of
Hywel Jenkins of comp.lang.javascript make plain:

In article <Xn**************************@216.196.97.131>,
alan@n-o-s-p- a-m-phorm.com says...

If I load a JS file from a different domain, the browser requests it
via HTTP, so I assume it sends any relevant cookie headers for that
domain; why then can I not access them? E.g. suppose I have this in a
file on domain1.com:

<SCRIPT TYPE="text/javascript"
src="http://www.domain2.com/cookie.js"> </SCRIPT>

and in cookie.js I have

alert(document.cookie);

It seems to me it should show me the cookies for domain2, no? But it
shows me the cookies for domain1. Is there a way to get it to do what
I want?

One would hope not - what's to stop unscrupulous developers from
trying to grab cookie data from other sites without your knowledge?

Because it would depend on the javascript on the other end to provide the
data. The two sites would have to be in cooperation.

--
Alan Little
Phorm PHP Form Processor
http://www.phorm.com/

[Alan Little]

Carved in mystic runes upon the very living rock, the last words of
Matthew Hagston of comp.lang.javascript make plain:

"Alan Little" <al**@n-o-s-p-a-m-phorm.com> wrote in message
news:Xn**************************@216.196.97.131.. .

If I load a JS file from a different domain, the browser requests it
via HTTP, so I assume it sends any relevant cookie headers for that
domain; why then can I not access them? E.g. suppose I have this in a
file on domain1.com:

I do not belive this is possible for just this reasons that Mr.
Jenkins stated. If by chance you own both domains you would have to
make a php script on the second domain to read it's own cookie then
transfer the data that way.

I do control both domains. They are two sites that share a member base; I
would like members to be able to log in to either one, then go to the
other without having to log in again. I could just pass an identifier in
the URL, but I'd rather not do that if I can figure out a way to do it
transparently.

Actually the dual membership is just one scenario; I have two clients at
the moment with similar requirements. In the other case I don't have
direct access to the server with the page that needs to receive the data;
I can only provide an HTML/JS page that they upload, which is why I was
mainly pursuing a JS solution.

Anyway, I don't follow what you mean about a PHP page on the originating
server. It's only going to have access to the cookie data if the browser
makes the request -- i.e. I couldn't have a PHP script on the receiving
end making the request. How would it return the data in a way that the
receiving JS could make use of it? Sorry if I'm being dense; sometimes
you stare at a problem so long you lose sight of the forest for the
trees.

--
Alan Little
Phorm PHP Form Processor
http://www.phorm.com/

[kaeli]

In article <Xn*************************@216.196.97.131>, alan@n-o-s-p-a-m-
phorm.com enlightened us with...

Anyway, I don't follow what you mean about a PHP page on the originating
server. It's only going to have access to the cookie data if the browser
makes the request -- i.e. I couldn't have a PHP script on the receiving
end making the request. How would it return the data in a way that the
receiving JS could make use of it? Sorry if I'm being dense; sometimes
you stare at a problem so long you lose sight of the forest for the
trees.

There is no "receiving" JS. JS is run on the client, and only the client.
Unless you're talking .NET JScript which you aren't. :)

As to sharing cookies across sites, lots and lots of people do this. It's a
third party cookie.

--
--
~kaeli~
Frisbeetarianism (n.), The belief that, when you die, your
soul goes up on the roof and gets stuck there.
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace

[Alan Little]

Carved in mystic runes upon the very living rock, the last words of
kaeli of comp.lang.javascript make plain:

In article <Xn*************************@216.196.97.131>,
alan@n-o-s-p-a-m- phorm.com enlightened us with...

Anyway, I don't follow what you mean about a PHP page on the
originating server. It's only going to have access to the cookie data
if the browser makes the request -- i.e. I couldn't have a PHP script
on the receiving end making the request. How would it return the data
in a way that the receiving JS could make use of it? Sorry if I'm
being dense; sometimes you stare at a problem so long you lose sight
of the forest for the trees.
There is no "receiving" JS. JS is run on the client, and only the
client. Unless you're talking .NET JScript which you aren't. :)

I understand that; it was perhaps not the best term to use. I was
attempting to refer to the page which would be "receiving" or reading the
cookie set by the other site.
As to sharing cookies across sites, lots and lots of people do this.
It's a third party cookie.

I understand how domain1 can set a cookie in the browser while the person
is viewing domain2, by the domain2 page loading, for example, a web bug
from domain1. That's my understanding of what a 3P cookie is, anyway. But
in such a case, that cookie is still only readable by code served from
domain2. That is, domain1 can track the person's activity across domain2,
but I want domain1 to be able to hand the person off and say, "Here,
domain2, this is Joe Surfer. He's all yours now."

--
Alan Little
Phorm PHP Form Processor
http://www.phorm.com/

[Jan Ehrhardt]

Alan Little in comp.lang.javascript (Fri, 25 Mar 2005 11:58:42 -0600):

I do control both domains. They are two sites that share a member base; I
would like members to be able to log in to either one, then go to the
other without having to log in again. I could just pass an identifier in
the URL, but I'd rather not do that if I can figure out a way to do it
transparently.

I have solved this by creating .js files that are actually php-files.
Create an extra directory /jsphp/ on domain2 with the following in your
..htaccess (for Apache):

AddType application/x-httpd-php .js

This will make sure a *.js file is parsed by php. Then all you have to
do is to put cookie.js in that directory with the following content:

<?php
header("Content-Type: application/x-javascript");
$user = $_COOKIE['user'];
?>
var user = "<?php echo $user; ?>";

Suppose a user has set a cookie on domain2 with user = myname.
Add this to any file on domain1:

<script type="text/javascript" src="http://domain2.tld/jsphp/cookie.js>
</script>

cookie.js is parsed by php on domain2, gets the cookie value for 'user'
on domain2 (!) and outputs this in the file on domain1:

var user = "myname";

Effect: any subsequent javascript within the file on domain1 can use the
variable 'user'. You may duplicate the cookie or whatever. Works
flawlessly in MSIE6, Firefox and Opera 7.

Jan

[kaeli]

In article <Xn**************************@216.196.97.131>, alan@n-o-s-p-a-m-
phorm.com enlightened us with...

I understand how domain1 can set a cookie in the browser while the person
is viewing domain2, by the domain2 page loading, for example, a web bug
from domain1. That's my understanding of what a 3P cookie is, anyway. But
in such a case, that cookie is still only readable by code served from
domain2. That is, domain1 can track the person's activity across domain2,
but I want domain1 to be able to hand the person off and say, "Here,
domain2, this is Joe Surfer. He's all yours now."

Oh, okay, I see the difference now.

Out of curiousity, is there a reason simply passing what you need via the URL
won't work for you?

Other than that, Jan seems to have posted a nice solution and there are an
absolute crapload of results from Google. ;)
http://www.google.com/search?hl=en&q...=Google+Search
--
--
~kaeli~
Abdicate (v.), to give up all hope of ever having a flat
stomach.
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace

[Jan Ehrhardt]

Jan Ehrhardt in comp.lang.javascript (Fri, 25 Mar 2005 22:22:38 +0100):

<?php
header("Content-Type: application/x-javascript");
$user = $_COOKIE['user'];
?>
var user = "<?php echo $user; ?>";

BTW: if you are passing really sensitive information you ought to be
carefull. Any other page that includes cookie.js gets hold of the same
information. You can always check HTTP_RERERER:

<?php
header("Content-Type: application/x-javascript");
$refr = $_SERVER['HTTP_REFERER'];
if (eregi("^http://www\.domain1\.tld/"),$refr) $user = $_COOKIE['user'];
?>
var user = "<?php echo $user; ?>";

Most browsers pass the location of the calling page to an included
js-file. But you can never be sure of that, so this scheme will fail in
a few cases.

Jan

[Jan Ehrhardt]

kaeli in comp.lang.javascript (Fri, 25 Mar 2005 15:45:35 -0600):

there are an absolute crapload of results from Google. ;)
http://www.google.com/search?hl=en&q...=Google+Search

Which are all pointing to the same article at phpbuilder.com ;-)

Jan

[Alan Little]

Carved in mystic runes upon the very living rock, the last words of Jan
Ehrhardt of comp.lang.javascript make plain:

Jan Ehrhardt in comp.lang.javascript (Fri, 25 Mar 2005 22:22:38 +0100):

<?php
header("Content-Type: application/x-javascript");
$user = $_COOKIE['user'];
?>
var user = "<?php echo $user; ?>";

BTW: if you are passing really sensitive information you ought to be
carefull. Any other page that includes cookie.js gets hold of the same
information.

All they would be getting would be the cookie value from their own
browser, which of course they can get anyway.

--
Alan Little
Phorm PHP Form Processor
http://www.phorm.com/

[Alan Little]

Carved in mystic runes upon the very living rock, the last words of Jan
Ehrhardt of comp.lang.javascript make plain:

Alan Little in comp.lang.javascript (Fri, 25 Mar 2005 11:58:42 -0600):

I do control both domains. They are two sites that share a member
base; I would like members to be able to log in to either one, then go
to the other without having to log in again. I could just pass an
identifier in the URL, but I'd rather not do that if I can figure out
a way to do it transparently.

I have solved this by creating .js files that are actually php-files.

<?php
header("Content-Type: application/x-javascript");
$user = $_COOKIE['user'];
?>
var user = "<?php echo $user; ?>";

Brilliant. I should have thought of that!

One thing: you don't have to do the .htaccess gimmick. You can just use:

<SCRIPT TYPE="text/javascript" src="http://www.domain1.com/cookie.php">

The TYPE attribute and the Content-Type header tell the browser what to
do with it. I learned this doing a similar thing with PHP files in IMG
tags. Of course, if you want to hide the fact that you're calling a PHP
file, you can do the other as well.

--
Alan Little
Phorm PHP Form Processor
http://www.phorm.com/

[Alan Little]

Carved in mystic runes upon the very living rock, the last words of Jan
Ehrhardt of comp.lang.javascript make plain:

kaeli in comp.lang.javascript (Fri, 25 Mar 2005 15:45:35 -0600):

there are an absolute crapload of results from Google. ;)
http://www.google.com/search?hl=en&q...&btnG=Google+S
earch

Which are all pointing to the same article at phpbuilder.com ;-)

Which requires server-side scripting on both sides, which I don't have in
one case, and requires passing an identifier in the URL, which I wanted
to avoid. A workable solution, but not a very clever one, unlike yours!

--
Alan Little
Phorm PHP Form Processor
http://www.phorm.com/

[Alan Little]

Carved in mystic runes upon the very living rock, the last words of
kaeli of comp.lang.javascript make plain:

Out of curiousity, is there a reason simply passing what you need via
the URL won't work for you?

Not that it wouldn't work, I just wanted to avoid it. URLs are more easily
tampered with than cookies, and cookies are just cleaner.

--
Alan Little
Phorm PHP Form Processor
http://www.phorm.com/

[Jan Ehrhardt]

Alan Little in comp.lang.javascript (Fri, 25 Mar 2005 21:06:21 -0600):

Carved in mystic runes upon the very living rock, the last words of Jan
Ehrhardt of comp.lang.javascript make plain:

Jan Ehrhardt in comp.lang.javascript (Fri, 25 Mar 2005 22:22:38 +0100):

<?php
header("Content-Type: application/x-javascript");
$user = $_COOKIE['user'];
?>
var user = "<?php echo $user; ?>";

BTW: if you are passing really sensitive information you ought to be
carefull. Any other page that includes cookie.js gets hold of the same
information.

All they would be getting would be the cookie value from their own
browser, which of course they can get anyway.

Yes, but the third domain has ways to read the cookie value and transfer
it to the server side. And then you might be in trouble.

Jan

[Jan Ehrhardt]

Alan Little in comp.lang.javascript (Fri, 25 Mar 2005 21:11:01 -0600):

One thing: you don't have to do the .htaccess gimmick. You can just use:
<SCRIPT TYPE="text/javascript" src="http://www.domain1.com/cookie.php">

You can never be fully sure of this. There might always be an odd
browser that looks at the .php and decides it is no Javascript. That is
why I use the .htaccess gimmick. Better safe than sorry.

Jan

[Jim Ley]

On Sat, 26 Mar 2005 12:30:14 +0100, Jan Ehrhardt
<mo*****@idem.invalid> wrote:

Alan Little in comp.lang.javascript (Fri, 25 Mar 2005 21:11:01 -0600):

One thing: you don't have to do the .htaccess gimmick. You can just use:
<SCRIPT TYPE="text/javascript" src="http://www.domain1.com/cookie.php">

You can never be fully sure of this. There might always be an odd
browser that looks at the .php and decides it is no Javascript. That is
why I use the .htaccess gimmick. Better safe than sorry.

I've never heard of such a browser, there have been browsers which
ignore the content-type set and will execute everything, but I've not
heard of one which goes the other way, and it would be a very broken
browser. Considering that none of the known major browsers have a
problem, and there's no reported browsers with the non-standard
behaviour, I see nothing wrong with doing it properly.

Jim.

[Jan Ehrhardt]

Jim Ley in comp.lang.javascript (Sat, 26 Mar 2005 11:31:55 GMT):

On Sat, 26 Mar 2005 12:30:14 +0100, Jan Ehrhardt
<mo*****@idem.invalid> wrote:

Alan Little in comp.lang.javascript (Fri, 25 Mar 2005 21:11:01 -0600):

One thing: you don't have to do the .htaccess gimmick. You can just use:
<SCRIPT TYPE="text/javascript" src="http://www.domain1.com/cookie.php">

You can never be fully sure of this. There might always be an odd
browser that looks at the .php and decides it is no Javascript. That is
why I use the .htaccess gimmick. Better safe than sorry.

I've never heard of such a browser, there have been browsers which
ignore the content-type set and will execute everything, but I've not
heard of one which goes the other way, and it would be a very broken
browser. Considering that none of the known major browsers have a
problem, and there's no reported browsers with the non-standard
behaviour, I see nothing wrong with doing it properly.

There is nothing improper in my way of doing it. The browsers request a
..js file and gets it.

Jan

[Alan Little]

Carved in mystic runes upon the very living rock, the last words of Jan
Ehrhardt of comp.lang.javascript make plain:

Alan Little in comp.lang.javascript (Fri, 25 Mar 2005 21:06:21 -0600):

Carved in mystic runes upon the very living rock, the last words of
Jan Ehrhardt of comp.lang.javascript make plain:

Jan Ehrhardt in comp.lang.javascript (Fri, 25 Mar 2005 22:22:38
+0100):

<?php
header("Content-Type: application/x-javascript");
$user = $_COOKIE['user'];
?>
var user = "<?php echo $user; ?>";

BTW: if you are passing really sensitive information you ought to be
carefull. Any other page that includes cookie.js gets hold of the
same information.

All they would be getting would be the cookie value from their own
browser, which of course they can get anyway.

Yes, but the third domain has ways to read the cookie value and
transfer it to the server side. And then you might be in trouble.

I guess I still don't see the problem. Let's say I'm Joe Hacker. I go to
domain1 and log in, and get a cookie: uid=jhakr. Now, the intent in
creating cookie.php is to make it so domain2 can retrieve that value. But
let's say that I instead go to domain3, my own little evil domain, and
create a page that calls cookie.php on domain1. All I'm going to get is
uid=jhakr, which I already have anyway.

--
Alan Little
Phorm PHP Form Processor
http://www.phorm.com/

[Jan Ehrhardt]

Alan Little in comp.lang.javascript (Sat, 26 Mar 2005 10:13:18 -0600):

Yes, but the third domain has ways to read the cookie value and
transfer it to the server side. And then you might be in trouble.

I guess I still don't see the problem. Let's say I'm Joe Hacker. I go to
domain1 and log in, and get a cookie: uid=jhakr. Now, the intent in
creating cookie.php is to make it so domain2 can retrieve that value. But
let's say that I instead go to domain3, my own little evil domain, and
create a page that calls cookie.php on domain1. All I'm going to get is
uid=jhakr, which I already have anyway.

But now suppose you are Alan Little and Joe Hacker tricks you into
visiting domain3. Your browser calls cookie.php which presents
uid=alitl. Joe Hacker stores your uid and any other sensitive
information cookie.php wants to transfer. Joe Hacker gets a very big
smile on his face when he sees you are giving your data away.

Jan

[Martin Bialasinski]

Alan Little <al**@n-o-s-p-a-m-phorm.com> wrote:

Jan Ehrhardt in comp.lang.javascript (Fri, 25 Mar 2005 22:22:38
+0100): BTW: if you are passing really sensitive information you ought to be
carefull. Any other page that includes cookie.js gets hold of the
same information.

I guess I still don't see the problem. Let's say I'm Joe Hacker. I go to
domain1 and log in, and get a cookie: uid=jhakr.
Or a session ID, works better for the authentication example.
Now, the intent in creating cookie.php is to make it so domain2 can
retrieve that value.

The page from domain2 includes cookie.js, which then makes the session
ID from domain1 available to javascript on this page from domain2.

The script now sets a session ID cookie for domain2 with this value,
so domain2 checks the DB shared with domain1 to check if the session ID
is valid.

=> Login to domain1 automatically also logs in to domain2.

You are now logged in and decide to visit evildomain.

The page from evildomain includes cookie.js from domain1, which makes
the session ID from domain1 available to the page from evildomain.
On this page is a script, that now submits the session ID to the
evildomain server. For example by creating a img node with source
evildomain/sid-grabber.jpg?[$sessionid]

Now the guy at evildomain has a valid session ID.

He can now impersonate you on domain1 to grab your stuff by just
sending the captured session ID as a cookie with the request.

Bye,
Martin

[Alan Little]

Carved in mystic runes upon the very living rock, the last words of Jan
Ehrhardt of comp.lang.javascript make plain:

Alan Little in comp.lang.javascript (Sat, 26 Mar 2005 10:13:18 -0600):

Yes, but the third domain has ways to read the cookie value and
transfer it to the server side. And then you might be in trouble.

I guess I still don't see the problem. Let's say I'm Joe Hacker. I go
to domain1 and log in, and get a cookie: uid=jhakr. Now, the intent in
creating cookie.php is to make it so domain2 can retrieve that value.
But let's say that I instead go to domain3, my own little evil domain,
and create a page that calls cookie.php on domain1. All I'm going to
get is uid=jhakr, which I already have anyway.

But now suppose you are Alan Little and Joe Hacker tricks you into
visiting domain3. Your browser calls cookie.php which presents
uid=alitl. Joe Hacker stores your uid and any other sensitive
information cookie.php wants to transfer. Joe Hacker gets a very big
smile on his face when he sees you are giving your data away.

OK, I see what you're getting at. But rather than relying on
HTTP_REFERER, which may or may not be passed by the browser, just check
the location object. Since we're doing Javascript and all. :)

--
Alan Little
Phorm PHP Form Processor
http://www.phorm.com/

[Jan Ehrhardt]

Alan Little in comp.lang.javascript (Sat, 26 Mar 2005 22:27:31 -0600):

Carved in mystic runes upon the very living rock, the last words of Jan
Ehrhardt of comp.lang.javascript make plain:

But now suppose you are Alan Little and Joe Hacker tricks you into
visiting domain3. Your browser calls cookie.php which presents
uid=alitl. Joe Hacker stores your uid and any other sensitive
information cookie.php wants to transfer. Joe Hacker gets a very big
smile on his face when he sees you are giving your data away.

OK, I see what you're getting at. But rather than relying on
HTTP_REFERER, which may or may not be passed by the browser, just check
the location object. Since we're doing Javascript and all. :)

Then you still would have to reveal your sensitive data. You will have
to prevent the PHP-part of cookie.js to reveal the uid etc.

Jan

[Alan Little]

Carved in mystic runes upon the very living rock, the last words of Jan
Ehrhardt of comp.lang.javascript make plain:

Alan Little in comp.lang.javascript (Sat, 26 Mar 2005 22:27:31 -0600):

Carved in mystic runes upon the very living rock, the last words of Jan
Ehrhardt of comp.lang.javascript make plain:

But now suppose you are Alan Little and Joe Hacker tricks you into
visiting domain3. Your browser calls cookie.php which presents
uid=alitl. Joe Hacker stores your uid and any other sensitive
information cookie.php wants to transfer. Joe Hacker gets a very big
smile on his face when he sees you are giving your data away.

OK, I see what you're getting at. But rather than relying on
HTTP_REFERER, which may or may not be passed by the browser, just check
the location object. Since we're doing Javascript and all. :)

Then you still would have to reveal your sensitive data. You will have
to prevent the PHP-part of cookie.js to reveal the uid etc.

But you would only be revealing it to the user's browser. The page on
evildomain tells your browser to request the script from domain1. Let's
suppose that script is not secure, and simply sets a var or cookie with
the value; at this point evildomain still has to do something to retrieve
the information, such as create a form object and submit it. If the code
from domain1 doesn't make the information available *programatically*,
then there's nothing the evil page can do with it. The initial
transaction is between the user's browser and domain1. If the user's
browser would display remote code, then s/he could view source and see
something like:

if (location.host == 'gooddomain.com') document.cookie = 'uid=guser';

but that does no good for the hacker's code.

--
Alan Little
Phorm PHP Form Processor
http://www.phorm.com/

[Jan Ehrhardt]

Alan Little in comp.lang.javascript (Sun, 27 Mar 2005 07:46:36 -0600):

Carved in mystic runes upon the very living rock, the last words of Jan
Ehrhardt of comp.lang.javascript make plain:

Alan Little in comp.lang.javascript (Sat, 26 Mar 2005 22:27:31 -0600):

Carved in mystic runes upon the very living rock, the last words of Jan
Ehrhardt of comp.lang.javascript make plain:

But now suppose you are Alan Little and Joe Hacker tricks you into
visiting domain3. Your browser calls cookie.php which presents
uid=alitl. Joe Hacker stores your uid and any other sensitive
information cookie.php wants to transfer. Joe Hacker gets a very big
smile on his face when he sees you are giving your data away.

OK, I see what you're getting at. But rather than relying on
HTTP_REFERER, which may or may not be passed by the browser, just check
the location object. Since we're doing Javascript and all. :)

Then you still would have to reveal your sensitive data. You will have
to prevent the PHP-part of cookie.js to reveal the uid etc.

But you would only be revealing it to the user's browser. The page on
evildomain tells your browser to request the script from domain1. Let's
suppose that script is not secure, and simply sets a var or cookie with
the value; at this point evildomain still has to do something to retrieve
the information, such as create a form object and submit it. If the code
from domain1 doesn't make the information available *programatically*,
then there's nothing the evil page can do with it. The initial
transaction is between the user's browser and domain1. If the user's
browser would display remote code, then s/he could view source and see
something like:

if (location.host == 'gooddomain.com') document.cookie = 'uid=guser';

but that does no good for the hacker's code.

I suppose you are right. But still I have a bad feeling about this.

Jan

[Alan Little]

Carved in mystic runes upon the very living rock, the last words of Jan
Ehrhardt of comp.lang.javascript make plain:

Alan Little in comp.lang.javascript (Sun, 27 Mar 2005 07:46:36 -0600):

Carved in mystic runes upon the very living rock, the last words of
Jan Ehrhardt of comp.lang.javascript make plain:

Alan Little in comp.lang.javascript (Sat, 26 Mar 2005 22:27:31
-0600):

Carved in mystic runes upon the very living rock, the last words of
Jan Ehrhardt of comp.lang.javascript make plain:

> But now suppose you are Alan Little and Joe Hacker tricks you into
> visiting domain3. Your browser calls cookie.php which presents
> uid=alitl. Joe Hacker stores your uid and any other sensitive
> information cookie.php wants to transfer. Joe Hacker gets a very
> big smile on his face when he sees you are giving your data away.

OK, I see what you're getting at. But rather than relying on
HTTP_REFERER, which may or may not be passed by the browser, just
check the location object. Since we're doing Javascript and all. :)

Then you still would have to reveal your sensitive data. You will
have to prevent the PHP-part of cookie.js to reveal the uid etc.

But you would only be revealing it to the user's browser. The page on
evildomain tells your browser to request the script from domain1.
Let's suppose that script is not secure, and simply sets a var or
cookie with the value; at this point evildomain still has to do
something to retrieve the information, such as create a form object
and submit it. If the code from domain1 doesn't make the information
available *programatically*, then there's nothing the evil page can do
with it. The initial transaction is between the user's browser and
domain1. If the user's browser would display remote code, then s/he
could view source and see something like:

if (location.host == 'gooddomain.com') document.cookie =
'uid=guser';

but that does no good for the hacker's code.

I suppose you are right. But still I have a bad feeling about this.

I'm the first to admit I'm rather dense on security issues. I feel like
Rainman sometimes ("Yeah. I'm an excellent programmer.") I can write code
that will make your computer dance a jig and whistle Dixie, but unless
I'm careful, anybody else can make your computer dance a jig and whistle
Dixie, too. I have to really slow down and look things over to be sure
I'm not missing something.

I spent about an hour (literally) looking over this, and the only way I
can see that a hacker could get that value is if s/he is sniffing your
traffic or has compromised the other server, in which case this is a moot
issue anyway.

So, it meets my comfort level. But that doesn't mean I haven't overlooked
something. If you or anyone else thinks of something, feel free to speak
up.

--
Alan Little
Phorm PHP Form Processor
http://www.phorm.com/

[kaeli]

In article <Xn**************************@216.196.97.131>, alan@n-o-s-p-a-m-
phorm.com enlightened us with...

Which requires server-side scripting on both sides, which I don't have in
one case, and requires passing an identifier in the URL, which I wanted
to avoid. A workable solution, but not a very clever one, unlike yours!

Yeah, that one was quite neat.
I am so used to having server-side scripting, I forget some people don't have
it. *g*

You *can* obfuscate the URL params, though, to make them pretty hard to putz
with in any meaningful way.

I really like Jan's solution, though.

--
--
~kaeli~
It was recently discovered that research causes cancer in
rats.
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace