‘SQL Injection Signatures Evasion’
‘The document linked below describes several possible ways to evade IDS/IPS detection of SQL Injections. By creating unusual SQL requests it is possible to fool ‘signature’ driven IDS/IPS systems and execute SQL injection attacks even if an IDS/IPS is present.’
In recent years, Web application security has become a focal center for security experts. Application attacks are constantly on the rise, posing new risks for the organization. One of the most dangerous and most common attack techniques is SQL Injection, which usually allows the hacker to obtain full access to the organization’s Database.
With the rise in SQL Injection attacks, security vendors have begun to provide security measures to protect against SQL Injection. The first ones to claim such protection have been the various Web Application Firewall vendors, followed by most IDS/IPS vendors.
Most of this protection, however is Signature based. This is obviously the case with common IDS/IPS vendors, as they come from the network security world, and revolve around signature-based protection. However, most of the Web Application Firewalls base their SQL Injection protection on signatures as well. This is due to the fact that they inspect HTTP traffic only, and is able to look for attack patterns only within HTTP traffic. Moreover, it has lately become a common belief that signatures are indeed sufficient for SQL Injection protection. A recently published article, describing, allegedly, a thorough guide for building SQL Injection signatures, in Snort(tm) -like format, has backed up this belief.
The research done at Imperva’s Application Defense Center shows, however, that providing protection against SQL Injection using signatures only is not enough. This paper demonstrates various techniques that can be used to evade SQL Injection signatures, including advanced techniques that were developed during the research.
The paper further demonstrates why these techniques are actually just the tip of the iceberg of different evasion techniques, due to the richness of the SQL language. Eventually, the conclusion that the research leads to is that providing protection against SQL Injection using only signatures is simply not practical. A reasonably sized signature database will never be complete, while an attempt to create a complete comprehensive signature database, even if theoretically possible, will yield an amount of signatures that is impossible to handle while maintaining a reasonable performance requirement, and is likely to generate too many false positives.’