Advise the administrators of the server/service you will be testing SQL-injection. Advise them that your account will need to be unlocked or for your IP addressed to be un-banned.

1. Random SQL
Type some random SQL for the input value and see if the server returns a message
Result should be no matching rows and no error messages displayed.

2. Wildcards
Type an asterisk (*) as the input value and observe
Result should be no matching rows and no error messages displayed.

3. The Classic
Type the following: ' or 1=1-- as the input value.
Result should be no matching rows and no error messages displayed.

Variations of the Classic
Type the following: ' or ''=' as the input value (note that there is a space in front of the first apostrophe here).
Result should be no matching rows and no error messages displayed.

Type Conversions
Type a conversion: eg. CAST('username' AS SIGNED INTEGER)
Result should be no matching rows and no error messages displayed.

Login and Login
Login as a standard user, and then try to login again without logging out in between.
Result should fail if system is set up properly and advise you you are already logged in.

Login/Logout/Login
Do the following: Login, Logout, Login, Logout, Login, Login
Result should be the same as #6 but we are testing session caching.

Correct ID
Enter a valid value and note the number of rows and what messages are returned.
Result should work as per usual. Eg. ${Test Request: Login#Response#//sam:loginResponse[1]/sessionid[1]}

Expired Session
Login while logged out on the same day or when sessions are suspected for not changing.
Result should show new session and nothing conflicting.

Expired Multiple Sessions
Try logging into the application with two instances of the viewer (eg. same user using 2 browsers looking at same site).
Result should error or deal appropriately with two sessions by the same user.

Lost users
Type a random input value that the system is not expecting or that could not exist in the database.
Result should not give information as to how to validate your input (eg. "The specified username does not exist")

Lockout
If this is a login input, then test how many times you can try incorrect logins without getting locked out. If this is merely a websystem, test how many queries you can input before being locked out.
Result is obviously that you should be locked out of the system or be unable to execute further processes.

Element Duplication
If you can modify the URL, try submitting the same input field twice in one url (specify the parameter twice)
Result should demonstrate that the system can still understand the input and ignore the additional elements.

Element Ommission
Again if you can modify the URL, submit less than the expected input values (so if username&password required just send username). Result should demonstrate that the system will advise on missing elements.

Malformed XML
Need to create a posting form on a server that can communicate with the service you are testing. Create some XML file with invalid XML eg. <login><username>joe</username></login>
Results should have no messages. Any error/validation messages should be suppressed in this case.

The weirdest things happen with the weirdest content
If username is expected to be 25 characters, enter 26. If free-text field, then enter text of about 1000 lines.
Result should have no error messages or possibly a notification of a size limit. Lookout for timeouts and size limits as a giveaway for hackers.

Xpath Injection variants
This is similar to SQL injection but the SQL is parsed and escaped among XML code which is used between many of our applications.
Result should be no messages or errors. Eg. <login>string(//user[username/text()='' or '1' = '1' and password/text()='' or '1' = '1'])</login>

Source: SQL-Injection Tests

While we're here: XSS
Just a quick test for XSS vulnerability: Go to a field and type the following

<SCRIPT> alert(“XSS”); </SCRIPT>

If vulnerable: Will popup a message saying "XSS"
If not: will accept/refuse your input and will not show XSS alert.

< Prev		Next >