Jeremiah Grossman has an article in CSOonline wherein he calls the current web application security methods (review code, find flaws, fix) insane and proposes web application firewalls as the better alternative.

It is unreasonable to expect publishers, enterprises and other site owners to restart and reprogram every website securely from scratch. Nor can we fix the hundreds of thousands (maybe millions) of custom Web application vulnerabilities one line at time. The very thought sounds insane to me. It would take too long (probably never finish), cost far too much (billions per year), and the bad guys are already ahead of us.

…..

We have to be able to detect flaws, react faster, and adapt better on an Internet-wide scale. Web application vulnerability assessment solutions like those provided by WhiteHat Security are able to do this and then inform businesses of where the problem spots are. To address identified issues quickly Web application firewall (WAF) technology is getting a serious look. Recent technology advancements enable vulnerability assessment results to pipe straight into a WAF as virtual patches.

Honestly it sounds good (really it does), and I know many entities which have been forced to dos omething similar (most didn’t call it a WAF at the time) when faced witht his problem. (That being too many applications and too little time).

My general feeling on WAFs is that the centralization and tremndous time savings can be a boon to many enterprises, but that signature systems will always have flaws, and need to be constantly maintained and updated. To use a metaphor, think of traditional port filtering firewalls and IDS/IPS. Imagine an admin who has only an IPS, and must constantly be on the lookout for new attacks so that he can write new signatures and block them. Then there is thefirewall with a default deny. That admin knows that only specific ports are allowed through because only those services are needed and on which machines they reside. His life is a lot easier (although admittedly he still has to worry about application vulnerabilities). Once again however, Jeremiah has beaten my thought process to the punch.

To implement default-deny Web Application Firewalls (WAF) must know everything about a website at all times, even when they change.

What we need to do for web applications is do what we did for networks in the past – learn everything. We need to know which applications do what, and what inputs and outputs they should have. Hard? yes. But ultimately it will be better than the alternative.

_[^!_%/%a?F%_D)_(F%)_%([)({}%){()}£$&N%_)$*£()$*R"_)][%](%[x])%a][$*"£$-9]

There’s a new paper out on SQL injection DoS attacks. Given the severity of the claims, I don’t see why this isn’t getting more coverage. The authors purport that almost any server with a SQL back-end and a search form is vulnerable. Essentially, they craft SQL queries that take an exorbitantly long amount of time to execute. When launching a small handful of them, you can actually make a database completely unresponsive. Although perhaps not as damaging as traditional SQL injection (most people would rather have their data unavailable rather than in the hands of an attacker), it appears to be much easier to execute, so it probably won’t be long before people start seeing this show up everywhere.

Why am I only finding out about this now (also reported by wired)?

Oleksandr Dorozhko hacked a system containing information on IMS health that would negatively affect their stock price. (Or, possibly, someone else hacked the system and gave him the information). He invested in puts and netted himself about $300,000 in one day. The SEC noticed and tried to block it, but the court has ruled that a hacker is not an insider, and therefore insider trading does not apply. Mr. Dorozhko gets to keep every cent of his admittedly ill-gotten gains.

I remember back in “the good old days” people would laugh at web defacements. It might be a way for a hacker to prove themselves or gain their fifteen minutes of fame on 2600, but it was not a gateway to sensitive or important information. The web was, after all, nothing more than an advertisement – a billboard on the information superhighway. Organizations had important information on computers, but none of it was on web servers. Web page defacements were akin to graffiti, not corporate espionage.

Fast forward to today, and it’s remarkable how everything has changed. The web has begun supplanting the other 65535 ports on the internet. Although e-commerce was the first thing to change the web from a static billboard to a method of transmitting sensitive data, it is web applications which have done the most recently. Now everything occurs over the web – companies use SOAP to transmit sensitive information between them, and back-end databases frequently hold incredibly important data. Even services which were originally designed to function over other protocols, such as remote administration, email, and file transfer, have now begun to migrate to the web. The bottom line is that the web matters. There are still the electronic graffiti artists who want nothing more than their 15 minutes of fame on zone-h.org, but serious hackers are eying the web too.

I remember some time ago I got into a long discussion with someone at work that at its essence revolved around the question of whether or not the web mattered. I essentially argues my old position, more out of habit than anything else, while he argues that the web was of paramount importance (although admittedly he had other ulterior motives for taking that position). I was ultimately proven right only because the case we were dealing with turned out to be nothing more than a simple electronic graffiti artist. Despite being right in that single instance, I am being forced to change my overall position.

In terms of practical application, it means people can no longer blithely allow in traffic to their web servers on ports 80 and 443. Traffic must be examined, either by an intermediate network device or the web server itself to ensure safety. Web applications need to be coded securely, and web servers should in general not be trusted. (Don’t run the process as root, perform system calls in a sandbox, etc.)