Home

I haven’t done much of the exploratory testing as I would’ve like to, but I have gone through a few structured test cases. As I spoke about in the previous month, I’ve been reading The Complete Software Tester and I decided to learn more about APIs and SQL. To be more specific, I decided to learn about SQL injections (SQLi) because I didn’t understand how they worked.

A few years ago I learned some basic SQL by going through SQLBolt, but to see where I stood currently I signed up for a crash course this past week through CoRise. To be honest, because I was working I only made time to watch the first session, so I can’t give an accurate review of what took place. However, I did do both project assignments and completed the course. Essentially, they set you up on a Google Colab, and you work your way down the file answering questions with SQL queries. They made it relatable by having us look at sample Airbnb data to help our hosts make better decisions on how they took care of their guests.

I say all that to say, SQL in that respect isn’t… difficult. Like, it’s certainly not easy once you start getting into subqueries and unions, but I felt like I could think my way through a problem if I needed to. On thing that I felt was beyond me though was SQLi. I think it has more to do with the name. It’s like I’m taking a syringe and injecting code into a site or an app to cause chaos, and I felt by that imagery alone, that was enough to keep me away. Fortunately, as I was going through the book, I was also checking out content from Dr. Katie. She’s really big on discovering IDORs (also something new to me) but she has several videos showing her process of using Burp Suite to locate them. And because Burp Suite wants you to understand how their product works, they have an academy that walks you through not just SQLi, but also other vulnerabilities can be discovered with Burp Suite.

Just to be clear that was The Complete Software Tester > CoRise > Dr. Katie > PortSwigger Academy (Burp Suite) > SQLi

I say all that to say, I could’ve started sooner. The academy explains some of the common examples of SQLi as retrieving hidden data, subverting application logic, UNION attacks and Blind SQL injection. And you should’ve seen my eyes when they explained that you can (in some cases) view hidden content with a quote and two dashes:

'--

I’m going to use some of what they say as an example, but feel free to go through the labs yourself. Say you have a URL like https://someshoppingwebsite.com/products?category=Gifts, the equivalent SQL for it could be SELECT * FROM products WHERE category = ‘Gifts’ AND released = 1. “released = 1” just means that the product should be displayed, whereas unreleased products would be equal to 0. Let’s say this fake website doesn’t have any defenses against SQL and we add our quote with two dashes like https://someshoppingwebsite.com/products?category=Gifts’–, this turns into SELECT * FROM products WHERE category = ‘Gifts’–’ AND released = 1. The double dash is how you would start a single line comment. Whereas before we were searching for gifts and released products, because we’ve commented out everything after gifts, it would ignore the restriction of only displaying released products.

That was an example of SQLi! I was kicking myself when I found out it could be so simple. Now, stuff like that won’t work for everything, but it taught me that things aren’t as difficult as they appear. The real task would be to learn how to outsmart the program to use its own logic against itself.

I’m well on my way on this journey of testing. I know I got here in a roundabout way, but I think I’ll take some time to focus in on Burp Suite. I find the academy to be a valuable resource of information and it can only help at this point to understand more of Burp.