SQL Injection Tests

Applies to ReadyAPI 3.9, last modified on July 30, 2021

The SQL injection is one of the most commonly used techniques for accessing and manipulating databases. Attackers use it to execute queries against a database to get its contents and violate the data by injecting SQL commands into an SQL statement. Unfortunately, such attacks happen very often. However, if you find vulnerable points in your application software, you will find ways to protect it.

Below is the description of several steps, which will help you find out whether the base security concerning data injection is strong enough.

1. Random SQL

Start with a simple test. Insert an SQL statement in any field and check the response.

<login>
    <username><User>SELECT * from userstable</username>
    <password>*</password>
</login>

Although this might seem simple, consider the following message:

Microsoft OLE DB Provider for ODBC Drivers error '80040e07' [Microsoft] [ODBC SQL Server Driver][SQL Server]Syntax error Invalid string or buffer length.

This message reveals information about the database you have. Also, it allows to identify the platform that has been used to create the web service. Keep in mind that malicious users use this information in further attacks.

2. Wildcards

In this step, enter an SQL Wildcard.

<login>
    <username>*</username>
    <password>*</password>
</login>

Two previous steps are similar and unlikely to result in errors. However, you should eliminate the possibility of using SQL wildcards by potential attackers.

3. Classic SQL

This test is the most common SQL injection test:

<login>
    <username> ' or 1=1--</username>
    <password>' or 1=1--</password>
</login>

The following SQL statement allows checking the login:

SELECT * FROM users WHERE username = '[username]' AND password ='[password]';

If the content of the element is not checked, the statement should look as follows:

SELECT * FROM users WHERE username = or 1=1 - -' AND password ='[password]';

This statement causes the SQL server to exclude everything after the - sign and return the first user in the database. With this statement, a potential attacker may be able to log in. Since the first user is often an administrator, the necessity of protection should be obvious.

4. Empty strings

This step is a variation of step 3.

<login>
    <username> ' or ''='</username>
    <password>' or ''='</password>
</login>

This request results in the following SQL and returns all records in the database and provides the possibility of gaining access to the service:

SELECT * FROM users WHERE username ='' or ''='' and Password = '' or ''=''

5. Type conversions

Try to expose the database by sending type conversions which will fail in the database.

<login>
    <username>CAST('smartbear' AS SIGNED INTEGER)</username>
    <password>yesitdoes!</password>
</login>

This SQL statement is aimed at exposing the database by sending an error message. As mentioned above, any information about the database or the application platform gives additional information on specific vulnerabilities for that environment.

For more information on database protection, see The Database Hacker's Handbook: Defending Database Servers.

See Also

Sample Login Tests

Highlight search results