© The Author(s), under exclusive license to APress Media, LLC, part of Springer Nature 2021
A. SheikhCertified Ethical Hacker (CEH) Preparation Guidehttps://doi.org/10.1007/978-1-4842-7258-9_11

11. SQL Injections

Ahmed Sheikh1  
(1)
Miami, FL, USA
 

Structured Query Language (SQL) is a language that allows interaction with a database server. Programmers use SQL commands to perform operations using the databases. SQL injection takes advantage of non-validated input vulnerabilities. Attackers inject SQL commands through a web application that executes on the backend database.

Any web application that accepts user input for taking action or performing a query may be vulnerable to a SQL injection. In this chapter, you will learn about SQL injections, how they work, and what administrators can do to prevent them.

By the end of this chapter, you will be able to
  1. 1.

    Examine SQL injection attacks.

     
  2. 2.

    Identify defensive strategies against SQL injection attacks.

     

Web Application Components

The web server receives the request and verifies the user’s access rights to make the request. The web server validates the request and queries the database server to fulfill the request. The database server receives the request and processes the query. A web page is built based on the query response and is returned to the browser. See Figure 11-1.
../images/505537_1_En_11_Chapter/505537_1_En_11_Fig1_HTML.jpg
Figure 11-1

Web application components

SQL Injection Classifications

Once a SQL injection vulnerability is found, the only limitation on an attacker is their skill with SQL queries. Attackers can submit one SQL statement after another until the backend is mapped, altered, viewed, and controlled. See Figure 11-2 for SQL injection classifications.
../images/505537_1_En_11_Chapter/505537_1_En_11_Fig2_HTML.jpg
Figure 11-2

SQL injection classifications

Web Front End to SQL Server

If a web application is linked to a SQL backend database, when the user enters information (such as a username and password), these values are placed in a SQL statement. See Figure 11-3.
../images/505537_1_En_11_Chapter/505537_1_En_11_Fig3_HTML.jpg
Figure 11-3

A login page

After the web user submits the request, the input is placed into a SQL statement (Figure 11-4).
../images/505537_1_En_11_Chapter/505537_1_En_11_Fig4_HTML.jpg
Figure 11-4

A web front end for a SQL Server

Manipulating the Input Fields

The SQL injection works by manipulating the values placed in the statement. For instance, in this case the attacker inserts the value JESSE’ OR 1=1-- for the username that appears in Figure 11-5.
../images/505537_1_En_11_Chapter/505537_1_En_11_Fig5_HTML.jpg
Figure 11-5

Input field manipulation

Failed SQL Injection Attempt

The SQL password field will not be evaluated if the username field ends with double dashes. The reason that this attempt at SQL injection was unsuccessful is that the input was validated by the browser’s JavaScript. See Figure 11-6.
../images/505537_1_En_11_Chapter/505537_1_En_11_Fig6_HTML.jpg
Figure 11-6

Failed SQL injection attempt

Using Client-Side Validation

A web application can use JavaScript to check for input validation. This is a form of client-side validation. You can disable JavaScript within the browser. See Figure 11-7.
../images/505537_1_En_11_Chapter/505537_1_En_11_Fig7_HTML.jpg
Figure 11-7

Client-side validation

Successful Login

Attempt the SQL injection again. The likely reason that the name aanderson is displayed is due to the fact they are the first user in the column. Once 1=1 is elevated as true, login is successful. See Figure 11-8.
../images/505537_1_En_11_Chapter/505537_1_En_11_Fig8_HTML.jpg
Figure 11-8

Login successful

Using a Stored Procedure

To view all the names and passwords in the database, just use a stored procedure. The stored procedure is known as sp_makewebtask. This stored procedure, which is provided only in Microsoft SQL Server, generates HTML output. Use the code shown as the username. Although a failed login name response is received, this does not mean that the SQL statement did not execute. See Figure 11-9.
../images/505537_1_En_11_Chapter/505537_1_En_11_Fig9_HTML.jpg
Figure 11-9

Stored procedure

Injection Results

The whole database that includes all usernames and passwords is shown in Figure 11-10. This could have been a credit card or social security number database.
../images/505537_1_En_11_Chapter/505537_1_En_11_Fig10_HTML.jpg
Figure 11-10

Injection results

Injecting Username

Inject a username and password into the existing database. This allows you to log in and access the resources in the database. Or, in a database, you can create an account that will provide physical or network access. After logging into the SQL server you can verify that your credentials are added, as shown in Figure 11-11.
../images/505537_1_En_11_Chapter/505537_1_En_11_Fig11_HTML.jpg
Figure 11-11

Injecting a username

Countermeasures

Regular expressions play an important role in overcoming a SQL injection. The last four countermeasures apply specifically to blind SQL injection. This occurs when an application accepts data from a client and executes SQL queries without first validating the input. To avoid this, do the following:
  1. 1.

    Input a validation check for every user input.

     
  2. 2.

    Use Salt to store the hash of passwords instead of storing them in plain text.

     
  3. 3.

    Check for SQL-specific metacharacters like the single quote (‘) or double dash (--).

     
  4. 4.

    Client-supplied data should never be allowed to modify the syntax of SQL statements.

     
  5. 5.

    Isolate the web application from SQL.

     
  6. 6.

    All SQL statements required by an application should be in stored procedures on the database server.

     
  7. 7.

    An application should execute stored procedures using a safe interface.

     

Preventing SQL Injection Attacks

By following several recommendations, SQL injection attacks can be prevented. Prevention is the responsibility of both developers and database administrators.
  • Convert all single quotes to double quotes using a simple replace function.

  • Minimize privileges.

  • Implement consistent coding standards.

  • Firewall the SQL server.

  • Never trust the input of users.

  • Never use dynamic SQL.

  • Exceptions should provide only minimal information.

Summary

In this chapter, you learned about SQL injection attacks, how they work, and the types of tactics that can be applied in order to prevent them. You reviewed specific countermeasures that can aide in preventing SQL attacks and thus can help administrators maintain security.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.144.212.145