09 July 2009 - 3.0 user guide eclipse intellij netbeans maven download nightly forum bugs blog sf.net eviware


Eviware Logo

Tips and Tricks: 10 Tests of a Web Service Login you should always do

The most common Web Service Request must be The Login, many of the web services we produce are used by an identified user. This leads to us often having a Login TestStep as the the starting point for all our Web Service testing a typical TestCase will look Like this: Log In, Get a Session ID and use that ID in all subsequent requests, and finally use that session id to Log out.

We have a long tradition of doing security Testing of Login functionality for "Regular" Web Pages as are we very conscious about intrusion mechanisms for web pages when we build them, but still both Security and security testing is quite often left out of Web Service Testing.

In this tip and tricks article we will produce some simple tests you can perform when doing your Web Service Testing and that we feel you should always do. Create the tests in your own project, save them as a template and use them in all your tests all the time.

Before we look into the tests, we have to be aware of what we're looking for, so first let's state this; large part of hacking often is not about actually gaining access to a system, but rather exposing system behavior in order to be able to get access to it later. This means large parts of our testing is not about cracking the system, but rather expose behavior in your web service that exposes how it works. Our first Tip is an example of this.

Start soapUI Testing
Get updated!

This Tips and Tricks article will be updated on a daily basis for 10 days. Follow us on Twitter and we'll let you know when the latest update is out.

/ Follow NiclasReimertz on Twitter

Tip 1) SQL Injection Tests

Date: 1) 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 Server Driver][SQL Server]Syntax error Invalid string or buffer length.
				
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.

July 10, 2009. 1) TBA

Look here for the next tip!