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 app? Yes again. What about SQL injection, cross-site scripting, directory traversal attacks, or appending “.bak” to every file? Once again: Yes.

Many of these attacks have common signatures that could be thrown into Snort or passed through a simple grep command when examining log files. These are the vulns that are reported most often on sites like www.cgisecurity.com or www.securityfocus.com. They pop up for good reason – they’re dangerous and can undermine an app.

On the other hand, a different category of attacks has not yet crept far enough into the awareness of security admins and developers – session attacks. There are several reasons for this relative obscurity. No automated tool does a proper job of identifying session vulns without customization to the app. There are no defined signatures to try, as opposed to the simpler single quote insertion for a SQL injection test. Most importantly, session state vulns vary significantly between apps.

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 browser. The attack relies on selecting proper values for the em (victim’s email) and prefem (attacker’s email) parameters to the emailpwdreset.srf page. 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 email addresses -– not email addresses with single quotes, long strings, Unicode encoded characters, or other nefarious items.

The attack succeeded for two major reasons. The email 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, so have the vulns moved on from buffer overflows. Plus, attacks no longer just stick to site defacement, but have moved into identity or financial theft. Attacks that used to primarily affect only the site’s owners (and perhaps annoy users who can’t access the site for a while) now include more that directly affect users.

As admins and devs, we need to be aware of all the vulns that crop up in apps -– not just the easy (yet still important!) ones that currently populate the web vuln encyclopedia.

This was originally posted in July 2003 on the now-defunct vulns.com. Even several years later when I re-published it on the blog in 2008, no web app scanner could automatically identify such vulns in a reliable, accurate manner. Now 20 years later in 2023, many vulns still require human analysis.