Last week I passed the OffSec Web Expert (OSWE) exam. This was a long time coming as I started studying for it at the end of 2020, but got side tracked for OSEP (review here), OSDA (review here), CRTO (review here), and then OSED (review here). As expected with an OffSec 300-level course, the test was a 48-hour practical exam that challenged web application source code review, vulnerability analysis, and exploitation. Bottom line: This course was a ton of fun, and it is a great foray into white-box web application testing and web vulnerability exploitation.
I would recommend this course to anyone with a strong desire to broaden their technical acumen in application security. This can include penetration testers (web app and even infrastructure), DevSecOps practitioners, and even red teamers who want to dive into the application side of things. While the course is primarily focused on white box code review, there is significant overlap with black box web app pentesting, and practitioners who rarely obtain source code will benefit from the skills taught in the course.
WEB-300 focuses on vulnerabilities that lead to 1) authentication bypass and 2) code execution. These vulnerabilities cover SQL injection, cross-site scripting (XSS), code injection, server-side request forgery (SSRF) and server-side template injection (SSTI), deserialization, and XML external entity vulnerabilities. In the exam, students are challenged to chain together vulnerabilities to obtain access (or higher/elevated access) to the application and then from an authenticated/admin perspective, achieve remote code execution. All activities are required to be scripted into a single exploit for that system.
I would give this course a 9/10 rating. Some people did not like how it was so source code/white-box focused, but from my perspective that was clearly communicated and based on the understanding that it is NOT a black box course, I would give it a 9/10.
Prerequisites
At a bare minimum, I would recommend the OSCP as a pre-requisite, but candidates would certainly benefit from a black box WAPT course such as OSWA (WEB-200) or Burp Suite Certified Practitioner (BSCP). While I have not done either of those courses, I have heard good things about them. I walked into WEB-300 with a lot of black and white box WAPT experience from my consulting work, but I would not consider myself a web security expert.
Course Content
Normally, I would break the course content down into the sequential sections; however, I will break down the content by skills imparted and vulnerabilities covered.
- Recovering source code: For web apps that are compiled such as Java and C# .NET, the course covered decompilation (using JD-GUI and DNspy, respectively).
- Debugging and remote debugging: This was really helpful, although I doubt many testers will be able to live debug a web app during a pentest (at least, I haven’t in my white box WAPTs!). The course covered remote debugging in several languages, and also debug statements (app logs, database logs, etc.). I found this to be crucial for the exam. When I initially failed the test, I realized I spent a lot of time trying to get the remote debugging to work because I didn’t really practice it initially. Being familiar with the process makes it more natural to set it up during the exam and save time/effort trying to follow code without a debugger.
- Source code analysis: A lot of the course revolved around white box source code analysis. While there were a few key sections, I didn’t think that OffSec did a very good job of helping students establish a methodology. However, that’s par for the course for OffSec. Part of the challenge is developing that on your own (for better or for worse).
- SQL injection: As you can imagine, the course heavily covered more advanced SQL injection techniques. In some cases, it was SQLi to RCE. In other cases, more restrictive SQLi scenarios were leveraged for auth bypass. Pay attention to the capabilities of the various DBMS’s and the relevant attack scenarios for each.
- Command injection: A number of different command injections were discussed, such as JavaScript “eval()”. Definitely some great content here including filter bypasses.
- Cross-site scripting: I really enjoyed the more advanced XSS and similar client-side attacks that were taught. There were situations where automated “users” would simulate a victim so you could practice the full attack chain.
- Server-side template injection: Honestly, I have never exploited this one in the field, so this one was very helpful for me to practice and see. It took me a while to actually “get” it — particularly what scenarios trigger the vulnerability.
- Server-side request forgery: This was covered in an “extra” recently-added module. I think it is fantastic that they added it and the example used was really enjoyable to walk through. It is a highly relevant vulnerability in 2024.
- Insecure deserialization: This is some of the primo content in the course. If you have never understood why deserialization vulnerabilities are so dangerous, and the situations where they are (or are not!) exploitable, you will LOVE this section. I do not have a development background, so this was extremely helpful for me in understanding not only the overall concept, but also some of the more foundational development concepts. Out of curiosity and to deepen my own understanding, I did some research into the Java “readObject()” deserialization vulnerability to solidify my understanding.
- Weak authentication: A number of authentication bypass methods were covered, and tested in the labs. One thing I loved about the course is that it emphasizes chaining non-RCE vulnerabilities together to finally obtain code execution, starting with authentication attacks.
The Challenge Labs
The labs were really enjoyable; however, I wish they had a few extra machines to practice on. There were two white box machines with full source code available and one black box machine. While there were only three challenge labs, each system had multiple vulnerabilities to exploit for a complete attack chain from zero access to a remote shell.
I highly recommend completing all three machines and scripting out the exploit chain for each one so that it is fully automated. Keep in mind that there may be more than one route to take to complete the challenge!
While you are working through the labs, I recommend getting familiar with a scripting language (most favor Python3) to interact with web applications, manage sessions and authentication, and automate the web exploits. Make it a goal to be able to set up a listener and then run “python3 exploit_LABX.py” to achieve a shell. Consider crafting an exploit template with boilerplate code that you can reuse for the exam.
A quick tip: build the capability to easily toggle a proxy on and off so you can view the traffic in Burp when your script makes a request. This is extremely helpful when debugging your exploit code (e.g., when you’re submitting complicated web forms). It is one thing to manually exploit a vulnerability in Burp. It’s another to have it fully automated in your non-interactive exploit code.
Preparation & The Exam
The exam was difficult…I did not pass on the first try! I had tried it in the past before this most recent go at it since I had started in 2020. But at this point I had a lot more experience. I started studying (again) for it in January after I completed the OSED late last year. I went over some modules such as remote debugging, decompiling, etc. and completed all the challenge labs including the black box machine. You will need to be familiar with all the vulnerabilities taught in the course as any of them (in any combination…) may be present on the exam machines.
If you go through all the content and are able to complete the challenge labs, you likely will have what you need. If you would like additional practice, consider attacking these systems on HackTheBox.
I cannot give too much away about the exam, but what I will say is 1) REPORT AS YOU GO and 2) remember that it takes a lot of time to script your exploits.
As for reporting as you go, it is critical that you document along the way. Make sure (before your exam ends) you have submitted your flags, have all the appropriate documentation, and have reviewed the requirements in the OSWE exam guide. I tried something different this time: I did all my reporting in my Obsidian markdown notes and exported them as PDFs, then combined them for the final report. It worked really well, and it was a huge relief to not have to deal with MS Word!! I just used the docx template they provide for the cover page and first page and exported it as a PDF, but for the actual machine write-ups, I copied the section headers over to Obsidian and filled them in. Then, I exported the two documents (one for each machine) and combined them with the cover page. I wish I had done that many exams ago! I have wasted so much time copying from my notes to the MS Word doc…
The second tip is to remember that it takes time to script your exploits. Even though I had an exploit skeleton, the machines take multiple steps to exploit, so you will be writing a lot of code (expect ~100–250 lines per machine). While identifying and exploiting the vulnerabilities may be the most difficult part, scripting the exploits can be surprisingly stressful and time consuming. Make sure you get lots of practice managing sessions and combining each stage of the attack. The best practice is to script out the challenge labs. While it may seem tedious or unnecessary, it will pay off!
Conclusion
Overall, this was another great 300-level course from OffSec. I understand why it’s the more popular advanced course! I will simply copy what I said for the OSED: While so many are giving them flack these days, I found this course to be enjoyable, tough (but fair), and in-depth. Good luck!
