Add manual SQL Injection steps into A1 app

[rafaveira3]

Motivation

Copy-and-Paste's attack narrative makes use only of SQLMap to show how an automated SQL injection could be performed.

It would be great if

We could also have the queries needed to perform an exploration of the intentionally vulnerable app manually. This would be interesting due to the fact that SQLMap can be very intrusive and dangerous to the application functionality.

What we expect

We expect to have the manual steps written down in the README.md with an explanation on how and why these commands work.

curl -s -H "Content-Type: application/json" -d '{"user":"-1'\'' <sqli payload here> ", "pass":"password"}' http://127.0.0.1:10001/login

Tips

• Testing for SQL Injection - OWASP
• Full SQL Injection Tutorial - Exploit DB
• SQL Injection Ninja Testing Labs - LeetTime

[giancarlopro]

can i do this one?

[Krlier]

Definitely, @giancarlopro! We'd be very happy to review any PR you send us.

[Krlier]

thanks, I will create an app for this issue ;)

Hey, @giancarlopro!

How's it going?

Can we help you with anything?

[giancarlopro]

thanks, I will create an app for this issue ;)

Hey, @giancarlopro!

How's it going?

Can we help you with anything?

Hi, i've been a bit busy lately and couldn't finish it yet, i thought it were vulnerable to normal sql injection, but it is vulnerable to blind sql injection and i found it more difficult to write about because of the repetitive nature of the method. So i thought about writing a script in python to automate it because doing it manually is a bit overkill. This is what i've writen so far

---

For this attack narrative, we need a valid user, we will use userBianca with password 123456 , and we will use blind sql injection techniques to get sensitive information from the server.
The following two payloads can be used to test if the app is vulnerable to this type o attack.

Bianca' and 1=1 - 
Bianca' and 1=2 - 

If we get two different responses from those payloads, the app probably is vulnerable.

Now, since the app don't return the result from the query executed, we need to make assumptions about the data, and use the response to confirm those assumptions.
The following payload can be used to check if there's any table with the name starting with letter 'u':

Bianca' UNION SELECT table_name,2,3 FROM information_schema.tables WHERE SUBSTRING(table_name,1,1) = 'u' - 

If the app responds with User not found or wrong password! it means that there is a table starting with 'u', then we can change the second parameter ofSUBSTRING(table_name, 2, 1) to test the second character. And repeat those steps until we find the table name. The one we're looking for is Users .
Now we do the same to find the columns from table Users . Using the same payload with small changes we can test the column names.

Bianca' UNION SELECT column_name,2,3 FROM information_schema.columns WHERE SUBSTRING(column_name,1,1) = 'u' WHERE table_name='Users' - 

And again we repeat it and to get all the column names.

[Krlier]

Nice job, @giancarlopro! Excellent work so far! 🎉

I understand the repetitive nature of this exploration method. Although, I believe it would be cool to be able to see the steps needed to exploit the app manually, which, in this case, does not mean we need to write every step needed.

In the scenario of this app, you could try describing what you intend to accomplish by using a certain command multiple times and, after those many times, what the app should return and what you'll do with it. Similar to what you did above!

What do you think?

If you'd like, add your suggested changes to the app's README and we can work together on writing the narrative! 🙂