App IDS guards databases

Applications and their back-end databases are increasingly exposed to application-level intrusions, such as SQL injection, cross-site scripting attacks and access by unauthorized users - all of which bypass front-end security systems and attack data at its source.

What has emerged in response is a new level of security - application security - that implements traditional network- and operating system-level intrusion-detection system (IDS) concepts at the database (that is, application) level. Unlike generic network or operating system solutions, application IDS provides active, SQL-specific protection and monitoring, protecting thousands of prepackaged and homegrown Web applications. For example, application IDSs monitor and defend critical data against database-specific attacks such as buffer overflows and Web application attacks, and will also audit these events.

Application security differs from network and host security. The applications vary, but the attacker's goal is always the same - to access the database. Since applications use SQL to communicate with the database, a good application IDS parses SQL, providing an objective layer of protection that understands the traffic yet remains independent of the application.

Most application IDSs have three components. The first is a network- or host-based sensor. A network sensor is connected to a switched port analyzer port, which is configured to see all traffic within a database. In contrast, a host sensor resides directly on an application. Sensors gather SQL transactions, interpret them and determine whether the traffic warrants an alert. If an alert is necessary, it is passed to the second structural component, a console server. The server stores events and is the central point for sensor maintenance, such as policy configuration and updates. The third component of an application IDS is a Web browser, through which administrators can modify IDS settings, monitor events in real time and generate reports.

Take a SQL injection attack, in which an attacker tries to bypass the SQL statements defined on a Web server in order to inject his own statements. Assume the expected input is the user name Bob with the password Hardtoguess.

Presented with this input, the database finds a match with a row in the WebUsers table and thus the application authenticates the user. To break in, a SQL injection attack will trick the application into believing the correct credentials were submitted. Let's assume the attack uses the password 'blah' OR 'A'='A' so the attack SQL statement created would be: SELECT * FROM WebUsers WHERE Username='Bob' AND Password='blah' OR 'A'='A'.

Evaluated logically 'A'= 'A' is always TRUE, thus the WHERE clause now matches all rows, and the attacker is validated by the application even without a correct user name or password. The application server accepts the input and is fooled into allowing the attacker past. In doing so, the application server requests data from the database through SQL commands.