From: “Tips and Tricks: 10 Tests of a Web Service Login you should always do” by eviware

Tip 1) SQL Injection Tests

Date: July 9, 2009

SQL Injection the art of sending in SQL Statements in forms and data to the target system to be executed by the back end database. The result we’re looking for is will either for the system to allow you access or to display information that will move us closer to getting access. In the infancy of The Web, this used to be a large problem, but is largely handled today at least on a basic level. Unfortunately with in the realm of SOA development we’ve taken a step back and the database is exposed surprisingly often.

What we’ll be looking at here is using several small steps to see if the base security is fine in regards to Data Injection.

Step 1: Random SQL

We’ll start of with a simple test, we insert a SQL Statement in any field and monitor the return response.

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

This might seem way to simple, but look at this message:

Microsoft OLE DB Provider for ODBC Drivers error '80040e07' [Microsoft][ODBC SQL

We have already gained information about what what the database is, we can probably guess what the platform used to create the Web Services are and can use that information in further attacks.

Step 2: Wildcards

Next we enter a SQL WildCard

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

Both Step 1 and 2 are similar and should really not result in any errors, but although it shouldn't doesn't mean it doesn't and it's wise to try it: you might get an SQL error back. Step 3 is more complicated

Step 3: The Classic

This test is the most common SQl injection test using the following:

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

"Why?", you might ask. Well, if the SQL used to check the login is:
SELECT * FROM users WHERE username = '[username]' AND password ='[password]';
This results in the following if the contents of the elements aren’t checked:
SELECT * FROM users WHERE username = '' or 1=1 - -' AND password ='[password]'
Which might actually cause the SQL Server to exclude everything after ?–” (since it’s TransactionSQL) and just return the first user in the database. With some (bad)luck, we might even be able to log in.

Step 4: Empty Strings; The Classic updated

Step 4 is a variation of step 3:

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

Which results in the following SQL:
SELECT * FROM users WHERE username ='' or ''='' and Password = '' or ''=''
Returning all records in the database and possibly logging us in.

Step 5: Type Conversions
We can also try exposing the database by trying sending in type conversions that surely will fail in the database.

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

The goal here is -as with the above- to make the database give us any info by sending an error message that exposes the database. As we said earlier, anything that exposes what the database or the application platform is using is helpful, it can help us look up specific vulnerabilities for that environment.

Database hacking is a chapter in itself and you should be learning it from the pro’s themselves: The Database Hacker’s Handbook: Defending Database Servers

This tip was quite long, the next will be considerably shorter.

From: “Tips and Tricks: 10 Tests of a Web Service Login you should always do” by eviware see for the other 9 tests:

Quality Time is a Futurice awareness campaign to improve knowledge related to testing. Follow Quality Time at http://blog.futurice.com or on any Futurice rest room.