Students who are familiar with the PWK/OSCP understand that the field of penetration testing is broad, and at times, overwhelming because there is a lot to learn. Does the AWAE/OSWE come across as significantly less broad?
Well, not exactly, because web applications are extremely diverse. Let us take the white box/black box approach to examine web applications.
Many penetration testers are familiar with the black-box approach. Many bug bounty programmes, HackTheBox, and boot2root VMs operate on a black box principle, but the AWAE/OSWE attempts to look at penetration testing from the white box angle. Did they succeed?
An Overview of AWAE and Preparation Required
The AWAE incorporates different programming languages, databases and web application vulnerabilities. The web vulnerability classes include blind SQL injections, cross-site scripting and deserialization. Throughout the course, scripting skills are emphasised. Exploits aren’t good enough; we sometimes try harder by automating them. Be comfortable in a scripting language of your choice. Python is excellent since the course is in Python, but it is alright to use another scripting language of your choice.
Since this course is a white box penetration testing course, 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 (dnSpy is awesome; even if you don’t plan to take the AWAE, take some time to reverse engineer a .NET application). A white box penetration tester must be familiar with walking through code execution flows with the help of a debugger. The AWAE will be about 50% of the time on a debugger, about 20% of the time spent scripting, and if you try harder, 30% on the extra miles and other research.
It is unlikely that the penetration tester is familiar with every language written because of the diversity of programming languages for web applications. The AWAE covers four web languages: NodeJS, Java, PHP and .NET (more details on this in the AWAE course contents page). The AWAE cannot promise Jedi mastery of any language, but be prepared to read code and do research in order to understand code execution flow. The AWAE will introduce languages and simultaneously throw the student into the deep end of the code base pool.
I went into the AWAE mentally prepared to spend long hours tiring myself on code. It happened. Unlike the PWK, where a student could rotate through objectives, there is little benefit doing so on the AWAE because each topic requires the student to do some in-depth research; flitting from module to module is counter-productive to such deep dives in my opinion.
Note: The AWAE is NOT a fuzzing course, or a WAF bypass course.
Specifics that you should have, before coming for AWAE:
- Competency in scripting. Python preferred, but any language will do.
- Some background in pentesting. You know where to obtain reverse shell payloads, and already do black box testing. If you already have the OSCP, you should be fine.
- Familiarity with web application languages. You don’t need to be an expert in any, but you cannot freak out with codebases of tens of thousands of lines.
- Familiarity with various web application vulnerabilities. You know what
<script>alert("Try Harder!")</script>is, and you know what you can continue to do if something likehttp://192.168.72.100:8080/post.php?id='results in an error in a MySQL database. Merely knowing how to usesqlmapdoes not count as familiarity. If you want a far more extensive guide, feel free to look at wetw0rk. - Know how to read stuff like
/[a-zA-Z0-9_\-]{100,200}/. (Hint: regex.) Regex is a life-saver for searching. - Knowledge of Burp Suite. The free version suffices.
- Weekends to try harder. This is non-negotiable unless you are already excellent in all of these, and find the contents page of AWAE easy.
- The curiosity to read technical material and understand it. E.g.: Black Hat briefing, or a manual on magic tricks (sorry, I meant PHP type juggling).
- (Optional) If you are familiar with HackTheBox, you can read this review, where 21y4d has kindly written an extensive post on AWAE/OSWE.
Moments During AWAE
The First Taste of “Hell”: This started with Atmail. The material sounded a little too easy and “black magic” to me initially. (Yes, there was XSS, fantastic, but how on earth did they see the vulnerability?) However, the XSS to RCE chain was not that difficult to understand in the guide. And then, the extra mile goes: ok, you learnt how to compromise Atmail through Method A, right? We also briefly mentioned Method B in the video. Please try Method B. Except, there was no mention about Method B at all!! This would be the tone that would be set in some of the AWAE modules; the material itself seems understandable, until you’re left to your own devices. These are “true tests” of material mastery. More on these “extra miles” in a later bullet point.
The Silliness: My initial inadequacies meant that I sought advice from some learned friends. Among some of the skills I learnt included:
- Realising Telegram allowed for neat presentation of code. Far easier to read than to try to wade through text and code. Why did I not discover this earlier?
- Dynamically debugging Javascript using vscode, even though it did not exactly work as it should on the extra mile (if you’re on the AWAE and know which extra mile this refers to, this shall be left as an exercise.)
- Getting “DotNetNuked”. I personally found the .NET deserialization module the most challenging because deserialization flaws were relatively more exotic to me, and because I had difficulty getting up to speed on understanding .NET. Frequent head-banging because I managed to get working exploits, but just could not initially understand why they work and how they really work.
The Fulfilment: In PWK, there was the “big four”. In AWAE, there’re some extra miles which will burn 5 days of precious time, opposed to 5 minutes (yes, there’s an extra mile that takes about 5 minutes to complete). Despite the large variances in extra miles, I recommend doing them. Some extra miles encourage the student to perform self-initiated research, often leading into new peripheral learning journeys. The web application world is unfortunately both wide and deep. Every opportunity to understanding something extra in web applications is useful for the web application pentester. Extra miles can easily burn weekends if left unchecked.
The Joy: Joy is when I have, through AWAE, found like-minded information security enthusiasts. One is a Javascript expert. Another does hardcore security research for a living. Another one is a zero-day hunter for web applications. Joy is when I discover I know little, and that there is so much to learn in web application penetration testing… way beyond XSS, IDOR and CSRF. Forming a tight-knit community of capable people is extremely important, not just for the course itself. Who would expect a course, not a networking event, to bring together lots of different like-minded infosec professionals, be exposed to the community in many different ways and on top of it all, interact with experts. Somehow, once one moves into a more hardcore course, some will fall out, leaving the persistent behind. Special thanks to my buddies in Mystiko, NetSec Focus and various Telegram groups.
The Shelling: Shells, shells and more shells everywhere! In the ManageEngine module, I was brought through the sheer number of ways to obtain a shell from SQL Injection. The only phrase I could come up with after that module was “mind-blown from all that shelling”. At some point I had lingering thoughts on just how many system administrators had any clue on the powers their database contained. My suspicions were confirmed when some database administrators replied, “LOID? What large object? Definitely not my salary!” Not so good for the database administrator, but fantastic for the penetration tester. (P.S. Oh gosh, I hate JD-GUI… the searching features on JD-GUI are horrendous.)
The Frustration: There were two aspects in the AWAE that were somewhat frustrating.
- The vulnerability discovery process: Some vulnerabilities were straightforward to discover (e.g. search for unsafe functions and follow the code execution flow). This is not the case for others, especially when the application contains a large code base. Some foresight is required, and foresight requires experience. There’s no shortcut to “teach” vulnerability discovery because it can be extremely subtle; do more code review to get better at vulnerability discovery.
- Probably the most frustrating aspect when debugging a web application is the target machine running out of memory. Once it happens, simply closing other processes and restarting them does not help. New files will simply no longer be de-compiled, forcing me to revert the machine, or at least, restart the debugger and losing my saved work.
Exam-Time: The OSWE
No spoilers, but some general tips.
- It’s a marathon, not a sprint. One could get by OSCP without sleep, but don’t try this on the OSWE exam. Have a rough plan, remember to take breaks, eat and sleep.
- Be familiar with all methods the course uses to debug web applications, or parts of web applications, because you’ll be using these methods. These are all available in your lab guide.
- Learn how to search efficiently. That means, know how to grep, know how to use Notepad++’s search, know the strengths and limitations of search features in the debuggers. Take the time during the labs to experiment with searching through the codebase efficiently.
- Have fun!
Others have also collated exam prep material, such as deletehead (methodology) and Joshua (how to build your local labs, for those that you can).
I Tried Harder, Now What?
I started my cybersecurity adventure with web applications, and I thought obtaining the OSWE was a mark of achievement that, come what may, I would at least be proficient in web application penetration testing. However, at this point, I am thinking of different options. Venture into mobile pentesting? Build up exploit development capability? Go attend mr_me’s course? Do some network penetration testing such as active directory attacks? Or maybe start a side-project, customise a PHP application to deliberately introduce vulnerabilities and make a vulnerable Vulnhub box? There are too many ideas to think of. I will be thankful if you can give me some.
Should I Take This Course?
If you are already a penetration tester, definitely! But be prepared to stare deeply into code, spend weekends trying to understand the innards of web applications.
If you are a security researcher, why are you not already taking this course?
For all others, be warned this is not an entry level course. But if you are willing to try harder, what’s stopping you?
Bonus: Two Memes
