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'.

Whitepapers

• The Trend from UNIX to Linux in SAP(r) Data Centers
• Secure Wireless Printing Options
• Getting in Compliance With Government Data Regulations By Leveraging Online Security Technology
• How to Offer the Strongest SSL Encryption
• Maximizing Site Visitor Trust Using Extended Validation SSL
• The Latest Advancements in SSL Technology

View more SOFTWARE whitepapers

Webcasts

• Managing the End User Experience-A Real World Example of Success
• Lowering the Cost of Email Archives
• Google Webcast: Why archive email? Top challenges and best practices
• High Availability for SQL Server 2005 Using Array-Based Replication and Host-Based Mirroring Technologies
• Technical Overview of Exchange Server 2007 with HP Servers and Storage
• Bringing Order and Security to your Mobile Workforce: Corporate Mobility Policy and Device Management On-Demand

View more SOFTWARE webcasts

Special Reports

• WAN Optimization: The Ultimate No Brainer
• Keeping Spam at Bay
• Application Performance Management Executive Guide
• Executive Guide: Building a Service Oriented Architecture
• Executive Guide: Virtualization Reality Check
• IT Buyers Guide To: Collaboration

View more SOFTWARE special reports