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
Anti XHR
Posted by: digi7al64
Date: January 24, 2007 02:29AM

One of the security issues involving ajax is the ability for the malicous script to push and pull data to and from the client without the client knowing. Generally the key purpose of the original pull is to grab the authenication token used in the subsequent push to validate the post. Therefore the focus has been on securing the token, token patterns etc. However once a XHR has the data it is simply a matter of searching for the token in the string. Unfortunately, without disabling XHR this will not stop.

So, having read a number of posts/articles on the subject lately i though i would add my suggestion to the mix and get some feedback.

Basically it works like this, consider the following page.

<html>
<head>
<script>
var token = "11111";
</head>
<body>
<body>
</html>

In javascript we could easily request this page via ajax and using js we can simply search the text until we find the keyword "token", from there it is only a few more steps to get the value.

next consider the following

<html>
<head>
<script>
var token = "11111";
function decode() {
token = token + 1234;
}
</head>
<body onload="decode();">
<body>
</html>

In this example we call the onload function to decode the original token value. This in itself presents a number of problems for string matching logic as this code returned via ajax is in fact a string an not a browser instance and therefor the onload function isn't interpreted/called and hence the token value would be incorrect.

Now consider if we have a extremely complex decoding function that uses more then just a simple addition and that instance of the decode function is unique to every page request (dynamically created at run time). And be this i mean, unique function names, different methods of encoding etc.

<html>
<head>
<script>
var token = "11111";
function unique_name() {
//obscufated code goes here
//which appends the submission form
//adding a new hidden input
//with the real token value
}
</head>
<body onload="unique_name();">
<body>
</html>

How exactly would someone go about attacking that?

----------
'Just because you got the bacon, lettuce, and tomato don't mean I'm gonna give you my toast.'

Options: ReplyQuote
Re: Anti XHR
Posted by: kuza55
Date: January 24, 2007 06:44AM

I'd just get the JS engine to do it for me. Either by using an iframe (the preferred method), or by using a popunder. or even just extracting the JS, and executing it via eval.

You may try to do something like break out of frames, or check I'm on the correct page or whatever, but considering I can essentially reassemble the page however I want, and overload and overwrite everything there is no way to win, since your code is going to be fairly static (even if it changes a bit) and will have to think of everything, an attacker would just have to work out a single way to get past it.

So while its an interesting idea that would stop a lot attacks, its not fool proof.

Options: ReplyQuote
Re: Anti XHR
Posted by: rsnake
Date: January 25, 2007 10:43AM

I was thinking the same thing as I read this. If the JS to de-obfuscate the token is on the page, you can use the same JS to do the same thing since it's right there and visible to you.

- RSnake
Gotta love it. http://ha.ckers.org

Options: ReplyQuote


Sorry, only registered users may post in this forum.