Background
I am currently a final year University student majoring in Information Security at the Singapore Institute of Technology (SIT). Previously, I graduated from Singapore Polytechnic with a Diploma in Information Security Management. In 2021, I achieved my OSCP (Offensive Security Certified Professional) and set my eyes on my next goal of earning an OSCE3 (Offensive Security Certified Expert 3). However, commitments such as my internship and having to complete my final year project forced me to put my plans to attain my OSCE3 on hold. This year, I managed to make time to obtain my OSWE (Offensive Security Web Expert) certification, which was crucial for my internship as a penetration tester.
What is OSWE?
The OSWE is one of three certifications needed from Offensive Security to achieve OSCE3 — the other two being OSEP (Offensive Security Experienced Pentester) and OSED (Offensive Security Exploit Developer).
Like OSCP, the OSWE exam is a proctored exam where you are given access to a VPN with vulnerable web applications. You are tasked to perform deep analysis on the given web application with the goal of identifying, combining, exploiting, and chaining logical vulnerabilities to create complex attacks.
Is OSCP Required?
“Is OSCP required to take the OSWE examination?” This was a common question I received after obtaining my OSWE certification. My answer is always the same — Definitely not. However, having it will definitely help you understand certain concepts present in the OSWE examination/having it will provide you with a definite boost/having it will etc. you get it. During my preparation for the OSCP, I learned a lot from my training/practices in the HackTheBox labs and the PWK course.
The main reason for this is due to the fundamental difference between the two certifications. OSCP employs a black-box approach whereas OSWE employs a white-box approach.
Black-Box vs White-Box (OSCP vs OSWE)
The OSCP course takes a black-box approach, where you are not given prior knowledge regarding the services that the OSCP lab machines are running. You are then taught processes such as scanning, enumerating, and exploiting machines.
On the other hand, the OSWE course focuses on the white-box approach. Within the OSWE labs, information such as that the source code and that the vulnerable service is a web application are provided.
Furthermore, OSWE differs from OSCP as it requires you to craft your own exploit by chaining logical vulnerabilities. This is typically done in python (my preferred language). The general strategy would thus be to exploit logical vulnerabilities in authentication then proceed to achieve a shell.
The following course materials will walk you through the processes and methodologies used to identify vulnerabilities across various web applications and how to exploit them.
If OSCP is a mile wide and one inch deep, then OSWE is a mile deep and one inch wide.
OSWE Review
The OSWE incorporates different programming languages, databases, and web application vulnerabilities; which includes blind SQL injections, cross-site scripting, and deserialization. Scripting skills are emphasised throughout the course. It is highly advised to be comfortable in a scripting language of your choice. I would personally recommend Python (as the course materials use Python as their scripting language) but any other scripting language is fine as well.
Since this course focuses on white-box approach, it introduces different methods of debugging such as simply writing “console.log()” statements to print output in JavaScript and dynamic debugging in .NET with dnSpy. During the OSWE course, I personally spent roughly 50% of the time on a debugger, 20% of the time spent scripting, and the remaining 30% on extra miles and other research. Therefore, it is imperative that one has to be familiar with walking through code execution flows with the help of a debugger.
I went into the OWSE mentally prepared to spend long hours tiring myself on code — which happened. Unlike the PWK, where a student could rotate through objectives, this brings little benefit regarding the OSWE as each topic requires in-depth research. Thus, flitting from module to module could be counter-productive as compared to deep dives.
Note: The OSWE is NOT a fuzzing course, nor a WAF bypass course.
Recommended Pre-Requisites
- Competent in scripting, any language would suffice but Python is preferred.
- As mentioned earlier, background in OSCP is unnecessary but nonetheless useful.
- Familiarity with web application languages — while not to the degree of being an expert, you should not be fazed by codebases with tens of thousands of lines.
- Knowledge of Burp Suite would be ideal.
What To Do During Lab Time
- Unlike OSCP, the course PDF and the videos go hand-in-hand. Skipping either one might cause you to miss important details.
- Do all the exercises. Especially the extra miles! Do all the exercises that involve automation! Try to make your scripts modular so that they can be re-used in the future if needed.
- If stuck, do not hesitate to get help from the Offensive Security forum or the Offensive Security Discord Server.
- Solve the extra lab machines. You will be given extra lab machines with no guide or instructions on how to solve them. Some machines have multiple possible solutions, and if time permits you can practise solving them through different means.
- Create a checklist of all the vulnerabilities that you were taught during the course. Have notes on each vulnerability and how to find them. This will aid you greatly during the exam as you will be able to work through the process of elimination. The course materials are sufficient for passing the exam. Take note of logical vulnerabilities and their locations that allow you to exploit the application. Here is an example I took from a GitHub page:
Difficulties Encountered
Employing the Same Style as OSCP to Study OSWE
During OSCP, I rarely followed the PDF guides as I had prior experience from Hack The Box and multiple VulnHub boxes. However, this approach introduced a weakness as I had no idea how or where the vulnerabilities were found. Therefore, I had to change my approach by strictly following each sentence of the PDF and video. The PDF would provide a simple statement such as “line xxx in xxxx.js is vulnerable” as well as “how” they found the vulnerability. However, I decided to establish my own method in the end as their method differed greatly from my own thought process
Locating the Vulnerability in the Application
Code tracing is not an easy task. However, it is vital to master code tracing to understand the application and spot the vulnerability.
Understanding the Vulnerability of the Application
With some basic knowledge from OSCP, it is easy to understand the vulnerability itself such as SQLi, CSRF, XSS, XEE, etc. However, they are NOT the vulnerability of the application itself. The vulnerabilities are not as clear cut as in OSCP. Having a full understanding of both application logic and vulnerabilities are necessary to obtain authentication bypass and RCE.
The main crux of this course is that you will understand why the exploit works or does not work. Just like real life, both the lab and exam will have protection mechanisms. However, even though protections are in place, it does not mean that these protections were implemented properly. There will typically be some common functions/libraries called to do sanitization. Furthermore, if you do not understand how or why your exploit works, it is impossible to script an automated script.
Coding and Scripting
For OSWE, the exam requires you to chain vulnerabilities via an exploit script. Additionally, there is no way to do this manually in some attacks. Hence, practicing scripting and coding is a must to pass the exam.
Understanding Web Engine and Frameworks
OSWE covers many common coding engines/frameworks/databases. It requires a basic understanding of how the application route is done. Also, knowledge regarding using a debugger is critical in the course and exam.
OSWE Exam
The exam will provide you with 47 hours and 45 minutes to work through your target machines. During this time, you have full access to the application’s source code. Be mentally prepared for a huge amount of source code to review and manage your time well. Like OSCP, you will have another 24 hours to submit your exam report.
The exam machines come in a group of two: one is a “development” machine that grants you full access via RDP, and the other is a “production” machine which you have no access to. Your attack chain will be created and tested on the development machine and performed afterwards against the production machine, which holds the relevant flags.
The development machines have a basic setup of everything you need to start your exploit development with. Additionally, you are not allowed to remotely mount or copy any of the application’s source code to your local machine. You must do this with the tools provided.
The goal of the exam is to exploit these independent production machines using a single exploit script with any scripting language of your choice. This means your script must chain the vulnerabilities found where the execution of the script should obtain a shell from the machine. If your script fails to obtain a shell for the machine, it will be counted as a failure (I am unsure if partial points will be given). You need a minimum of 85 out of 100 points to pass the exam.
OSWE Exam Methodology and Guidelines
It is important to have a clear understanding regarding the course materials and methodology to reach for once you are presented with an objective. As everyone has different ideas and preferences, this is one of the things you are not actually taught during the course. Hence, there is no one-size-fits-all solution and you should build your own personal approach on how to enumerate a web application.
Here is a broad overview of my approach for assessing a web application:
- 1. Look at the targets from a black-box approach. Take your time to familiarise yourself with the objectives.
- Start poking around the website and have Burp start recording its traffic. Check both public and authenticated web pages.
- Take note of important functionalities such as authentication endpoints (login, password reset), admin area, file upload, forms, restricted information, etc.
- If you find something interesting, follow the code flow.
- Review the application’s source code to find how routes are handled. Find responsible code for the functionalities identified earlier while cross referencing against the additional details that your preliminary discovery might have missed.
- Once that is done, search for programming-language specific issues. I have made notes on the possible vulnerabilities you might encounter besides the ones already described above. If stuck, take a break and re-check what you are doing.
- Take breaks and sleep properly.
Personally, I prioritise unauthenticated functionalities such as authentication related mechanisms (eg. Password reset) and session management code. Manual analysis is required to properly understand the logical flow of the function.
Afterwards, I will then target injection vulnerabilities. Use RegEx to search for common SQL keywords.
Run programs manually to view the console log.
Tips and Checklists
Here, I will be providing some final tips that I felt were useful to during my course.
There will be a lot of automated exploits using Python (my preferred choice) scripting to chain logical vulnerabilities together and I prefer Python as my scripting language. I chose Python as my scripting language because it has useful libraries such as requests to aid in chaining the vulnerabilities found. Since this is a web course, you will need a Python module for sending web requests. As such, I suggest getting used to the requests module.
An efficient way to make use of your lab time would be to read a chapter, watch its corresponding videos, and then solve the chapter’s exercises. While doing this, do not forget to note down important information being taught. I personally used OneNote for notetaking. Once you have detailed notes of what you have learned in each chapter, I recommend proceeding with the extra miles exercises. This is probably the best way to push yourself further and it provides a taste of the challenges that the OSWE exam will throw your way. The Offsec forums are helpful here if you get stuck. I would recommend not reading the forum unless necessary as reading the posts usually provides you with sufficient clues to figure out whether you’re heading in the right direction.
Save Your Course Scripts and Reuse Them During the Exam
Even though the exercise scripts mostly build on each other, I would recommend making separate script files for them to document your progress. This saved me a ton of time on the exam too, as I could just reuse snippets of my past scripts.
Get Comfortable with Debugging, Databases, and Reading Logs.
Reading the code is one thing, but seeing how it operates is another. I find that setting breakpoints, stepping through the code’s execution, and seeing how variable values change with a debugger are invaluable when attempting to break down complex code, especially when it comes to stuff like encryption functions. I would advise getting used to Visual Studio Code for debugging, mainly because it is the primary code editor that will be used throughout the course and in the exam (during my time).
Additionally, make sure you understand how to use decompiled code and attach it to a running Java or .NET application to debug it. You should also understand how to use logs to your advantage, especially database logging. This will be covered in depth during the course, and it is the key to successfully figuring out a payload for a blind SQL injection vulnerability for example. Typically, I use the database’s command line tool to test out my queries before creating my payload. I like to have a working query before considering filtered characters or any other transformations that might introduce unexpected errors into the mix.
It’s a Marathon, Not a Sprint.
This point has been mentioned on every other post about Offsec exams, but it deserves reiterating. I would strongly advise against attacking this one full-on for two days straight. If you are anything like me, you will fixate on some rabbit hole, go nuts, exhaust yourself, and start losing your mind. Take breaks, get enough sleep, eat meals, and clear your head out from time to time. And don’t forget toilet breaks!
Conclusion
Overall, the materials are well done, and they work great. As usual with Offensive Security courses, you should do some research on the topics covered in the course to get the most out of it.
In general, I did not really do a lot of extracurricular reading. I read the course PDF, watched all the videos, and did all the “Extra Mile” challenges, which proved to be sufficient for me. However, you might have a different experience as I had OSCP and some prior experience with web pentesting. Once again, if it has not emphasized enough through this post — Do all the “Extra Mile” challenges.
Ultimately, my favourite part of the course was gaining the ability to understand how impactful finding several seemingly unimportant vulnerabilities and chaining them together to obtain remote code execution can be.
I hope this gave you some insights on what to expect from OSWE. All the best!
