So…so you think you can tell

[This was originally posted July 2003 on the now-defunct vulns.com site. Even several years later no web application scanner can automatically identify such vulnerabilities in a reliable, accurate manner — many vulnerabilities still require human analysis.]

Sit and listen to Pink Floyd’s album, Wish You Were Here. “Can you tell a green field from a cold steel rail?” Yes. Could you tell a buffer overflow from a valid username in a Web application? Yes again. What about SQL injection, cross-site scripting, directory traversal attacks, or appending “.bak” to every file? Once again, Yes. In fact, many of these attacks have common signatures that could be thrown into Snort or passed through a simple grep command when examining application log files. These are the vulnerabilities that are reported most often on sites like www.cgisecurity.com or www.securityfocus.com. And they pop up for good reason: they’re dangerous and quickly cripple an e-commerce application.

On the other hand, a different category of attacks has not yet crept far enough into the awareness of security administrators and application programmers: session attacks. There are several reasons for this relative obscurity. No automated tool does a proper job of identifying session vulnerabilities without customization to the application. There are no defined signatures to try, as opposed to the simpler single quote insertion for a SQL injection test. Most importantly, session state vulnerabilities vary significantly between applications.
The consequence of session attacks is no less severe than a good SQL injection that hits xp_cmdshell. Consider last May’s Passport advisory in which an attacker could harvest passwords with tools no more sophisticated than a Web browser. The attack relies on selecting proper values for the “em” (victim’s e-mail) and “prefem” (attacker’s e-mail) parameters to the emailpwdreset.srf file. It should really be stressed that nowhere in this attack were invalid characters sent to the server. Both parameters were attacked, but the payload contained valid e-mail addresses – not e-mail addresses with single quotes, long strings, Unicode encoded characters, or other nefarious items.

The attack succeeded for two major reasons. The e-mail addresses are exposed to the client, rather than tracked on the server in a session object. The four steps ostensibly required for a user to complete the password reminder process did not have to be performed in sequential order, which demonstrates lack of a strong state mechanism.

It seems that most buffer overflow-style attacks against operating systems or Internet servers such as IIS or Apache have led to site defacements or denial of service attacks. Yet as e-commerce has grown with Web applications, so have the vulnerabilities moved on from buffer overflows. Plus, the attacks against Web applications no longer lead to site defacement, but to identity or financial theft (credit cards). Thus, vulnerabilities that used to affect only the server’s owners (and perhaps annoy users who can’t access the service for a period) now include Web application vulnerabilities that quite directly affect users.
As administrators and programmers, we need to be aware of all the vulnerabilities that crop up in Web applications – not just the easy (yet still important!) ones that currently populate the Web vulnerability encyclopedia.