Cenzic 232 Patent
Paid Advertising
sla.ckers.org is
ha.ckers sla.cking
Sla.ckers.org
Q and A on cross site request forgeries and breaking into sessions. It's one of the attacks that XSS enables and the attack of the future. For Session, fixations, hijacking, lockout, replay, session riding etc.... 
Go to Topic: PreviousNext
Go to: Forum ListMessage ListNew TopicSearchLog In
Javascript and same-origin policy
Posted by: dsan
Date: May 02, 2007 04:53AM

Found a strange architectural option today, once i've not seen deployed yet and wanted to throw it to the crowd to see what they think.

This site I'm testing stores the session ID in a JavaScript variable, and embeds it in every HTTP post request - there is no session cookie (or any other cookie). AFAIK, JavaScript hijacking will only work if there is an existing session cookie so that the attacker can make an XSRF style request to the vulnerable site from his own malicious site, and then read any Javascript vars set in the vulnerable site. But this doesn't apply if there is no session cookie (because there's no way to do the XSRF). right?

Is there any other way to get at a JavaScript variable from another site?

Options: ReplyQuote
Re: Javascript and same-origin policy
Posted by: dsan
Date: May 02, 2007 06:32AM

Adding to my own post, scary...

The attack window should be the same; as both scenarios rely on the
session being established prior to the attack delivery.

The basic session riding stuff goes away, as it won't be spat out in any
cookie related side effects (HTML injection etc).

XSS attacks are slightly more simple, as you now just grab the variable
contents from the javascript context (avoids htmlonly flag etc for
messing with the cookies).

XSRF should be generally the same (as long as you deliver via a XSS)
using a query plus the variable as an argument etc (don't forget the
POST is easily delivered via the script).

You get other problems though, as now the session ID is embedded in the
body of the HTTP response, so is likely to be cached and stored all over
the shop.

Surely others have encountered this? this board cant be full of baby xss :p

Options: ReplyQuote
Re: Javascript and same-origin policy
Posted by: WhiteAcid
Date: May 02, 2007 06:50AM

It first glance using the method you mention should be the same as using a normal cookie. The downside is that you cannot implement HTTP only and there are no plus sides I can see.

If you find an XSS flaw you've beaten it, but that's a given. Once you have an XSS flaw you've already lost the game anyway. I don't know why they'd chose the method they are doing as it makes the site that little more complicated to build and maintain, but there's nothing hugely wrong with it.

Am I missing something huge and obvious here?

Don't forget our IRC: irc://irc.irchighway.net/#slackers
-WhiteAcid - your friendly, very lazy, web developer

Options: ReplyQuote
Re: Javascript and same-origin policy
Posted by: ma1
Date: May 02, 2007 06:51AM

It's very similar, if not identical, to session persistence via url rewriting, a very common fall-back found in many sites if you browse with cookies disabled (as I usually do).

Url rewriting is even worse than cookies as a session-persistence mechanism, as it's easier giving away your session "by accident", e.g. using copy&paste from your location bar or quoting a link verbatim inside a forum post.

On the other hand, it's less vulnerable to "blind" CSFR, as you need a rewritten URL to start with (while cookies are for free).

--
*hackademix.net*

There's a browser safer than Firefox... Firefox, with NoScript



Edited 1 time(s). Last edit at 05/02/2007 07:06AM by ma1.

Options: ReplyQuote
Re: Javascript and same-origin policy
Posted by: WhiteAcid
Date: May 02, 2007 06:52AM

Unless I fail at reading the site in question isn't appending the session id to urls. If it did, yeah, that sucks. You could even be giving that out in the referer to images other people place on the site.

Don't forget our IRC: irc://irc.irchighway.net/#slackers
-WhiteAcid - your friendly, very lazy, web developer

Options: ReplyQuote
Re: Javascript and same-origin policy
Posted by: ma1
Date: May 02, 2007 07:12AM

WhiteAcid Wrote:
-------------------------------------------------------
> Unless I fail at reading the site in question
> isn't appending the session id to urls.

My bad, if the site does only POST requests, then it's not vulnerable to copy&paste.
All the rest we said stands, IMHO, included the PITA to mantain such a thing, disproportionate if it's done just for security reason.

--
*hackademix.net*

There's a browser safer than Firefox... Firefox, with NoScript

Options: ReplyQuote
Re: Javascript and same-origin policy
Posted by: dsan
Date: May 02, 2007 08:05AM

Agree with all the responses, this is a tight app and a right f**ker to test (damn those developers who listen to what we say)

Options: ReplyQuote
Re: Javascript and same-origin policy
Posted by: kirke
Date: May 06, 2007 03:31PM

> .. if there is no session cookie (because there's no way to do the XSRF). right?
wrong
depends on the transport technique of the session id, see below

> Is there any other way to get at a JavaScript variable from another site?
XSS, or only due to browser bugs, for example the mhtml problem in IE...

> The basic session riding stuff goes away, as it won't be spat out in any
cookie related side effects (HTML injection etc).
wrong i.g.
If the session id is transported using basic/digest authentication, session riding works the same way.

> It's very similar, if not identical, to session persistence via url rewriting,
session riding is not possible with URL rewriting (as long as there is no XSS in the page itself). This is a major advantage over cookies.

> Url rewriting is even worse than cookies as a session-persistence mechanism, as it's easier giving away your session ..
That's a strong statement.
From the view of web application security, it's not the fault of the application if there is a server inbetween which can be hijacked to view/steal logfiles or whatever.
With URL rewriting the application can ensure the security of its own session (beside sholder surfing and hijacking other systems), while cookies are subject to countless attacks all over the domain far out of control of the application.

> .. using copy&paste from your location bar ..
this is the users own fault, not a problem of the application.
Or should we talk about the most stupid user?

> .. You could even be giving that out in the referer to images
That's indeed a programming error.
But why the hell should a secure web application call images from a diffrent site?

Options: ReplyQuote


Sorry, only registered users may post in this forum.