Anyone who has worked as a security auditor, sometimes called a “white hat,” knows that most organizations have gotten pretty good at configuring their firewalls and patching their externally facing servers.
Doing a scan with tools such as Nessus will reveal very few exploitable vulnerabilities. But, if the target organization has a significant web presence, invariably there are weaknesses in the way they deploy Web applications.
For instance, have you ever seen the following inside the URL window of your web browser: Note the SID (session ID). Sometimes this is even a UID, or User ID. Many times, all you have to do is decrement the session or user ID by one and you immediately hijack the session of the person who logged in just before you.
It is rare but still possible to find for-pay subscription sites that expose session IDs in this way. Once a session is hijacked a hacker can navigate to the “profile” section of the website and permanently take over a victim’s subscription by changing the login password.
Although there are usually good programming practices that can avoid most web application snafus, some of the harder bugs to counter target business processes.
For example, ChoicePoint was seriously whacked by a gang of identity thieves because they assumed that only good guys would sign up for their service. ChoicePoint made it very easy for fictional organizations to get credentials and start to pilfer their online databases of credit histories.
A similar vulnerability is also exposed with high-cost legal and research data services that provide short-term subscription options—a “try before you buy” ploy. So a hacker pays the $250 for a month’s access and executes an automatic program to download the entire contents of the site’s data base.
Easy Remedies
Both of these scenarios are easily addressed, but changes to the business process are required.
In order to counter all of these types of attacks a web application firewall is required. These are network devices that reside in front of the web servers. They counter attacks against underlying vulnerabilities in the web server, OS, and web applications. They also provide a control point were additional rules can be enforced such as password and session management, or denying requests beyond a certain threshold of volume or frequency.
I have seen three designs of web application (WA) firewalls. The first generation WA firewalls would scan your web apps for vulnerabilities and generate a set of rules that would protect those vulnerabilities. Kavodo and Sanctum are good examples of this first generation. Sanctum branched out into offering its web vulnerability scanner as a separate product.
The next generation of WA firewalls represented by NetContinuum and Teros maintains a very sophisticated “state” for every web session. By keeping track of all outgoing information it is possible for these firewalls to enforce a policy that essentially “denies everything except that which has implicitly been allowed”.
In other words, a visitor to a website is only allowed to go to internal links that have been sent out during that session. No more changing SID’s or typing in unreferenced addresses like www.somewebsite.com/test. This technology can also be used to block leakage of information such as social security numbers or account information.
The third generation of WA firewall uses a scanner as well, but scans and maps a website to create a “deny everything except that which is explicitly allowed” rule set. This is the technology that Magnifire developed and is now sold by F5 Networks.
One common prognostication is that WA firewalls will eventually become a component of traditional firewalls. However, as Web-based business processes become more and more decoupled from the rest of an organization’s Internet connectivity there is an argument to be made that protecting web applications requires separate infrastructure.
As a first step, every organization should take a fresh look at the web applications they have exposed to the world over the last several years of rapid development and deployment.
Re-evaluate the risk in light of new threats posed by gangs of hackers that are actively hunting for ways to harvest identities by exploiting weak business processes such as in the ChoicePoint case.
Beef up network protections around those web applications. Check your network firewall’s ability to block “syn flood” and “get flood attacks;” two popular ways to force a website to go down. Use a web application scanner or service to check how well your applications have been deployed. And, finally, evaluate the benefits of deploying web application firewalls.
Richard Stiennon is vice president of Threat Research at Webroot Software. He is a holder of Gartner’s Thought Leadership award for 2003 and was named “One of the 50 Most Powerful People in Networking” by Network World Magazine.
You can read his blog at www.threatchaos.com.