In this post I will talk about my experience with preparing for and passing the OSWE exam and collect the resources I found useful for this certification. This course is offered by Offensive Security, well-known in the industry for top-notch training and difficult to pass exams.

What is OSWE

Let’s start with the obvious. The Offensive Security Web Expert (OSWE) certification is given after completing the Advanced Web Applications Exploitation (AWAE) course and succesfully completing the exam.

As the course page states it is designed for experienced penetration testers and web app security people or developers looking to deepen their understanding. In my opinion:

The OSWE is especially useful for security engineers who do a lot of code reviews and code-assisted penetration tests.

To put it another way, if the OSCP is the “pentester entry-level cert” then the OSWE is a solid candidate for being the “security engineer entry-level cert”.

Keeping the term “entry-level” in quotes here since neither security engineering nor penetration testing is typically an entry-level job itself.

During the course, you get access to a huge 412 page lab guide as well as videos and you get a walkthrough of 9 applications, introducing you to different vulnerabilities and debugging methods. These include a wide-variety of languages such as PHP, NodeJS, Python, Java or C#. This approach helps develop a language-agnostic viewpoint where no matter the application, you can have confidence in knowing where to start. In the lab you also have 3 custom applications developed by OffSec waiting for you. These do not have a walkthrough in the lab guide therefore they can be used to practice for the exam in a realistic manner.

You can find numerous pages already to help you prepare. These are the ones I found to be most complete and useful:

At a minimum you should be comfortable in a scripting language (the course uses Python) and the concept of dynamic debugging (for this the course uses VSCode). Prior experience with web application testing is also required but I would not spend too much time learning different languages (unless you have zero experience) as the lab guide provides a good framework for learning.

There is also a curated list of OSWE-like boxes from TJNull you can look at. These can provide further practice against Vulnhub and HackTheBox machines.

Taking the course

Once you decide to take the course I recommend at least 60-days to go through it (as I see on their website this is now the shortest option they offer). The course material can be read / watched relatively quickly but rushing through it defeats the purpose.

I strongly feel that whatever you are learning you need to give it some time for “muscle memory” to build and actually practice it. Put more eloquently:

Passive learning is not a form of practice because although you gain new knowledge, you are not discovering how to apply that knowledge. Active practice, meanwhile, is one of the greatest forms of learning because the mistakes you make while practicing reveal important insights.

— Taken from James Clear’s blog, read on to allow yourself more time to procrastinate doing.

I think this applies to security beautifully as well, you can read about vulnerabilities in the course but that won’t help you apply it. Until you start doing it and learning the insights of when and why to perform a given test you haven’t really mastered anything. This also manifests in security ‘veterans’ looking over your shoulder and telling you there is an issue there because their spidey sense is tingling.

Learning path

Because I have a tendency to put off doing things, my learning method was devised as follows:

  1. Read one chapter / part of the lab guide every day. - This was to combat losing momentum. I stay focused on at least doing something simple and easy, and most of the time it pivots into doing some practical stuff because I get interested in the material.
  2. Watch the videos once for the exercises. - Again this had a lower barrier of entry than actually starting on the practical exercises but I was taking notes and staying in touch with the material.
  3. Do the excersises by myself, check lab guide if stuck. - Finally I jumped to the practical part and went through everything they outlined. I tried to rely on what I have already picked up and doing it without checking the solutions first.
  4. Do the extra miles! - The lab guide includes extra exercises (called extra mile) that do not have a walkthrough or solution. This often ranges from improving a script to be more robust to finding further vulnerabilities in one of the tested applications.

This worked for me but should not be taken as gospel. Many people do just fine reading the lab guide once and then doing a lot of hands-on practice.

But I would stress, don’t be complacent:

Many parts of the lab guide will say after some enumeration we land on X,Y function/class and notice it has a vulnerability. When you are reading along it is easy to say - yes indeed I just have to check those 20 files and I will land on this code, cool let's continue. But I promise you will not feel that way when you are actually left to your own devices.

Therefore, a golden rule is to always perform these steps yourself before moving on. Even better, once you get the hang of identifying the vulnerability that is in the exercise, see if that same process allows you to find other vulnerable code segments. In a few cases I found vulnerabilities for the extra mile challenges just during the initial discovery, which is a good sign that you are on the right track.

Going the extra-extra mile

