Re: Insecure Ids - Need explanation

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

That's more of an authorization attack, which is detailed in the  
authorization chapter.

The session chapter needs to be clearer (see my other post) about  
what we mean to avoid session fixation / CSRF attacks. It's no longer  
enough to rely on framework session IDs, particularly from sites that  
have permissive session generators (ie if you don't have a session  
ID, the framework gives you one).

Knowing the JSESSIONID/PHPSESSIONID/ASPSESSIONID grants you access to  
the user's session object. Many trojans capture cookies and many XSS  
attacks also capture this value. So the idea of this section is to  
ensure that you must:

1. know the framework's session identifier
2. know the "hidden" strongly pseudo random page / function token
3. and come from the same user agent and IP address (and any other  
semi-trustable HTTP headers)

Most applications stop at #1 and are trivially attacked by most  
trojans and XSS attacks. Some apps add a quite bad #2, which makes it  
even easier to attack, particularly if they try to be stateless and  
thus deliberately don't know about the framework's session object. An  
example of this I've seen recently is a very large company's  
integration layer. They used a monotonically increasing "transaction  
number" to separate SOAP requests from different users. It was easy  
to change to a different transaction number:

POST /xmlrpc.aspx ...
transactionid=1&attack data

Obviously ... becoming transactionid 2's user was easy. That's what  
this sentence was really worried about.  I've seen this a few times.  
Variations on a theme include a Cognos PowerPlay attack from a few  
years ago:

http://www.packetstormsecurity.org/9906-exploits/cognos.powerplay.txt

The session was in a predictable temporary file. I've seen this type  
of attack since then, too.

thanks,
Andrew

On 18/04/2006, at 6:54 AM, Patrick wrote:

> It's worded confusingly, but I think the point they're trying to  
> get across
> here is that if you have an easily guessable function- let's say  
> you have a
> web application that you notice has the following url:
> ...
> So if your application doesn't do a check to see that the caller is
> authenticated for a given function, then anyone can perform that  
> function.
> ...
> The moral of the story is: authenticate a user and then check for
> authorization for your function calls.  Don't rely on obscure urls  
> that can
> only be found by clicking a certain page as the level of security  
> needed for
> keeping people out of administrative features on your applications.

Attachment: smime.p7s
Description: