| VID |
21835 |
| Severity |
40 |
| Port |
80, ... |
| Protocol |
TCP |
| Class |
CGI |
| Detailed Description |
The Web server has a Web page which is vulnerable to a Blind SQL injection vulnerability. Structured Query Language (SQL) is a specialized programming language for sending queries to databases. Most small and industrial-strength database applications can be accessed using SQL statements. SQL Injection is an attack technique used to exploit web sites that construct SQL statements from user-supplied input. The vulnerable Web script page can allow a remote attacker to injection and execute arbitrary SQL statements, due to the application failing to properly sanitize user-supplied input to the affected parameter before using it in SQL queries. The impact of this attack can allow a remote attacker to gain total control of the database or even execute commands on the system.
There are two commonly known methods of SQL injection: Normal SQL Injection and Blind SQL Injection. The first is an SQL Injection method in which the attacker can format his query to match the developer's by using the information contained in the error messages that are returned in the response. In Blind SQL Injection, instead of returning a database error, the server returns a customer-friendly error page informing the user that a mistake has been made. In this instance, SQL Injection is still possible, but not as easy to detect. A common way to detect Blind SQL Injection is to put a false and true statement into the parameter value.
The typical administrative safeguard is simply to prohibit the display of database server error messages. Regrettably, that's not sufficient. If your application does not return error messages, it may still be susceptible to "blind" SQL injection attacks.
* References:
http://www.webappsec.org/projects/threat/classes/sql_injection.shtml
http://www.spidynamics.com/support/whitepapers/WhitepaperSQLInjection.pdf
http://www.spidynamics.com/support/whitepapers/Blind_SQLInjection.pdf
http://www.nextgenss.com/papers/advanced_sql_injection.pdf
http://www.nextgenss.com/papers/more_advanced_sql_injection.pdf
http://www.nextgenss.com/papers/webappdis.doc
http://www.securiteam.com/securityreviews/5DP0N1P76E.html
http://www.imperva.com/application_defense_center/white_papers/blind_sql_server_injection.html
http://www.imperva.com/application_defense_center/white_papers/sql_injection_signatures_evasion.html
http://www.net-security.org/dl/articles/IntegrigyIntrotoSQLInjectionAttacks.pdf
http://www.webcohort.com/Blindfolded_SQL_Injection.pdf
* Platforms Affected:
Any HTTP server Any version
Any operating system Any version |
| Recommendation |
The simplest defence against SQL injection is to never use CGI variables directly in constructing SQL queries. All Client-supplied data needs to be cleansed of any characters or strings that could possibly be used maliciously. This should be done for all applications, not just those that use SQL queries.
- Make it so that you include only the type of characters that you want. Depending upon whether the input is a string or a number different methods can be applied. For instance, for strings you can filter out character like single quote, double quote, slash, back slash and semi colon, and extended character like NULL, carry return, new line, etc. In ASP script, the replace() function can be used as the following:
Replace(Request.Querystring("foobar"), "'", "")
- For numeric value, convert the input to an integer before parsing it into SQL statement. Alternatively it is possible to use IsNumeric() in ASP script and IsNaN() in java script. |
| Related URL |
(CVE) |
| Related URL |
(SecurityFocus) |
| Related URL |
(ISS) |
|
