Published on

Offensive Security Web Expert (OSWE) Review

Authors
  • avatar
    Name
    Nicholas Chong
    Twitter
oswe

Background

On the 4th May 2022, I was towards the end of my second year in university, which was when I started working on the AWAE coursework. Prior to that, I achieved the eCPPTv2 certification and was already working on the PortSwigger labs during my school trimester breaks. Apart from that, I was constantly reading disclosed bug bounty reports. During the time when I was working on the course, I was also leading one of my ITP (Integrative Team Project). The ITP is a module that occupies an entire academic trimester. Its aim was to get students grouped into teams of 5-6 and utilize all the knowledge from previous modules to provide a solution for a real problem. As I may digress (you can skip this part), my project was to develop a Secure Patch Distribution Framework that will ensure non-repudiation of software patches and allow software vendors to do an open declaration on the actions in all patches. The declarations are to be validated by a third party. Basically, the problem stems from the Software Supply Chain security landscape and past incidents like SolarWind’s compromise. Okay, back to what this post is about. What is OSWE?

To those who don’t know what is OSWE, here is your answer https://www.offensive-security.com/courses/web-300/ . Basically, it is a certification exam that focuses on white-box web application testing. This means that the course heavily touches on code audits across an array of different programming languages. The practical exam is 47 hours 35 minutes where your goal is to get at least 85 out of 100 points. You will have to write a single exploit script per target application. I think there are many other reviews out there that have already explained what the exam is about, so I won’t say any more.

Preparation

I am assuming what you are here for is how I prepare for the course and the exam. A disclaimer that what works for me may work for you or not. First off, I have not done the PWK and am not OSCP certified. Second, I am very comfortable with programming and picking up different languages easily (at least to a basic comprehendible level). Next, I am fairly okay with SQL as I have done somewhat complex nested queries and union/join queries during a particular course, not to mention a even a written examination on that… I didn’t do any HTB or PG, but have worked on many PortSwigger labs, even redoing some of them. I guess one thing coming towards the course was that when I do the PortSwigger lab, I make notes or at least try and understand why the vulnerability even exists. Even thinking about how the backend code may look like. Of course, this is not something anyone will be able to do right off the bat. Neither did I, I was only able to do it because I did work on PentesterLab labs, and they do go through the source code for most labs. At that point, I was already comfortable with Burp Suite, reading simple source code snippets.

Pre-requisites

For the folks who have never or rarely program before, some tips you can do before starting the course are:

  • Learn python scripting (try to use it to work on PortSwigger lab, there are plenty of online resources out there, YouTube, Github)
  • Create a simple web application using MVC architecture. Maybe do it in Java with Spring framework to get a feel of a compiled language. Make sure your web application involves a relational database like MySQL or PostgreSQL.
  • Extra mile is to create intentionally insecure endpoints and script the exploit in python. Afterwards, you can do a simple patch (in your own understanding of how to block the attack). You want to at least be familiar with Java, PHP and NodeJS and especially Python since I am assuming that will be your choice of scripting.

Coursework

Each lab contains a series of follow-me exercises where you can watch the video or read the PDF to understand how to get the vulnerabilities and how to script them. However, the real value of the course is the extra miles. The extra miles will help reinforce the concepts taught, so please do them as much as you can (I didn’t manage to complete all of them due to my school project). One encouragement is to not be intimidated by the different programming languages used in this course. In all honesty, programming languages function the same way (at least on the surface). Unless you are a software engineer, you only need to worry about understanding or interpreting the flow of the code.

The Exam

It is daunting to take an almost 48 hour long practical exam, but it is not impossible if you are well prepared. Some tips are:

  • Make template scripts for different vulnerabilities (ensure that they are easily modifiable)
  • Make notes on how to setup your debugging environment (this spans from using VSCode debugger to enabling logging on Web Application Services such as Database logging).
  • Note down the different quirks of different programming languages (e.g. string concatenation in PHP vs Python)
  • Make a Regex note where you can refer what the regex do when using it for string search

My strategy

Devise a strategy for the exam. My strategy was to first and foremost set up my debugging environment. Look for the file that contains all the routes and start to inspect them. Aim for low-hanging fruits (you should know what to look out for at this point). If you know that a section of the code is vulnerable and compromising it will help you to achieve the exam objective, then you can start to look for other entry points to hit that section of the code. Basically, similar to the nature of many web vulnerabilities, it is all about sources and sinks (user input to objective).

Understanding what you control & what you are looking at

Know what the parameters are you can control, and understand the impact of when they are compromised or abused. It is good to employ a breadth first search strategy and only a depth first search once you manage to obtain significant progress. In my humble opinion, understanding the rough sense of how the application is structured (code architecture and programming paradigm) will give you a better advantage as time passes, as compared to just hitting on one section of the code in the beginning.

Debugging and logging is 90% of what will enable you to pass

Debugging and logging is essential as it will help confirm your doubts if your payload is being sanitized or not. Being able to setup breakpoints or observe SQL logs will help you to craft the payload you need to trigger the vulnerability. Some of the labs present certain obscure non OWASP:2017 top 10 vulnerabilities. There is always a reason why Offensive Security includes them. That is to widen your horizon and let you be aware of such bugs (you know what I mean), so don’t just skip them. What I did was to try and use burp suite to trigger the vulnerabilities. Before using chaining, them in python, I make subscripts for each vulnerability in python. Of course, there a instance where you have to include previous scripted exploits. Make sure to always save the individual exploit script as you build a final chain exploit script.

Conclusion

The course has widened my perspective on web security and it is definitely worth the money. Offensive Security is infamous for the “Try Harder” mentality. I am not familiar with this as I didn’t feel it in this course. Maybe the OSCP folks can weigh in on the PWK, but AWAE/OSWE is a well-structured course that can actually be done in less than 90 days if you can actually commit full time to it.

With that said, does this course makes me a Web Security Expert? I will honestly say no. Not to discredit the value of the course but a course that typically spans across 30-90 days can only cover so much.

oswe-result