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:
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:
If the content of the element is not checked, the statement should look as follows:
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.