[REVS] SQL Injection Signatures Evasion
From: SecuriTeam (support_at_securiteam.com)
Date: 04/22/04
- Previous message: SecuriTeam: "[UNIX] Cherokee Format String Vulnerability"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
To: list@securiteam.com Date: 22 Apr 2004 18:47:21 +0200
The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion
The SecuriTeam alerts list - Free, Accurate, Independent.
Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html
- - - - - - - - -
SQL Injection Signatures Evasion
------------------------------------------------------------------------
SUMMARY
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.
DETAILS
Abstract:
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.
ADDITIONAL INFORMATION
The paper can be found at: <http://www.imperva.com/download.asp?id=2> PDF
version or
<http://www.imperva.com/application_defense_center/white_papers/sql_injection_signatures_evasion.html> HTML version
The information has been provided by <mailto:adc@imperva.com> Imperva
Application Defense Center.
========================================
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com
====================
====================
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.
- Previous message: SecuriTeam: "[UNIX] Cherokee Format String Vulnerability"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
