OffSec Web Expert (OSWE) Review
Introduction
The OffSec Web Expert (OSWE) is an web application penetration testing certification offered by Offsec that teaches advanced web attacks and exploits, with an emphasis of performing white-box engagements and source code review.
It comes with the Advanced Web Attacks and Exploitation (AWAE) video and text course and it’s one of the major advanced certifications in the penetration testing world. In this review I take the time to talk about my personal experience with this course, the learning material and resources I used to prepare etc.
Background
I had been wanting to complete OSWE in a while, but I always felt somewhat intimidated by the challenge of the exam, but since my OSEP exam was three years ago, I felt like it was finally time.
I did not do any specific preparation prior to starting the course, as I already had 5+ years of experience in web testing and I felt pretty confident I had a solid grasp on all the main attacks and techniques.
Exam Preparation
To prepare for the exam I used various resources, both part of the course and external. As much as the course material is more than enough to pass, and you shouldn’t find any attack or technique in the exam that wasn’t mentioned in the course, I wouldn’t exclusively rely on it.
The course content can feel somewhat rushed at times, so it is definitely useful to have some extra challenge, especially when it comes to deep diving into source code and finding vulnerabilities manually.
The WEB-300 Course
The learning material provided with the course covers a wide range of web attacks and vulnerabilities, such as deserialization, SQL injection, cross-site scripting, client and server-side request forgery, XML external entity injection, prototype pollution, template injection, command injection and more.
I purchased three months of lab access, at first I wasn’t sure whether it would be enough, however after chatting with a few colleagues who had already attended the course, and considering my existing experience, I didn’t feel like I needed any more time.
I started by going through all the modules within the course, watching the videos and reading the corresponding text, completing and documenting all the exercises. I would copy all code snippets, commands or other information that I thought was relevant in my Obsidian notes.
Unlike other courses, WEB-300 does not have a section for each topic, but instead it uses case studies from previously identified vulnerabilities to showcase them. While confusing at first, I really liked this approach as it put the student in the shoes of a bug bounty hunter or researcher looking for vulnerabilities in large enterprise-style applications.
Due to the large code base of the applications, and in the interest of time, the process of identifying the vulnerabilities illustrated throughout the course may feel sloppy and rushed at times, for example searching for SQL statements to identify potential injections, but totally skipping the manually process that eventually led to such discovery. I totally understand why this approach was followed, however a less experienced tester may feel a little bit lost.
I recommend completing and documenting all of the exercises as they will be a good way to put the techniques learned into practice and solidify your knowledge. The code used throughout the learning objectives will also come in handy during the practice labs as well as the exam. The extra mile exercises may feel tedious and even pointless at times, however they definitely provided some good value for me. Some of them even included finding vulnerabilities in off-the-shelf applications.
While I don’t think the content is anywhere near perfect or cutting edge, especially considering some of Offsec’s competitors, it definitely provided me with a huge amount of value and practice.
It took me about one and a half months to complete all of the modules, and after that, I got started with the WEB-300 labs.
The WEB-300 Challenge Labs
The labs were comprised of seven standalone web applications, plus a couple of modules part of the learning content that required flags to be submitted as part of challenges. Six of the applications were white-box, with one being black-box and slightly more CTF-style.
This was definitely the most interesting part of the entire course, as you get to play around with vulnerable applications that feel realistic, unlike most CTF challenges out there. The code was relatively well written, and I could tell that some real work had been put in them.
I suggest to try and complete as many of these as you can if you want to have a good chance at passing the exam, as they will somewhat simulate the exam experience. Some of them include multiple paths, so if you think you may have missed them I would recommend going back and trying to find them all.
Make sure you carefully document each of the steps you performed during the challenges and all of the code used, as these could come in handy later on, as well as they will get you in the habit of always taking notes and screenshots of your steps.
With your lab access, you also get access to the Discord and the official forum where you can discuss the challenges with other students, and provide/receive hints. Try not to rely on hints and help from others too much as this can be a bad habit that might cause you to fail the exam.
It took me two and a half weeks or so to complete all seven challenge labs. I was able to complete the first three, easier challenges without any assistance, I then completed my next two with little assistance, and required quite a bit of help to finish the remaining two.
My only complaint about the lab challenge labs was that the difficulty varied greatly between them, and there was no indication of which ones were easier than others. This may make you feel discouraged or give you a false sense of security depending on the order in which you decide to tackle them. I wish the student panel had a difficulty rating for each one to help students determine the next challenge to complete.
External Preparation Resources
Along with the material provided once you enroll for the course, I suggest using a number of external resources to better prepare for the exam. Unfortunately, there aren’t many white-box challenges available online, however luckily the course itself does a really great job at preparing you for the exam.
I have listed below the resources I personally used for my preparation after completing the lab challenges.
- PortSwigger Academy (Especially SQLi, Deserialization, SSRF, SSTI, Prototype Pollution and XXE)
- VulnHub
- SecureCode
- Cryptobank
- Zorz
- Pipe
- Potato
- Ted
- GitHub
- William Moody
- Chat
- Testr
- Tudo
- java-deserialize-webapp
- William Moody
Some of these boxes may require you to do some small changes to the Docker files to ensure they work with the latest packages.
Despite some of these not being intentionally white-box, you can often simply access the virtual machine and transfer the code to your local host with SSH or Rsync and use more of a source code review approach. Other platforms with paid subscriptions with as Hack The Box, PentesterLab and TryHackMe also offer some valid content, however I didn’t personally feel these were necessary.
These are also some external resources/links I have used during my preparation for the exam:
Tips & Tricks
As you go through the course material, complete the challenge labs and other machines, make sure to save any useful code snippets, payloads and commands that you may need during the exam. You should have template scripts for most functionality/exploits so they can be easily re-used, and you should be very comfortable writing Python code (or whatever scripting language you prefer) and using common libraries like requests.
Make sure you are comfortable reading source code in different languages, as challenges may include Java, PHP, Python, JavaScript, C# (.NET) and more. While you don’t need to have advanced development experience, you need to be able to understand what a certain application’s logic is doing, trace its origin and identify any potential issues.
If you are unable to perform the authentication bypass portion of a challenge, you can skip ahead and login as an admin user (for example by changing its password in the database), which may help you identify the intended path, which may be unclear at first when logged in as a low-privileged user. Additionally, this can help you focus on the remote code execution portion while you are stuck on bypassing authentication.
You should be able to comfortably use a debugger (for example with Visual Studio) in order to analyse how certain code is functioning, and whether there may be possibility for abuse. When attempting to exploit SQL injection attacks, it can be useful to enable logging of queries in the database to see exactly what query is being executed, and run it manually to fix any syntax mistakes if necessary.
While source code analysis tools such as Semgrep are not allowed during the exam, during your labs it may be beneficial to run it against your application after having compromised it manually. This can help compare notes with the tool and identify any additional vectors you may have missed.
If you are struggling to replicate certain requests in Python or JavaScript, for example as part of an automation or cross-site scripting payload, it is always good to proxy your request and compare it with a working one using the Burp Suite Comparer tool. This will help you find any missing information or discrepancies that may cause your request to fail.
Additionally, tools like Curl Converter are great as they allow you to convert any Curl command to various scripting languages, so if you have a working request in Burp you can simply right-click and hit “Copy as curl command”, and paste the command in Curl Converter. The tool is available both as a website and a Pip package. I found this particularly useful with requests that were particularly complex or that were uploading files to a web application.
The Exam
The OSWE certification exam two web applications, with two flags on each, obtained upon achieving authentication bypass and remote code execution. In total, you will have 47 hours and 45 minutes to complete the exam.
There will also be a debug machine for each of the web applications, where you will have root access to and the ability to connect to it via SSH and RDP. This will allow you to analyse the source code, and performing any required debugging and troubleshooting, as you are not allowed to download any of the code onto your host.
A Kali Linux machine is also available where you will be able to test your exploits and make sure they work in the exam environment. I suggest that after getting all your flags you run your scripts on this machine a few times (reverting the victim machine each time), as this will help you catch any mistakes. You should avoid hard-coding anything within your scripts and parametise things where possible. Also any proxying should be removed as otherwise the script will fail when run by Offsec to validate it.
The Exam Control Panel will contain specific instructions for your target applications and the exam objectives. Make sure you read these carefully as they will contain useful information on what your path may be.
In order to pass, you must obtain at least three flags (i.e. authentication bypass on both machines and remote code execution on one of them), which will result in 85 points.
Upon ending your exam, you will have 24 hours to submit a detailed report on how you exploited all of the vulnerabilities, including specific information to explain exactly why the code was vulnerable.
Make sure to read the OSWE Exam Guide and to carefully follow the exam objectives, reporting requirement, exam restrictions and proctoring rules, as failure to do so may result in a fail mark.
I cannot stress enough how important it is to take frequent breaks, consume plenty of water and food, and get quality sleep. I would take breaks at least every three hours, as I have learned over the years that when I am stuck on something I am much more likely to make progress if I go and do something else for a little bit and come back to it with a fresh mind, then if I keep banging my head against the wall for 10 hours straight.
My Exam Experience
I had booked my exam a couple of days before my lab time was meant to expire, to make sure everything was still fresh in my mind. The exam started at 10am, after completing the verification process I started going through the exam objectives and setting up my environment.
I first connected to one of the debug machines via RDP to start looking at the code, however I quickly realised the environment was extremely slow, to the point it was almost unusable. Every action in the RDP client took about 5 seconds to execute, making the code analysis and debugging process extremely frustrating. I tried multiple RDP clients and settings (recommended by the support team) to no avail.
After contacting support via the exam chat, x11 forwarding was recommended as a potential solution, however after trying this for an hour or two, it didn’t seem feasible (Visual Studio required the remote SSH extension apparently) and I didn’t feel like sinking any more time on it.
I decided to instead connect to the debug machine via SSH and use commands like cat and grep to analyse the code and copy it into my Obsidian notes where needed. Needless to say this was far from ideal. It is actually impressive how Offsec has managed to create such an under performing environment, especially when they are considered the gold standard in the industry.
After spending a little bit of time on the first application without getting anywhere, at around 12:30pm I decided to go on a walk to clear up my head. After getting back home and having some lunch I resumed and decided to look at the other machine instead. After three or so hours, I had made some progress and had a good idea on how to get the first flag, so I took another break and went on another walk.
I once again resumed the exam at around 6pm, and in a couple of hours I finally had my first flag and my first script to extract it written up. I then had some dinner and went back at it at around 9pm. I spent the next three and a half hours or so trying to obtain remote code execution on the same machine, with no success. While I was on the right path, I didn’t have the right payload to exploit the vulnerability. I decided to get some well deserved sleep feeling somewhat satisfied with the progress I had made.
I woke up at around 9am and almost soon jumped back into the exam. I looked at other avenues for RCE on the first machine for a few hours but ultimately concluded the previous path was the correct one and I just needed to spend more time on it. After getting some lunch, I decided to go back to the other machine and after more analysis of the code, I was finally able to find an authentication bypass at around 3pm. I then spent the following two hours or so writing up the script and making sure it worked consistently.
After a long break, at around 6:30pm I resumed the exam focusing on getting RCE on the machine I first bypassed authentication on, and after some time spent trying a million different payloads, I finally found one that worked. I decided to write my script to obtain a reverse shell, which proved more difficult than I originally planned, however by around 9:30pm I was all done.
I took another quick break and then spent the next hour running all my scripts a bunch of times on the Kali VM provided in the exam environment, after reverting the victim machines each time, to ensure they worked consistently and without any issues. This was crucial as it made me realise I had accidentally pasted some extra content into one of my scripts which caused the payload to no longer work.
I then went through all the notes I had taken during the exam, making sure I had all the necessary screenshots and code snippets, I had submitted the right flags in the control panel, and I wasn’t missing any information for the report. Although I had another 10 hours or so left, at around 12am I decided to end my exam early to prioritise some good sleep and report writing in the morning, as I already had enough flags.
I woke up around 10am the next morning and I spent a couple of hours adding all of my notes into Offsec’s Word template, fixing any spelling mistakes and adding more information where needed. I then made sure my report was in the right format and submitted it at around 12PM.
After about 5 business days from submitting my report, I received the following email stating I had passed the exam. There are no words to express how happy this made me, it was like an early Christmas gift from Offsec.
Conclusion
Overall, I had a great experience with this course as well as with the exam. I have learned a ton of advanced web techniques and I now feel a lot more confident reading through code and identifying security issues that way.
That said, the hefty price tag and underwhelming performance of the labs may not be worth it to you, especially considering the content that some of Offsec’s competitors have been putting out there.
I would definitely recommend this course for anyone in the industry who already has some solid web pentesting experience and is looking to sharpen their skills in more advanced areas and become more knowledgeable when it comes to performing white-box assessments.
