The next step after the OSWA, from black box to white box.

So why OSWE?

I’ve always admired the way experienced web pentesters can take a handful of obscure web app vulnerabilities and chain them all the way into remote code execution. My day to day work in malware analysis keeps me pretty far from that world. But looking at the research output of remarkable titans like Orange Tsai, James Kettle or Gareth Heyes always made me wonder if there was a way to better understand these more complex web vulnerabilities and move myself even a millimeter closer to where they stand.

This is me, basically:

That curiosity is what eventually led me to embark on studying the OffSec Advanced Web Attacks and Exploitation (AWAE) and pursuing the OSWE certification.

Background going in

I had some prior experience building full-fledged web applications using backend frameworks like Django, Flask, and Spring. That experience served me well when I went through the OSWA coursework and I thought I “knew things”. However, OSWE coursework was a different beast altogether. The complexity ramped up significantly, and it constantly made me reassess if I’ve truly understood something that I thought I was familiar with.

I would not say having that kind of prior dev experience is strictly necessary to get started on the OSWE journey. As an example of this, check out Jael Koh’s informative writeup on his journey through OSWE and eventually OSCE3.

The “rest of the owl” problem

A particular nitpick I had about the materials is that during the analysis of web case studies, there were some rare occasions where we would be finding vulnerability A then immediately going on to finding vulnerability B without always going into details of what typically happens in between.

• How did the assessor arrive there?
• What was the thought process that connected the two?
• How am I going to strategically find this vuln during a limited time engagement?

Now, in retrospect, there is certain value in this. Having to self-bridge that gap does, to some extent, force you to find and hone your own methodology. That skill pays dividends later. But in the moment, it can be genuinely stress-inducing.

You sit there wondering: “is it normal for someone to struggle this much to get from A to B?”

What I can suggest here is to get practical experience building and deploying small web app projects in the common languages you’ll encounter: PHP, Python, Java, C#. Once you’ve experienced the full workflow of setting up a project with a framework, defining routes, working with MVC patterns, and implementing basic authentication, those jumps from A to B in the course material become way more comprehensible. You begin to identify patterns in how a certain way of implementing a mechanism can potentially lead to something vulnerable, because you’ve seen how these apps are built from the as a developer.

Overall thoughts

With these minor nits aside, I remain a big fan of what I learned from OffSec here. It felt like a logical next step from OSWA, with much more advanced vulnerability classes on the table. The depth and difficulty were exactly what I was looking for.

Throughout the journey, I leaned on free resources to supplement the course material. PortSwigger Academy was great for getting a second perspective on specific vulnerability types, and Programming with Mosh’s youtube videos helped me when I needed more targeted, visual information on particular programming languages or web frameworks.

There’s just tons of other free resources out there, some crafted by those who have walked this OSWE journey before.

Labs, extra miles, and exam prep

When working on the labs, extra miles, and challenge machines, it is absolutely essential to start experimenting with scripting exploits on your own. The exam requires you to submit scripts that essentially compromise a target web application without any manual interaction, so you need to be comfortable writing full exploit scripts.

Rather than watching video walkthroughs or merely copy pasting snippets from the course or from online resources, I would say that actually typing the code out yourself, running into errors and solving them, makes a real difference for retention. When you’re sitting in the exam staring at a barebones script, you would not want to be bashing your head against the wall on syntax issues.

Also, kick the itch to use LLMs when debugging your scripts. They will not be an available crutch during the exam. Force yourself back to the docs, or Stack Overflow. Get comfortable (again) finding answers by searching for them manually.

And importantly, after you’ve finished crafting your practice scripts, take the time to properly organize them in your folders and document them in detail. You’ll want to be able to reference your own work quickly during the exam, and sifting through a messy pile of poorly named scripts is not going to be a good experience.

Overall tips and takeaways

• Build small web apps in PHP, Python, Java, and C# before or alongside the course. You don’t need to build anything complex. Just go through the cycle of setting up a framework, defining routes, understanding MVC, and wiring up basic auth. This alone will make the white box review process feel way less foreign.
• When you hit a point in the course material where the logic jumps from A to B and you can’t figure out how the author got there, slow down and sit with it. Don’t just move on. Try to think and step through the code path yourself. It can get pretty frustrating, but that definitely where a lot of the core learning happens.
• Use PortSwigger Academy alongside the course. If OSWE introduces a vulnerability class and you’re not fully grasping it, chances are PortSwigger has a lab or explanation that approaches it from a different angle. Having that second perspective can make things click.
• Start writing your exploit scripts from scratch as early as possible. Don’t wait until you’re close to the exam to start practicing this. Every lab and extra mile is an opportunity to build your scripting muscles. Type the code out yourself instead of just copying from the materials or from online without understanding them.
• Stop using LLMs to debug your code. I know this is a hard habit to kick in recent times, but you will not have access to them during the exam. Train yourself to work with the docs, or sources like Stack Overflow instead. The sooner you wean off the AI crutch the better.
• Organize your scripts and document them properly after every practice exercise. Write notes on what each script does, what vulnerability it targets, and any quirks / troubles you ran into. When exam prep time comes around, having a well-structured personal library of your own work is worth its weight in gold.
• If you’re coming from a background that isn’t heavy on web app security, give yourself grace. The learning curve is steep and you will feel lost at times. That doesn’t mean you’re not cut out for it, many web security giants had to go through the struggle of learning some of these tough concepts as well.
• Lastly, have faith and be kind to yourself.