App IDS guards databases
By Aaron Newman
,
Network World
, 10/24/2005
This vendor-written tech primer has been edited by Network World to eliminate product promotion, but readers should note it will likely favor the submitter's approach.
- Share/Email
- Tweet This
- Print
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.
Comment