What does XSS after SQLi look like? I think I may have XSS and SQL Injection...
How will I know?
SQL injection vulnerabilities arise when user-controllable data is incorporated into database SQL queries in an unsafe manner. An attacker can supply crafted input to break out of the data context in which their input appears and interfere with the structure of the surrounding query.
Various attacks can be delivered via SQL injection, including reading or modifying critical application data, interfering with application logic, escalating privileges within the database and executing operating system commands.
SQL Injection is identified when: The software constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component.
SQL Injection | Warning Signs | I known SQL Injection when I see it.....
Server Error in '/' Application.
The expression contains an invalid string constant: '.
This is SQL Injection:
This is Cross Site Scripting:
Remediation background
The most effective way to prevent SQL injection attacks is to use parameterised queries (also known as prepared statements) for all database access. This method uses two steps to incorporate potentially tainted data into SQL queries: first, the application specifies the structure of the query, leaving placeholders for each item of user input; second, the application specifies the contents of each placeholder. Because the structure of the query has already defined in the first step, it is not possible for malformed data in the second step to interfere with the query structure. You should review the documentation for your database and application platform to determine the appropriate APIs which you can use to perform parameterised queries. It is strongly recommended that you parameterise every variable data item that is incorporated into database queries, even if it is not obviously tainted, to prevent oversights occurring and avoid vulnerabilities being introduced by changes elsewhere within the code base of the application.
You should be aware that some commonly employed and recommended mitigations for SQL injection vulnerabilities are not always effective:
One common defense is to double up any single quotation marks appearing within user input before incorporating that input into a SQL query. This defence is designed to prevent malformed data from terminating the string in which it is inserted. However, if the data being incorporated into queries is numeric, then the defence may fail, because numeric data may not be encapsulated within quotes, in which case only a space is required to break out of the data context and interfere with the query. Further, in second-order SQL injection attacks, data that has been safely escaped when initially inserted into the database is subsequently read from the database and then passed back to it again. Quotation marks that have been doubled up initially will return to their original form when the data is reused, allowing the defence to be bypassed.
Another often cited defence is to use stored procedures for database access. While stored procedures can provide security benefits, they are not guaranteed to prevent SQL injection attacks. The same kinds of vulnerabilities that arise within standard dynamic SQL queries can arise if any SQL is dynamically constructed within stored procedures. Further, even if the procedure is sound, SQL injection can arise if the procedure is invoked in an unsafe manner using user-controllable data.
SQL Injection Impact
Depending on the backend database, database connection settings and the operating system, an attacker can mount one or more of the following type of attacks successfully:
Reading, Updating and Deleting arbitrary data from the database
Executing commands on the underlying operating system
Reading, Updating and Deleting arbitrary tables from the database
Suggested Actions:
See the Remediation Solution Below.
The application should handle errors gracefully and prevent SQL error messages from being returned in responses.
If you are not using a database access layer (DAL) within the architecture consider its benefits and implement if appropriate. As a minimum the use of s DAL will help centralize the issue and its resolution. You can also use an ORM (object relational mapping). Most ORM systems use parameterized queries and this can solve many if not all SQL Injection based problems.
Locate all of the dynamically generated SQL queries and convert them to parameterised queries. (If you decide to use a DAL/ORM, change all legacy code to use these new libraries)
Monitor and review weblogs and application logs in order to uncover active or previous exploitation attempts.
SQL Injection Remediation
A very robust method for mitigating the threat of SQL Injection based vulnerabilities is to use parameterized queries (prepared statements). Almost all modern languages provide built in libraries for this. Wherever possible do not create dynamic SQL queries or SQL queries with string concatenation.
Required Skills for Successful Exploitation
There are numerous freely available tools to test for SQL Injection vulnerabilities. This is a complex area with many dependencies, however it should be noted that the numerous resources available in this area have raised both attacker awareness of the issues and their ability to discover and leverage them. SQL Injection is one of the most common web application vulnerabilities.
External References
CAPEC-66
CWE-89
CWE Top 25
SANS Top 25
OWASP Top 10
SQL Injection Cheatsheet - Ferruh Mavituna
Remedy References
MSDN - Protect From SQL Injection in ASP.NET
How To: Protect From SQL Injection in ASP.NET
SQL Server 2008 R2 - SQL Injection Information
darkblue.com, XSS, SQLi, LFI, Path Traversal CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Cross-site scripting (XSS) vulnerabilities occur when:
1. Untrusted data enters a web application, typically from a web request.
2. The web application dynamically generates a web page that contains this untrusted data.
3. During page generation, the application does not prevent the data from containing content that is executable by a web browser, such as JavaScript, HTML tags, HTML attributes, mouse events, Flash, ActiveX, etc.
4. A victim visits the generated web page through a web browser, which contains malicious script that was injected using the untrusted data.
5. Since the script comes from a web page that was sent by the web server, the victim's web browser executes the malicious script in the context of the web server's domain.
6. This effectively violates the intention of the web browser's same-origin policy, which states that scripts in one domain should not be able to access resources or run code in a different domain.
CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Description Summary
The software constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component.
Extended Description
Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data. This can be used to alter query logic to bypass security checks, or to insert additional statements that modify the back-end database, possibly including execution of system commands.
SQL injection has become a common issue with database-driven web sites. The flaw is easily detected, and easily exploited, and as such, any site or software package with even a minimal user base is likely to be subject to an attempted attack of this kind. This flaw depends on the fact that SQL makes no real distinction between the control and data planes.
CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Description Summary
The software uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the software does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory.
Extended Description
Many file operations are intended to take place within a restricted directory. By using special elements such as ".." and "/" separators, attackers can escape outside of the restricted location to access files or directories that are elsewhere on the system. One of the most common special elements is the "../" sequence, which in most modern operating systems is interpreted as the parent directory of the current location. This is referred to as relative path traversal. Path traversal also covers the use of absolute pathnames such as "/usr/local/bin", which may also be useful in accessing unexpected files. This is referred to as absolute path traversal.
In many programming languages, the injection of a null byte (the 0 or NUL) may allow an attacker to truncate a generated filename to widen the scope of attack. For example, the software may add ".txt" to any pathname, thus limiting the attacker to text files, but a null injection may effectively remove this restriction.
