SQL Injection: You Can’t Protect Against What You Can’t See
A couple of weeks back, we took a snapshot from our crowd sourced threat intelligence system, Community Defense, looking at the velocity of application attacks. For the sake of this blog, I will focus on findings from 5/8/2014. We found that there were 319,915 SQL Injection incidents that happened on that day from all over the world.
Web Server Defense In Depth Architecture
To better understand the meaning of this number, we will break down the flow of application traffic for a web application. Keep in mind, while some of these may be part of a cloud service, the following diagram shows the basic components regardless of where they are physically positioned.
When a user requests a web page or data from the website, there are several common components on the traffic path that are able to decrypt and inspect the traffic and make a security decision in order to protect the web application and the data that resides in it from being hacked.
What does 320K SQL Injections mean?
After we have established the security minded flow of traffic to a web application, let’s look at it in an attack scenario. Each component along the way – NGFW, IPS, WAF (and maybe some other layers like caching in between) – has the ability to block an event when it detects an attack.
The Web Application Firewall (WAF) component is the component where we get our data from.
This means, that in order for us to see SQL Injection attacks, they have to pass through NGFWs and IPSs along the way which do not see that traffic as malicious, simply because that’s not what they are designed to do. These SQL Injection attacks were only blocked when they reached the WAF technology.
This breaks an unfortunately common misconception that NGFW and IPS technologies are able to properly deal with web application attacks such as SQL Injection and others.
Learn more about this topic:
Authors & Topics: