Well, I’m somewhere hovering around a third of the way through the new version of Hacking Web Applications Exposed 2 and I ran across a section talking about how you can measure the time it takes for pages to return as a measurement of the logic overhead. Wow. I credit Arian Evans with this idea personally, but I’m not sure if the origins pre-date him. As a result of this function you can actually tell what is going on within the internal server logic.
Here’s how it works. Let’s say, to make this easy, there are two paths of logic within a sign-in application. The first path is a valid username with an invalid password and the second is an invalid username with an invalid password. Either way the application logic ends up in a sign-in failure and if the user interface designers built it correctly it gives an anonymous error state that says something like, “Either your username and/or your password is incorrect. Please try again.” That is to not tell the attacker anything about what happened if they happened to have found a valid username or not to begin their attack against.
From the outside this should provide you no information about the account from an attacker perspective but if you measure the time difference between the two application logic paths they can easily provide you with more information than they intend to. Let’s take the first path. 1) It has to make a query to the database first to insure that the user name exists. 2) Then perhaps to check if it is in a valid state. 3) Then maybe it checks to make sure that the user has not tried logging in too many times with failed attempts. 4) Then lastly it hashes the password using the same salt as the hash for the appropriate password and does a string compare. 5) After this it errors out as you would expect.
Now let’s contrast that with the second path. 1) It has to make a query to the database first to insure that the user name exists. 2) Upon finding no password, it errors out immediately.
Of course this is a simplistic example but you can plainly see that the first path is far more complex and requires more CPU cycles and database lookups than the second path, meaning that it will take far less time. With a known userid you can test the difference between that user and one that is highly statistically unlikely to exist like “189hdjhnt2h1″
Measuring the difference between the first and second paths of a single function will let you know information about the internal application logic that the presentation layer does not disclose. Pretty interesting stuff, and I hadn’t heard it anywhere else. So far, it’s a pretty good book. I can’t wait to find enough time to sit down and read the rest of it.