Offensive Security Web Assessor (OSWA) is a certificate that provides you with the practical skills to perform a security assessment on a web application. You learn the most common web application vulnerabilities, how they work and how you can exploit them such as SQL injection, XSS, SSTI, and more. The certificate is focused on being practical, a hands-on keyboard approach where you have to get your hands dirty by doing labs.

The OSWA exam itself consists of two parts, the first part is hacking 5 applications and finding at least 7 out of the 10 flags by exploiting the vulnerabilities. Each application contains two flags, where the first flag local.txt can be found by accessing the admin panel and the second flag proof.txt can be found on the server. You’re provided with 23 hours and 45 minutes of access to the exam lab environment. The second part is writing a professional penetration test report, you have to submit this report within 24 hours after the access to the exam lab has expired. So in short, after starting your exam and gaining access to the exam lab environment, you have a little less than two days to submit your report. Let’s dive into how I prepared for this exam.

Study preparations

There are different ways how you can prepare for this certificate. I had a one-year Learn One WEB-200 subscription from Offensive Security which gave me access to the WEB-200 course and two exam attempts. This is also the official courseware for the OSWA exam. I’ll give a quick summary of the OSWA WEB-200 course and my timeline for preparing for the exam.

WEB-200 course

The course aims to provide you with all the necessary skills to carry out a penetration test against web applications. The following topics are covered:

• Tools for the Web Assessor
• Cross-Site Scripting (XSS) Introduction and Discovery
• Cross-Site Scripting (XSS) Exploitation and Case Study
• Cross-Origin Attacks
• Introduction to SQL
• SQL Injection (SQLi) and Case Study
• Directory Traversal
• XML External Entity (XXE) Processing
• Server Side Template Injection (SSTI)
• Server Side Request Forgery (SSRF)
• Command Injection
• Insecure Direct Object Referencing

The course consists of pages with theory, example videos, and practice labs. The pages with theory are concise and contain examples of commands and code you can use to discover a vulnerability or conduct an attack. Some of the topics provided sandbox machines containing topic-related vulnerabilities you could connect to via VPN. This was a nice way to play around in a sandbox to better understand a vulnerability and instantly put to practice what you’ve learned. Also, the course provided five practice labs which gave a good taste of what kind of applications you could expect on the exam. It’s good to note that no hints or answers were available for these labs, simulating the exam experience. But when stuck you could turn to the Offensive Security Discord server to ask for hints and guidance. As far as the course goes, I’ve not watched the provided videos as I prefer to just read theory and practice. However, some prefer learning by mimicking what’s shown in videos, some prefer learning by reading the theory, and some prefer learning by trial and error by sweating in a lab. Whichever one you’d prefer this course provides it.

Study timeline

I started by going through the theory and practice by doing the labs. As I already had experience with web application penetration testing, I prepared for 3 weeks, going through the course material and doing the practice labs. I studied for an average of 3 hours per day. After these 3 weeks, I did the OSWA exam.

Exam preparations

Kali virtual machine

In preparation for my exam, I prepared a Kali virtual machine snapshot that had all the tools installed that I needed, contained folders for the exam, and was configured to backup itself every hour to ensure no precious data was lost if anything happened to my computer during the exam. First, I installed the following tools on the virtual machine:

• SecLists: a repository of wordlists used for discovery, and fuzzing during the exam
• PayloadAllTheThings: a repository of payloads for different web technologies and vulnerabilities
• Gobuster: a tool that helps to quickly discover directories and files

Second, I created the following folder hierarchy which I used during the exam. The exam-connection folder contained all connection package files. The filehosting folder I loaded up with pre-made malicious files, such as a JavaScript file that steals cookies. All files in this folder were hosted on my kali machine by cd’ing into the folder and running python3 -m http.server 80. In the target-0X folders I saved specific files or POST requests related to the target.

oswa/exam
├── exam-connection
│   └── connection pack files
├── filehosting
│   └── xss.js
│   └── cookies.js
│   └── etc...
├── target-01
├── target-02
├── target-03
├── target-04
└── target-05

Third I configured Parallels to backup my Kali virtual machine by making a snapshot every hour, so when anything happened I could go revert to the latest snapshot. After making everything in order I created a snapshot of the finalized virtual machine, so I could always revert to it if something broke.

Commands and payloads

In preparation for the exam, I created an OSWA repository containing commands to use during the exam in the folder commands. It consists mainly of wfuzz commands using wordlists from SecLists. To be able to quickly execute the prepared commands, it relays on having set terminal variables with the URL and IP of the target machine. You can do this with the commands export URL="http://192.168.XX.XX" and export IP="192.168.XX.XX".

Notes and reporting

To spare time on the exam, I used both a note and report template which can be found in the folders note taking and reporting of the OSWA repository. For note-taking, I used Obsidian where I created a note for each target machine using the machine_template.md template. For reporting, I created a Word template based on the exam template provided by Offensive Security but with improved visuals, layout, and headers.

The exam

The exam consists of two parts, the hacking part, and the reporting part. Before you can start with the hacking part of the exam, you have to log in to the proctoring portal to complete identity verification and proctor setup. After which you get an email with the VPN connectivity pack to connect to the exam environment, the list of exam servers assigned to you, and a link to the exam control panel. In the exam control panel, you can submit flags and reset machines. Use the VPN file and the provided credentials to connect to the exam lab environment. Now time is ticking, 23 hours and 45 minutes are left to get these flags and submit them to the exam control panel. When the time has run out, you have another 24 hours to write and submit your exam report. To pass the exam you have to get 70 out of the 100 points, with every flag being worth 10 points. Every machine contained two flags, a local.txt flag which can be obtained in the admin panel of the application, and a proof.txt flag which could be obtained by executing code on the server.

