09 July 2009 - 3.0 |
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.
![]() |
|
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.
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>
SELECT * FROM users WHERE username = '[username]' AND password ='[password]';
SELECT * FROM users WHERE username = '' or 1=1 ? -' AND password ='[password]';
Step 4: Empty Strings; The Classic updated
Step 4 is a variation of step 3:
<login> <username> ' or ''='</username> <password>' or ''='</password> </login>
SELECT * FROM users WHERE username ='' or ''='' and Password = '' or ''=''
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>
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.