If you just go through the materials, it is already pretty useful and well-polished, but nothing that you couldn’t find yourself with enough time by just researching various vulnerabilities present on the Internet. What gives the certification its edge is the method it instills in you through the extra mile exercises and through the exam. And I don’t mean the 'try harder' motto. It is the fact that you can take real applications, sometimes with quite large codebases with the intention (and knowledge) that you can and will chain together an authentication bypass into an RCE.

If you can keep that mentality going into your regular work or bug hunting then the training was already worth it. For every new programming language in the lab guide I would go on GitHub and start looking for open-source applications to test.

For example looking at PHP targets, I searched for the language then looked for something interesting for example a finance application ordered by most stars. You can take these for a spin locally and try to use the same enumeration techniques and methods as you did during the course.

Passing the exam

The exam itself is 48-hours of pure Offensive Security torture fun. You are given 2 machines and in both cases you get access to a whitebox instance where you can look at and debug the code in any way you want. The final exploits you put together will have to successfully run against the blackbox counterparts. These are the same machines and applications but with different credentials and flags.

I cannot give out details on the exam itself but in my experience as long as you follow the materials and understand what to look for and how - it is not an impossible challenge.

I started the exam at 2PM on a crisp Sunday afternoon. I found the code execution after an hour but still needed to “get to it”. In a few more hours I had a working manual exploitation of both the authentication bypass and RCE but I still had to extract some values manually to achieve this. The next couple hours were dedicated to understanding my limitations and overcoming them to remove the need to ‘know’ things beforehand. Around midnight I managed to put it all together and went to sleep knowing that one machine was down.

The next morning I started early - around 7AM - with the second machine. I once again identified what I needed to achieve in a few hours and was able to manually trigger it. Putting together the script to automate it took another couple hours because I was already fairly comfortable with using Python and had my toolkit ready. During this time I tried to go step-by-step and always verify that my assumptions were correct before implementing the next step of the chain. By the time I reached 24 hours in the exam, I had both scripts tested and working against both exam machines.

All in all, I have to say that it was a very pleasant experience for me, and I was quite excited to get started with the exam. I felt like I prepared as well as I could and instead of feeling stressed I was above all really ecstatic that I am getting my hands on two more machines I can break. I can say that I got lucky and got machines that matched with my strongpoints and that allowed me to finish quite early but I would like to think that the takeaway here is preparation and opportunity made that luck possible.

Tips

These are tried and tested tips to help with the exam:

  • Prepare your script toolkit - While you are doing the exercises, pay attention to producing reusable code snippets and categorize them. There is a high chance you will be able to repurpose something from it into your final exam script and that can save precious hours. So for example having a script that sends in a JSON POST request and can also use a proxy means you can immediately start working on the injection or whatever and verify what happens in Burp instead of writing the scaffolding.
  • Use Rubber Duck debugging - If you feel lost, try to explain to an imaginary person how the application works. Go step by step as you go through the flows and maybe something pops out that you missed before. Also don’t forget to explain to the person monitoring your exam that you are in fact just going crazy and not discussing the exam with someone else in the room.
  • Don’t be afraid to take things apart - You have a whitebox machine, use it. For the first application I logged in to the database to look at the schema and tables before I even loaded the website. Feel free to flip roles into admin if you need it, whatever it takes to get you to test some theories. This can help when identifying the attack surface, just don’t forget to reset everything after.
  • Take regular breaks - During the exam I sometimes had to force myself to step away from the computer, especially when I felt close to the solution. I had this urge to chip away at it until I get a breakthrough. Tenacity is certainly good, but there comes a point when it becomes a disadvantage. You can feel this when you are spinning your wheels, revisiting the same ideas that already failed, again and again, thinking surely this IS the right solution. During these breaks however, I often got new ideas that allowed me to look at the problem from a new angle. Some of them did not pan out, but sometimes it allowed me to figure out the next step after I returned with a fresh pair of eyes.

After the dust settles

This was my favourite exam so far and especially after the 2020 course update I think OffSec is providing a lot of value for the price and the exam was the right balance of tough but fair. I also much prefer the 48-hour format to the 24-hour race that is the OSCP. I highly recommend the course to those looking to sharpen their web application testing skills.

It is difficult to offer alternatives or next steps as OSWE is at the moment a unicorn with whitebox testing. There is the eLearnSecurity eWPTx for advanced web application testing techniques but I think it falls short of what OSWE provides.

After finishing the exam (and getting some well-deserved rest) I think the best thing to do is to start practicing and training the muscles you built against some real applications. Don’t let your knowledge fade, do some bug bounties or help out open source projects.