Understanding the Attack
The Open Web Application Security Project lists this type of attack as easy to exploit, and easy to detect. If that is the case, why then is this attack also listed as number four on their top ten of 2010 with a prevalence of common?
Before we can dig into that enticing question, we should look at how a maneuver of this kind is carried out. In its simplest form this vulnerability can be exploited by modifying a URL string with something like this: http://vunerableSite.com/cms/accountInfo?LoggedIn=True&userID=45674 Your Account http://vunerableSite.com/cms/accountInfo?LoggedIn=True&userID=45675 Not Your Account Fun right? And there’s more fun to be had here.
If you want to dig a bit deeper, load up your favorite proxy, poison some hidden parameters and you are on your way. What you will probably find is access to data the developer did not intend for you to see.
These vulnerabilities seem to be most common right now behind one level of authentication, so log into the application you are testing first, and then twist data. One would think that by now such easy web application hacks would rarely exist, emerging in conversations amongst veterans about the days of old.
The reality, as anyone who spends time researching web application vulnerabilities will likely tell you (and the OWASP top 10 of 2010 agrees), is that these Insecure Direct Object Reference Vulnerabilities (IDORV) are still common place. But enough on this easy attack, you found your hole, what’s next?
Level Two: Leveraging the Hole
Once an attacker has discovered a gap in your web app like this, they will likely script up to get to the next level.
Using the previous example, we would write a script that cycled through a series of GET or POST requests, incrementing the poisoned parameter through values as necessary. The responses are then saved off and collected. The attacker may now have all possible data directly associated with the insecure object in question.
In some cases, this will be a lot of data that should not be accessible to any user. OWASP lists these IDORV’s as easy to detect. But what did they have in mind?
In my next post, I will take a look at some of the different ways that I found to detect these kinds of attacks against your web applications using log data. Because many of the parameters in your GET and POST requests are not written to your web server logs by default we will have to looks for some other ways to observe this kind of behavior.