The hacking part

Before starting to run in guns blazing, I carefully read the exam objectives. The main objectives for each machine were identifying and exploiting a vulnerability to gain access to the admin panel of the application and gaining access to the server. Another objective was to submit the flags to the exam control panel. Be aware that you can’t access the exam control panel after your lab access has expired, meaning you’ll have to submit the flags during the lab access. Besides the exam objectives also the documentation requirements can be found here, which I read but not carefully enough. I only found out in the early hours of the morning that they wanted to have a screenshot for each flag showing the IP of the target, the local.txt or proof.txt value in the browser, and the Burp Suite request and response showing the flag value. As I made the mistake of creating hostnames for the different targets, I had to retake these screenshots at four in the morning. So, my advice is to also read the documentation requirements in detail.

During the exam, I took screenshots from commands I performed on web pages in specific exploit stages. Every 3-4 hours I took a break - not including lunch and dinner - with a duration between 3 to 10 minutes. I made sure to have healthy food in the fridge so my energy would remain steady, such as fruit and pre-prepared meals with low fat. This also helps to not have to leave the house.

When I started testing my first target machine, at 8:00 in the morning, I found the vulnerability rather quickly but got stuck on exploiting it successfully due to having tunnel vision. After 4 hours of seeing no light at the end of the tunnel, I took a step back and looked again at my recon information and quickly found out the way to successfully exploit it, but already spend five hours on this one machine. I was thinking too hard. I took a few things in mind going after the other four targets: if stuck go back to recon and don’t overthink it. I tried for another hour to get the second flag on the first target but decided to move on to seek success elsewhere. The four other targets went rather smoothly, with getting both flags in roughly two hours on average. For each target, I wrote down all my recon findings, information, vulnerabilities, exploit steps, and flags into a single note dedicated to that target. Here’s the note template. For a few targets, it was really important to have used the large wordlists for finding directories or files, rather than the smaller ones. I used these prepared recon commands and testing vulnerabilities commands during the exam. While the time it took to finish these scans was longer, it contained important clues. Don’t be impatient during recon. At 22:30 I obtained the 8th flag and after an intense day of testing decided I could relax now.

I planned to fix the documentation first and try the remaining flags later. Because if I did my documentation correctly, I would pass. However, there were two flags left and I couldn’t resist trying to get those. So my plan ended up in the dumpster. I started by going back to the first machine trying to find the vulnerability for the second flag, and after an hour or so found it. The exploitation, however, was not a success. While also having taken a look at the other missing flag I decided at 4:00 in the morning it was time to stop. I went over my checklist. First I made sure all flags were correctly submitted to the exam control panel. Second, I went over the exam objectives and documentation requirements to make sure I got everything before logging off. This is when I found out that I didn’t have the correct screenshots, as I used hostnames instead of IP addresses during the day. I had to retrace all the steps for each of the flags to take new screenshots. This was also a good test to make sure I documented all the steps correctly for the report. I advise you to do this documentation and evidence accumulation when you’re still sharp, instead of in the early morning. I created another snapshot of the virtual machine and at 5:30 logged off.

The reporting part

After having slept for 5 hours I started writing the exam report. I used the pre-created OSWA-OS-XXXXX-Exam-Report template and started filling it with the findings per target. In the end, this is the document they will grade you on. I made sure to follow all the documents requirements, making sure to explain each step of the exploitation, referring to what scripts I used and how I altered them, and to have added all the flags with the screenshots as evidence, and provided a summary of the vulnerabilities found, performed attacks and the exploitation process. After a long day of writing, pasting screenshots, and pasting commands, it was finally time for the last part. Submitting the report. Now, this is another part you have to pay attention to as it has to be done in a particular way, and here you just have to follow their instructions, rename the PDF file, and zip it to a 7zip archive. Now with this archive, I made sure the PDF in the archive still renders correctly and wasn’t altered. After having made sure everything is correct and the MD5 hash matched my archive and the one uploaded, I submitted the report to Offensive Security at 1:15 in the morning. After a few days of waiting in anticipation I received this great email:

Figure 01. Passed the OSWA exam!

OSWA repository

I’ve created an OSWA repository which contains a list of useful commands for discovery and exploitation, a note-taking template for exam machines, and a report template for the exam report. Please use it!

Conclusion

The OSWA certificate provides you with knowledge about how to conduct a web application penetration test. The course material is concise and provides you enough opportunity to practice. What is teached in the course can be applied during the exam one on one. I found the exam fun to do partly because it was a challenge to do proper time management with having to hack five applications. The WEB-200 course provides different ways to learn the content, which I like. However, I think the course is expensive if you compare it to the free Portswigger Academy or INE eWPT, as they do cover roughly the same content. Now, what is the value of this certificate careerwise? This I can’t judge as the certificate is new and we’ll have to see how it’ll be adopted by the industry. Non the less, it was a fun experience which I can recommend if you have the spare money or opportunity to do so.

My tips for the OSWA exam:

• Practice, practice, practice
• Do the practice labs to simulate the exam
• Read the exam objectives and documentation requirements carefully
• Take notes and screenshots of everything you do
• If stuck, go back to recon and the given course material
• Don’t think too hard
• Enjoy the ride!

References

Offensive Security Web Assessor (OSWA)
OSWA repository
SecLists
PayloadAllTheThings
Gobuster