Web Applications–the Highway to (and from) your Database

According to the Verizon 2016 Data Breach Investigations Report (DBIR), “Web application attacks climbed to the #1 spot for data breaches.” This finding is worth repeating, Web applications are the #1 source for data breaches, with over 40% of the data breaches linked to web application attacks.
While it is human nature to disregard issues in a downward trend, ignore web application protection at your own risk. In the 2015 DBIR, web application attacks took a backseat after being front and center in the 2014 report, but came roaring back in the 2016 report. We would like to take the opportunity to shed light on this disturbing trend and assist in understanding how best to protect your data. The key point is that database security solutions alone cannot protect against data breaches, and to do so you need to additionally deploy a web application firewall (WAF).
Application and data security teams need to join forces to tackle data breaches, web applications are the highway to your valuable data stored in databases. However, the data security team typically deploys database activity monitoring (DAM) without much consideration of a WAF. Yet as we see in Verizon’s most recent report, ignoring web applications puts your database data at significant risk.
A Quick Primer on DAM
When most data security teams think of monitoring and protecting their database, they typically think of DAM.  And true, a database activity monitor tracks activity to the database and can give some level of protection. A good database activity monitor can interface with an LDAP server to know who your users are, scan and classify the data in your databases, identify what users are connecting to the database and which tables and types of data those users are accessing.
However, most legitimate database traffic is generated by applications that use a single login to field requests from a large number of users.
How Web Applications Access Database Data
When a business user logs into a system like SAP, they typically do so through a user-friendly web page which connects to an application. The application functions as an intermediary, and can offer advanced functionality by modifying or processing the data for different purposes (like totaling numbers for a report).
The application connects to the database storing the required information and translates clicks and menus into queries like “select * from users where user_id = browser_user_id.”  The application has full access rights to the database. It queries the database which extracts the data and sends it back to the application. Then the data is provided to the user typically via a web interface (browser).
Applications may retrieve a single record, for example when querying about a particular supplier, or they may be a retrieve a large number of records, such as 10,000 credit card transactions, then perform a function on that data. For example, this may be done to compute a monthly summary of expenses.
Additionally, applications use a function called connection pooling. Connection pooling maintains a number of open connections, then the application uses one of these connections when it needs to connect to the database. This shared connection obfuscates the identities of the users connecting via the connection pool.
What’s the Hidden Risk?
The key item to note here is that the database and data protection products are not aware of the data processing applied by the application before the end user gets to view it.  So they don’t know if it’s one or one thousand users querying data via the application. In ideal circumstances, each web application will have its own login credentials, but even still, that single login is used to extract all data for users logged into the application. Furthermore multiple applications typically use a single database user login (a bad practice), making the problem even worse.
Additionally, databases aren’t aware of how an application is going to display data. So in our example above, a legitimate user might query a database and extract large amounts of data, but the application then processes that information for a specific purpose (to determine the total monthly expenses).
The query’s output may be passed onto other applications that could display every record being queried. For example, not only will the total charge be displayed, but the credit card number, expiry date, cardholder name, and CVN number may all be exposed, resulting in data leakage or theft.
A Significant Attack Vector that Shouldn’t be Ignored
We can see from the above that on any given day web applications process large amounts of data from a large numbers of users, which in itself poses an inherent risk, but there’s more.
Web applications represent a significant attack vector that can be used to extract huge amounts of data by hackers. For example, an SQL injection (SQLi) attack can be used to take advantage of poor or problematic programming to enable a hacker to extract a very large amount of data, even the entire content of a database. And without a WAF, you wouldn’t know there was anything suspicious or problematic taking place.
For all practical purposes, the web application is a multi-lane highway into and out of your database. A direct route that enables huge amounts of traffic, and that can be used by hackers to drive large amount of data out of your organization.
Under these circumstances, a standard DAM solution would see the activity between the application and the database, but it wouldn’t have visibility into what was taking place on the web application. It wouldn’t know who or how many users are extracting data, and wouldn’t block malicious access to the web application or distinguish when a legitimate user is doing something illegitimate.
This lack of granularity enables a single user to leverage a vulnerability in your web application and extract huge amounts of data which then can be sold to the highest bidder, dumped onto the dark web for a profit or leaked to the press.
To fully protect your enterprise and customer data you need not only a DAM solution, but also a WAF. Furthermore, these two solutions should be integrated to provide an end to end picture of what’s happening to your data, resulting in a more secure security posture.
In Summary
Web applications represent a serious risk to your organization’s data, and DAM solutions by themselves don’t have the ability to determine when a legitimate user is doing something illegitimate, don’t have full visibility into end-to-end transactions, nor the capability to block dangerous attacks like SQLi. Subsequently, without the ability to monitor traffic accessing your web application, malicious activity can take advantage of gaps in your protection to extract large amounts of data and put your organization at risk.
Using a DAM without a WAF is like guarding the employee entrance at your company headquarters, while leaving the loading dock door wide open. For more infomration on the Imperva WAF, see Protecting Your Critical Web Applications and Data.