Posted in Blog, PortSwigger

PortSwigger Web Academy – What have I gotten myself into? (SQLi)

So I’ve started working on the PortSwigger Web Academy because why not? Well, maybe because I’m (still) working on the IHRP stuff from eLearnSecurity and have started the THP course to help prep for that. Why do web app pentesting stuff? The short answer is because I think it nicely complements what I’m doing. Maybe I’m trying to justify my habit of chasing squirrels, but I’m seeing direct application already of what I’ve learned doing the SQLi section and what I need to do day-to-day. I am focused on the incident response/threat hunting/threat intel side of things, but I believe the info in the Web Academy supports those. It’s giving me ideas for things to look at and valuable hands-on keyboard stuff to go with the more theoretical stuff I’m doing to prep for IHRP.

I hope to script out the labs to get more practice with Python (one of the things I’m working on – those will end up on my GitHub), and I’m planning to make some short notes on here to kind of summarize what I’ve learned and how I’m applying it. The labs are excellent and build well (as in from one lab to the next) for the most part. There are some jumps, but solutions have been provided for every lab I’ve looked at so far. The community solutions are solid too. The community solutions aren’t available on all labs yet, but it looks like Rana Khalil and Michael Sommer are both working on getting labs done. They have different styles, but both are helpful.

Need To Know

The content helps with the labs, but there are sometimes jumps or connections that aren’t presented. Since the solutions are provided, it’s not bad. If you have the Web Application Hackers Handbook, it’s good to have on hand. You will also need Burp Pro to do some of the labs. It’s not cheap, but it’s not terrible. You can do a lot with the free community version, but there are some things you just can’t do with it. It’s also rate limited so some things will be painfully slow. Scripting can help but not completely. Scripting something out can mean it takes minutes instead of hours (and hours) in the Community version though. I’d recommend picking up the Pro version if possible.

Either way, take some time learning about how to use Burp Suite. Definitely tweak the options to set up the fonts and theme to your liking. I find the default fonts a little hard to read. And if you are a keyboard shortcut addict (like me), use the keyboard shortcuts and add your own. My little cheat sheet for keyboard shortcuts is here and includes the ones I’ve added to make my life easier (Burp is toward the bottom – I put everything here because it works for me).

I think someone with little to no technology background could do these, but it would be very frustrating. With the solutions, getting through the labs without knowing what you are doing is possible, but I don’t think that would help with either passing the certification or developing a solid skillset. If someone were to use the content in the Learning Path as a guide, I think you could go from limited skills to a decent set of web app pen testing skills (to use for bug bounties for example). I think supplementation would be necessary.

My General Approach

I try to at least get started on my own, but I go to the solutions after a bit. That’s just the reality of my limited time. I’ll do what I can without looking, but I’m not willing to spend hours tracking stuff down. Initially at least. The good thing about the PortSwigger provided solutions is they are broken into steps so you can unhide to get an idea of where to go next and hide again to see how far you can get with that breadcrumb. The solutions also don’t give exactly what to do (because of variability in the labs), so you can’t just point and click your way through. I used them to work through the first section (SQLi), and then I went back through using the Khalil videos on a couple to improve my understanding. After a few of those, I decided scripting the exploits would force me to understand the process more deeply, so I went that route. Plus Python practice. I do recommend going through the content before the associated lab – that will help quite a bit. If you are experienced pentesting web apps, it might not be worth the time.

My goal is to get the information in an efficient manner, and this approach works well for me. I repeated the labs until I could solve them quickly and consistently to ensure I had the concept down. If I didn’t understand something, I went searching so I understood what was going on. I feel a little bleh about going to the solutions, but I have to prioritize where my time goes. Yes, I’m rationalizing. No, I don’t care. At least not enough to not do it.

SQLi Takeaways

The biggest takeaway is to have a framework/methodology. The labs hint at this by their order and scaffolding. I think the biggest disconnect between the labs and real-life pentesting is the labs told you where to look. Burp Scanner is incredibly helpful, but if you don’t understand how the exploits work, having the payload provided may not be enough. A big bonus of working through this section was getting really familiar with BurpSuite. I’m still not great, but I’m much more comfortable with it than I was. I think that will help make future labs a little bit easier since I’m better with the toolset.

My general framework for checking for SQLi manually:

  1. Poke around and see possible injection points – use Burp Proxy, Inspector, etc. to see where I can mess with things.
  2. Try things that will work for each of the popular database types (Oracle, MySQL, MS, etc.).
  3. Try messing via basic injections like ', '--', ' OR 1=1-- to see if it breaks anything.
  4. Depending on what happens in earlier steps, determine if UNION approach might work, if so try UNION approach.
    1. Try to determine columns using ORDER BY.
    2. See if any columns take text using UNION SELECT null,'a' approach.
  5. If nothing is obvious, try basic blind SQLi attacks.
  6. If still nothing, give the DNS lookup option a shot.

Depending on what you are doing, using a scanner might save you valuable time. But scanners can sometimes be problematic (or too noisy when pen testing). If you use Burp Scanner, make sure you look through the options. The default scan doesn’t take the everything but the kitchen sink approach, so if you have an idea of what to look for, you may want to customize the scan.

I probably won’t be doing a lot of lab explanations/walkthroughs. I think looking at how people approach the problem is helpful, so I might jot down a few notes if I have time, but more than likely, I’ll throw scripts on GitHub (probably with more documentation than is Pythonic) and section reflections here.

Going Forward

How long will it take to finish all the sections? Kind of feel like forever given it’s not my primary focus. But it’s fun and a nice way to shift my focus and wake my brain up a bit. The scripting practice is really good for me.

I would definitely recommend this if you want to get into web-app pentesting. It’s a good way to get practice even if you stick with just the Community version. If you are a staunch blue teamer, it might not be the best use of your time, but I think it’s helpful to switch things up occassionally.


Lifelong paradox - cyber sec enthusiast - loves to learn

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.