1. Authentication
- Brute Force
- Insufficient Authentication
- Weak Password Recovery Validation
2. Authorization
- Credential/Session Prediction
- Insufficient Authorization
- Insufficient Session Expiration
- Session Fixation
3. Client-side Attacks
- Content Spoofing
- Cross-site Scripting
4. Command Execution
- Buffer Overflow
- Format String Attack
- LDAP Injection
- OS Commanding
- SQL Injection
- SSI Injection
- XPath Injection
5. Information Disclosure
- Directory Indexing
- Information Leakage
- Path Traversal
- Predictable Resource Location
6. Logical Attacks
- Abuse of Functionality
- Denial of Service
- Insufficient Anti-automation
- Insufficient Process Validation
|
 |
SQL Injection
SQL Injection is an attack technique used to exploit web sites that
construct SQL statements from user-supplied input.
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 is both an ANSI and an ISO standard. However,
many database products supporting SQL do so with proprietary
extensions to the standard language. Web applications may use
user-supplied input to create custom SQL statements for dynamic
web page requests.
When a web application fails to properly sanitize user-supplied input,
it is possible for an attacker to alter the construction of backend SQL
statements. When an attacker is able to modify a SQL statement, the
process will run with the same permissions as the component that
executed the command. (e.g. Database server, Web application
server, Web server, etc.). The impact of this attack can allow
attackers to gain total control of the database or even execute
commands on the system.
The same advanced exploitation techniques available in LDAP
Injection can also be similarly applied to SQL Injection.
Example
A web based authentication form might have code that looks like the
following:
<![CDATA[
SQLQuery = "SELECT Username FROM Users WHERE
Username = '" & strUsername & "' AND Password = '"
& strPassword & "'" strAuthCheck =
GetQueryResult(SQLQuery)
]]>
In this code, the developer is taking the user-input from the form and
embedding it directly into an SQL query.
<![CDATA[
Suppose an attacker submits a login and password that looks like the
following:
Login: ' OR ''='
Password: ' OR ''='
This will cause the resulting SQL query to become:
SELECT Username FROM Users WHERE Username = '' OR
''='' AND Password = '' OR ''=''
]]>
Instead of comparing the user-supplied data with entries in the Users
table, the query compares '' (empty string) to '' (empty string). This
will return a True result and the attacker will then be logged in as the
first user in the Users table.
There are two commonly known methods of SQL injection: Normal
SQL Injection and Blind SQL Injection. The first is vanilla SQL
Injection 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.
Normal SQL Injection
By appending a union select statement to the parameter, the
attacker can test to see if he can gain access to the database:
http://example/article.asp?ID=2+union+all+select+name+from+sysobjects
The SQL server then might return an error similar to this:
<![CDATA[
Microsoft OLE DB Provider for ODBC Drivers error '80040e14'
[Microsoft][ODBC SQL Server Driver][SQL Server]All
queries in an SQL statement containing a UNION
operator must have an equal number of expressions
in their target lists.
]]>
This tells the attacker that he must now guess the correct number of
columns for his SQL statement to work.
Blind SQL Injection
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.
Executing the following request to a web site:
http://example/article.asp?ID=2+and+1=1
should return the same web page as:
http://example/article.asp?ID=2
because the SQL statement 'and 1=1' is always true.
Executing the following request to a web site:
http://example/article.asp?ID=2+and+1=0
would then cause the web site to return a friendly error or no page at
all. This is because the SQL statement "and 1=0" is always false.
Once the attacker discovers that a site is susceptible to Blind SQL
Injection, he can exploit this vulnerability more easily, in some cases,
than by using normal SQL Injection.
References
"SQL Injection: Are your Web Applications Vulnerable" - SPI Dynamics
http://www.spidynamics.com/support/whitepapers/WhitepaperSQLInjection.pdf
"Blind SQL Injection: Are your Web Applications Vulnerable" - SPI Dynamics
http://www.spidynamics.com/support/whitepapers/Blind_SQLInjection.pdf
"Advanced SQL Injection in SQL Server Applications", Chris Anley - NGSSoftware
http://www.nextgenss.com/papers/advanced_sql_injection.pdf
"More advanced SQL Injection", Chris Anley - NGSSoftware
http://www.nextgenss.com/papers/more_advanced_sql_injection.pdf
"Web Application Disassembly with ODBC Error Messages", David Litchfield - @stake
http://www.nextgenss.com/papers/webappdis.doc
"SQL Injection Walkthrough"
http://www.securiteam.com/securityreviews/5DP0N1P76E.html
"Blind SQL Injection" - Imperva
http://www.imperva.com/application_defense_center/white_papers/blind_sql_server_injection.html
"SQL Injection Signatures Evasion" - Imperva
http://www.imperva.com/application_defense_center/white_papers/
sql_injection_signatures_evasion.html
"Introduction to SQL Injection Attacks for Oracle Developers" - Integrigy
http://www.net-security.org/dl/articles/IntegrigyIntrotoSQLInjectionAttacks.pdf
To receive your Free Application
Vulnerability Assessment for testing of one attack vulnerability of your choice, please submit your payment of $1999.00 for a second SQL Injection attack vulnerability test.
|
