WebApp Sec mailing list archives
Re: Insecure Ids - Need explanation
From: Andrew van der Stock <vanderaj () greebo net>
Date: Tue, 18 Apr 2006 10:25:36 +1000
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 token3. 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 dataObviously ... 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.txtThe 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 aweb application that you notice has the following url: ... So if your application doesn't do a check to see that the caller isauthenticated for a given function, then anyone can perform that function.... The moral of the story is: authenticate a user and then check forauthorization 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 forkeeping people out of administrative features on your applications.
Attachment:
smime.p7s
Description:
Current thread:
- Insecure Ids - Need explanation susam_pal (Apr 17)
- RE: Insecure Ids - Need explanation Patrick (Apr 17)
- Re: Insecure Ids - Need explanation Andrew van der Stock (Apr 17)
- Re: Insecure Ids - Need explanation Reid Nichol (Apr 17)
- RE: Insecure Ids - Need explanation Rod Divilbiss (Apr 17)
- RE: Insecure Ids - Need explanation M. Burnett (Apr 17)
- Re: Insecure Ids - Need explanation Andrew van der Stock (Apr 17)
- RE: Insecure Ids - Need explanation Patrick (Apr 17)