- Classic SQL injection test / payload stuffing assault (i.e.
' or '1'='1 --)- Trying to use a POST or JSON or even SOAP/XML request? You can copy-paste it from Burp into file, tag your intended injection point with a
*and slap it into sqlmap or ghauri with the-r muh_req.reqflag.
- Trying to use a POST or JSON or even SOAP/XML request? You can copy-paste it from Burp into file, tag your intended injection point with a
- Pop in some wildcards:
*and% - Throw in some empty strings or
',",=or'
Mess around with parameters like:
_Login then login then login then login_
- Try using a valid session or UUID, then mix it up with (other people's) correct, expired and faulty session IDs. Note changes in server response time, minimal differences in response size or content and investigate deeper.
Quick login testing methodology run:
- Login, get sessionID
- logout
- make request while logged out w/ sssionID
- request with expired ID
- request with faulty sessionID
- how about two IDs log in simultaneously and send requests (parameter pollution? race condition? almost anything you can do to a normal web app)
More tests to try, just to show mindset: Try sending...
- Username and password
- just password
- just username
- username and username
- password and password
- nothing just <login> </logiN>
- <user_name> <pass_word>
- <user> <pass>
- <username> <pass>
- <user> bigboy </user>
- mypassword </password>
- make payloads gigantic
<login>
string(//user[username/text()='' or '1' = '1' and password/text()='' or '1' = '1'])
</login>
Some things you can use to get BOLAs/IDORs, bypass auth or another mysterious outcome in your favor!
- Wrap ID with an array {“id”:111} --> {“id”:[111]}
- JSON wrap {“id”:111} --> {“id”:{“id”:111}}
- Send wildcard {"user_id":"*"}