SQL Injection

• The very first thing to point out is that this section is entitled “SQL Injection,” but injection attacks are not limited to applications running against a particular database server. MySQL, SQL Server, Oracle, etc, are all potentially susceptible.
• SQL injection vulnerabilities are common in web application that access an SQL back end. The vulnerability has its roots in the use of client-supplied data in SQL queries.
• Successful SQL injection attacks can result in the attacker possibly being to:
  • Run commands as the SQL Server user on the database server, using the xp_cmdshell extended stored procedure.
  • Read registry keys, potentially including the SAM (if SQL Server is running as the local system account) using the xp_regread extended stored procedure.
  • Run other extended stored procedures.
  • Run queries on linked servers.
  • Create new custom extended stored procedures to run explicit code with the SQL sever process.
  • Use the “bulk insert” statement to read any file on the server.
  • Use bcp to create arbitrary text files on the sever.
  • Create OLE Automation applications that can do everything that an ASP script can
  • The goal of an SQL injection attack is to attempt to manipulate queries or information sent to an SQL back end to gain control of the SQL server.
  • This control can mean the ability to modify queries to get unauthorized information, but it can also go as far as modifying data on the server, invoking stored procedures, or even shutting down the SQL server, depending on the skill of the attacker and the level of control that can be gained.
  • This is usually done by bypassing or tricking whatever safeguards are in place to validate or scrub data before it's sent to the back-end SQL server.

• SELECT FieldList FROM Table WHERE field= 'user-clause';
• Now, if the clause supplied by the attacker is “myclause'” (notice the trailing single quote), the SQL query now looks like this:

SELECT FieldList FROM Table WHERE field = `myclause' ;

• Typically, this will result in a syntax error because the trailing single quote will confuse the SQL server.
• Now, what if we try to change the nature of the WHERE clause by injecting a clause designed to always be true, such as “anything' or 'z'=z”. Our query then becomes: SELECT FieldList FROM Table WHERE field = 'anything' or 'z'=z';
• This version, because the conditions will always be met, will return all rows in the table.

* The attacker can continue on from there with some guesses at table names and even get to where, instead of just copying or stealing the information in the database, the attacker is writing data to the database' if that is not forbidden.

• Look for a Possible Vulnerability
  • The start of an SQL injection attack generally begins with the attacker looking for vulnerability in a site. This could be just about anything that accepts input: a search string, a form, ASP, JSP, CGI, or PHP pages.
  • Anything the attacker can see in the source is as vulnerable as what is openly displayed; perhaps more so, because sometimes there is less security on those fields that are hidden.
  • Once a possible vulnerability is found, the attack can begin in earnest.
• Test the Vulnerability
  • To test the vulnerability, the attacker often starts with what is the most common vulnerability: the single quote.
  • In SQL, a single quote is the string literal delimiter. If user input is submitted directly to the SQL back end without sufficient validation or input “scrubbing,” it's incredibly easy to gain control of the SQL server.
  • If the attacker is working with a hidden field in the source, it's only a bit more complicated in that the source needs to be downloaded from the site, saved, the URL and the hidden field modified, and then the source executed.
  • If the user input is not being sufficiently validated and scrubbed, the additional information after the apostrophe will be treated as a part of the query string submitted to the SQL server and will be executed.
  • Now the attacker takes a look at what is returned.
• All Errors Are Not Created Equal
  • Unfortunately, error pages can reveal a lot of information about exactly what is happening behind the scenes. If you know what to look for, they're a great tool to use when trying to diagnose and refine attack attempts.
  • The first thing to do is see just what error page is returned. If it’s an ODBC error page, the attacker knows right away that this is a true vulnerability because the error was generated from the SQL, which means the single quote inserted in the prior step was successful in passing from the front end to the SQL back end.
• If the attacker gets a different error, he will then look carefully through the source of the error page for any references to 'SQL Server,“ “ODBC,” or “syntax.” Sometimes the details of the error are hidden in the headers or in comments that aren't visible except in the source.
  • If an error page is returned that includes links, the attacker will search the links to see of they contain more details of the error.
  • If a 302 Page Redirect is called, the attacker will try to capture the page it is redirected from; this may have more error details in it that can't be easily read before the redirect occurs.
  • If a 500 Error Page is returned, the attacker knows that the injection may have been successful as this is the default error page for most Web servers. Though the attacker may not be able to determine much from this page, it will spur him on to greater attempts to exploit a possible weakness.
• The Hunt Continues
  • The attacker will continue to try other options as to how to bypass the site's validation and scrubbing routines. In each case, the server's responses will be carefully examined. These other options include:
    • Using the single quote in different places in the string to try to take advantage of any ordered validation routines (for example, an e-mail field may be validated to require an @ and a period, and if the attacker entered “joe@mysite.com,” it would fail that validation. However, it's never actually tested for a single quote, so “joe@mysite.com- would succeed and expose the vulnerability).
    • Using the single quote at the end of a maximum length string. If the site is escaping single quotes, the attempt to escape a single quote when it is already at maximum length for the string may lead to the string's being truncated right back to the single quote and the vulnerability exposed.
    • Using two dashes. Two dashes in an SQL server indicate a single line comment and may be passed to the back-end server, causing the server to ignore the rest of the line.
    • Using a semicolon. This is a character that indicates to the SQL server that a new command follows. If this is passed through to the back end, the attacker may be able to concatenate another command and essentially piggyback on the prior query.
    • Using all of these techniques in not just sting fields but in fields that appear to he set for other data types. For example, a back end SQL server may implicitly translate an integer into a varchar. Or a format may only be enforced by the Web code and never checked after that UI check.
    • Using a # character. This is sometimes used as a date/time delimiter.
    • Using char equivalents to the suspicious characters (for example. char(0x63)).

• Arguably, the most serious and widely publicized SQL injection attack is the one that was carried out on CardSystems in September 2004, where 263.000 credit card numbers were stolen and 40 million more numbers were exposed.
• Although the exact details of the attack are not available the attack is acknowledged to he the product of the exploit of an SQL injection vulnerability on the Web application that allows the customers to access account information.
• The attackers injected a script that would run every four days to extract records, zip them, and then export them to an FIT site.
• It is worth pointing out that the data that was exported had been kept in an unencrypted form and in violation of regulatory rules for supposed -research purposes.”

• Every parameter of every call must be tested separately to have a good picture of the Web service's/site's SQL injection vulnerabilities. the following Table shows the list of characters I recommend testing with.

• For black-box testing, you need to use a browser and perform parameter tampering in any query or parameter you can locate on the site.
• The basic process is to replace the argument in every parameter on every script on the server with a test argument, one parameter at a time. Leave all the other parameters with valid data intact. Submit this parameter (or set of parameters) to the server and then examine the returned page for the signs of possible vulnerabilities listed in earlier section titled “ Anatomy of the Exploit”

• Determine if the Web site is performing any type of input validation.
• String tend to be more susceptible to parameter injection than other data types.
• One parameter at a time, replaces the argument of each parameter on each API, with each of the listed single-quote test scenario, and submits It. Then, examine the entire response from the server to see if you received an error and whether you can tell if it's an SQL error.
• One parameter at a time, replaces the argument of each parameter on each API, with each of the listed single-quote test scenario, and submits It. Then, examine the entire response from the server to see if you received an error and whether you can tell if it's an SQL error.

• https://www.owasp.org/index.php/SQL_injection