Recently, I finished the Offensive Security WEB-300 course and successfully passed OSWE certification. The goal of this article is to share the methodology I’m using in white box engagements and which helped me in 48h long OSWE exam.
Before diving into the methodology, it’s worth spearing some words about the course and exam itself. The Offensive Security WEB-300 course is all about white box web testing, so application source code is available. It means exposure to a lot of code in five different languages: Java, JavaScript, C#, Python, PHP. The full course syllabus can be found here.
In my opinion, you have to obtain four types of skills to become OSWE:
Resources that I used for learning about 1 and 2 are linked at the end of this article.
This step is all about a clicking-through application from a user perspective with Burp proxy (or similar tool) turned on. Note all of the application functionalities, technology, how it handles authentication, authorization, is there anything odd that triggers your pentesting instinct? It’s worth to pay attention to the structure of requests, cookies, local storage. Writiting down observation from this step is essential.
It’s time to make use of your notes from the reconnaissance phase. List all of the application functionalities and map this to known vulnerabilities. What can go wrong if the attacker misuses the presented functionality? There are threat modeling lessons that I find very useful, it’s from Jakub Kaluzny from SecuRing - you can watch it here.
In this step, you should prepare a code base for tests. This depends on the type of application that you are auditing, but in general:
Before starting to look for vulnerabilities, it’s worth to know how the application is structured and understand used coding patterns. It can become easier if the application is based on some framework or uses well-known architecture like MVP. All exceptions from standards like places where database query is done without ORM or parts of the application that use custom code instead of framework capabilities, could be helpful in vulnerability search. Using debugger can make this step easier.
In this phase I’m trying to answer the following questions:
Warning. You can’t use automatic scanners in OSWE exam but it becomes really handy in real-life engagements, to localize low-hanging fruits. I have a local lab with three tools:
and real fun starts now. To summarize, following data is gathered from previous enumeration steps:
The OffSec exam and CTF’s are different from the real-life scenario. Usually, in real engagement, you should stick to penetration testing methodologies like OWASP Testing Guide to make sure your tests for all well-known vulnerabilities and deliver a comprehensive report.
In CTF the goal is usually to get full control over the application and underlying system. Firstly, look for some kind of authentication bypass as in general it’s easier to find more serious vulnerabilities like RCE as admin user than as non-logged in. When looking for authentication bypass, focus on all application functionalities related to login and registering user, such as:
Having access to the application as a privileged user, you can utilize all of its functionalities to get RCE or find flags. Things like insecure deserialization flaws, unrestricted file upload vulnerabilities, or SQL injections could be an important ingredient in your RCE kill chain recipe.
Have you find is useful? Do you have other white box testing flow? Please find me @twitter and discuss.
Happy hacking!