Re: Insecure Ids - Need explanation

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.