Re: Insecure Ids - Need explanation

[Andrew van der Stock <vanderaj () greebo net>]

Hi Susam,

This is a wordy way of saying "validate session tokens properly, or  
suffer session fixation attacks". This section needs revising for the  
simple reason that it is no longer good enough to rely on the  
JSessionID or ASPSESSIONID or similar alone, which is what the  
chapter currently says.

Authors need to ensure that they include a strongly pseudo random  
page or function token for value transactions, which may include  
private pages if you have a large reputation risk.

eg:

POST /foo.php ...
token=7384673674376476367437&action=payanyone&acct=54875847&bsb=545454&a 
mount=9999

The token is also kept on the server side in the session object for  
the user, and you only process the transaction if client and server  
agree that the token are the same.

eg:

if ( session("token") === $_POST['token'] )
{
        // invalidate the token for this request to prevent double submissions
        session("token") = $sessionHandler->generateNewToken();    

        // process the payment
	if ( processPayAnyOne($_POST['acct'], $_POST['bsb'], $_POST 
['amount']) )
        {
		redirect(succeedURL, 0); // the next page will include the new  
token in the POST data
        }
        else
        {
                redirect(failURL, 0);   
        }
}

For example of an attack like this, many forum softwares allow  
attackers to set a remote avatar image URL in their profile like this:

http://www.example.com/forum/logout.php

and the software does not validate that the remote avatar URL is  
actually an image. Of course, this logs out all users who see that  
"avatar". This can be avoided in three ways:

a) include a page / function token and check it in logout.php - this  
is the approach UltimaBB takes and is similar to the method  
demonstrated above
b) validate that the remote avatar image is an actual image before  
every view - this is the approach phpBB with some avatar hacks take
c) take a copy of the remote avatar image (if it is indeed an image)  
and store it locally to prevent further tampering - this is the  
approach vBulletin now takes

The entire idea is to prevent a worse attack, where the attacker  
might be able to force the user to a page, like this:

http://www.examplebank.com/transfer.php? 
action=payanyone&acct=54875847&bsb=545454&amount=9999

If a intercepting trojan has your cookie - which includes many  
applications *only* session token, using a function / page token can  
prevent that attack... but some trojans also keep post and get data,  
so you need to validate a few semi-trustworthy headers as well. To  
the mix of a truly random page / function token, you should also  
check that the client's IP address and User Agent doesn't change -  
but don't trust them - use a hash of the values. Any change is likely  
to be an attack. But this is only a temporary measure - Bank Phishing  
Trojans could easily be adapted to fake these as well if you take and  
hash fakeable headers.

The solution to this issue - to be done right now - is disconnected  
transaction signing for high value transactions. I would have said  
that banks need to do this by 2007, but honestly, with the latest  
Banking trojans out and about, places running high value sites over  
the internet need to introduce controls like this very soon if not  
already. The values the user should enter include into the token  
include the value and at least part of the destination or source  
account (or whatever works best for the transaction your app is doing).

Connected transaction signing devices, such as USB connected tokens  
or smart cards allow the user to go "yep, I agree" whenever they see  
a transaction signing request pop up on the screen. This happens  
today with MacOS X - when was the last time a MacOS X user clicked  
the triangle to see the detail of the requesting application? I don't  
do it, and I'm a tinfoil hat paranoid when it comes to security.

thanks,
Andrew
- OWASP Guide Lead


On 18/04/2006, at 2:18 AM, susam_pal () yahoo co in wrote:

> "If an attacker can guess these id’s, and the supplied values are  
> not validated to ensure the are authorized for the current user,  
> the attacker can exercise the access control scheme freely to see  
> what they can access."
>
> I have never used such ids, indexes or keys when I developed  
> authentication systems to reference users or roles. What kind of  
> ids or keys are we talking about? How can an attacker use a guessed  
> id?

Attachment: smime.p7s
Description: