Businesses have two primary options when building a defense against SQL attacks: prevention and detection. Code can be developed in a way that defeats SQL injection, and developers should take steps when writing code to avoid SQL injection flaws. At the same time, companies use a wide range of 3rd party applications. Avoiding SQL injection on all fronts is virtually impossible, thus businesses need a robust strategy for identifying and guarding against attackers.
The Open Source Web Applications Security Project provides a helpful SQL Injection Prevention Cheat Sheet. They offer key key defenses developers may employ when preparing code.
1. Use Prepared Statement (parameterized queries) instead of dynamic queries. Prepared statements require developer to define all SQL code initially, and then pass in each parameter to the query later. By developing code based on prepared statements, the database can distinguish between code and data.
2. Use Stored Procedures. Similar to prepared statements, stored procdeures require defining SQL code at the outset. While prepared statements store all the SQL code stays within the application, stored procedures are defined and stored in the database and called from the application. Stored procedures offer pluses and minuses, so you company must decide which model is best for you.
3. Escape User Supplied Input. For companies who are hesitant to rewrite dynamic queries because it might adversely impact your application performance, you can choose to escape all user supplied input before inserting it into a query. This is not as safe as the first two options but may be the best option if you are unable to rewrite applications.
Most companies used multiple 3rd applications, making it is almost impossible to avoid all SQL injection attacks. Thus, it is important to use detection and evasion strategies to avoid attack. Imperva’s “Hacker Intelligence Initiative, Monthly Trend Report #4” offers three helpful techniques for defeating SQL injection attacks in real time.
1. Detect SQL injection attack. Detecting SQLi must normalize the inspected input to avoid evasion attempts. The Open Web Application Security Project provide a helpful kit for testing for SQL injection.
2. Identify access patterns of automated tools. Since SQL injection attacks are primarily automated attacks, you can set tools in place that monitor and log attempts by automatic clients.
3. Create and deploy a blacklist of hosts that initiated SQLi attacks. As you log and identify attacks, you can create a blacklist that identifies and stops attacks at the outset. You might also use tools that include regular updating of attack list.