One year after earning the OSCP certification, I started thinking about my next challenge. While OSCP is a great entry level pentester certification from which I gained tones of skills and tactics, I wanted to get a certification more tailored to my experience, interests and day job (in Application Security). As the OSWE certification become available online, I though it would be the perfectly fit.

I recently had my first attempt at the OSWE certification and nailed it, so here are some of my notes.

What is AWAE?

The AWAE (Advanced Web Attacks And Exploitation) course teaches you how to find vulnerabilities in complex web-applications using a white-box approach. Once you finish the course, you can take the exam to get the OSWE certification. OSWE stands for Offensive Security Web Expert.

A white-box approach means that you either have access to the actual source code or to a decompiled version of it. This is very different from OSCP which involves using a black-box approach, where the attacker has limited knowledge on the systems and internals of the target. OSCP also covers a broader range of security issues, while AWAE deep dives into web application specific things.

As observed in the course syllabus, the material is structured in several chapters, almost everyone being a case study for a certain application. In each use case you will learn how to find, and exploit and chain together several vulnerabilities in order to obtain Remote Code Execution.

White-box vs black-box

White-box approach allows for more complete and thorough test of the application. It should ideally reach almost all areas of the application, including things like architecture design and even touch on secure coding practices. The problem with a white-box approach is that it takes a considerable amount of effort to conduct.

The black-box approach is done from the perspective of an outsider so it simulates a more realistic attack scenario. The major downside of this type of testing is that it’s usually time-boxed so it may not provide an accurate overview of the state of security (usually low hanging fruit are prioritised).

Ideally, one would use mix of both techniques to obtain the best results (grey-box).

Is OSCP a prerequisite for AWAE?

Definitely not. But if you have it, it does help. I learned a lot during my preparation for the OSCP (mostly done in the HackTheBox labs) and the PWK course. Here are just a few tips:

  • Linux Command Line kung-fu: this will help in AWAE on the Linux machines where you don’t have a nice GUI to use. Basic stuff like find, grep, cut, etc.
  • Tools: all types of reverse shells, serialisation tools, etc: having them around and knowing what they do will spare you some time during AWAE.
  • Python or a different scripting language: you will have to write exploits in AWAE using your preferred language. I was already familiar with python from day to day use and OSCP, so it was the obvious choice for me.

So how should I prepare for AWAE?

I think that it heavily depends on the experience you have. Myself, I have worked for quite a few years as a developer and a few later as a Security Engineer. Reading and understanding code as part of code reviews and security audits are things I was already doing and I’m very well accustomed to.

Since reading code is the main thing you’ll be doing during the AWAE course and exam, should be prepared and comfortable because you’ll do it a lot. This is mostly what you’ll be doing:

  1. Understand how a web application works: asset discovery, routes, endpoints and functionalities.
  2. Follow how user data reaches from endpoint to certain parts of code.
  3. Check if proper input validation and output encoding is performed.

Preparation Tips

To achieve all those three things you will use a variety of skills and techniques. If you don’t have all of them, do not worry as you will learn during the course. You will need to deep dive yourself, but the information is out there. Here are some tips:

  • Be comfortable with code debuggers: depending or your experience, you’ll probably spend the better time of the course debugging code, so make sure you know how to setup the debugger, use brake-points, etc. Adding print() or console.log() statement is not the best way to debug an application. Note that the AWAE course contains apps built in PHP, Java, .NET and Javascript, so you need to be able to handle all of them.
  • Be comfortable with large code bases: web-apps have lots of code, so be ready to comb through tens of thousand of lines of code. Some people could get analysis paralysis. Inevitably, you’ll spend time on rabbit holes. For the exam, you need to be discipled and limit allocated time to analysing individual parts of the application.

Tool familiarity plays a huge role here: be comfortable with your tools. For example it’s trivial to search for a method’s code references in Visual Studio or Jadx or DNSpy (you will deal with both of these last two). Just click a menu item or something. However in the exam, that won’t alway be possible. You have the decompilers, but no IDEs so you will either have to do your searches with Notepad++ or by grep’ing text via command line. In both cases you should know some basic RegEx to ease analysis.

  • Be able to understand and write code in some scripting language: python is used in crafting exploits in the course and you’ll probably end up using it later also.
  • Understand common web vulnerabilities. OWASP Top 10 pretty much covers it all.
  • XSS: how to trigger and what you can do with them
  • SQLi: understand how to recognise and exploit (manually of course, no sqlmap).
  • Deserialisation attacks: Java and .NET. I was already familiarised with Java deserialisation attacks but I gained great knowledge from the course on .NET attacks.
  • Take a look at the course syllabus: . Research the things you never heard of.

How much lab time should I get?

Again, it depends on your experience. If you feel you are comfortable with the above and you have the time to go though the materials, you’re probably fine with 1 month of lab time. Note that some extra miles can take a few days to resolve. If your job or other obligations don’t allow you to put in the time, go the safe way and get more lab time.

If you didn’t have time to prepare or you aren’t familiar with most of the above things, you should also go for more lab time.

What about the OSWE Exam?

  • The exam is a 48 hour marathon. And 24h more for you to write and deliver your report.
  • You will do pretty much the same things you did in the course, but on different applications so make sure you’re acquainted with the courses methods. It’s an entire different thing when you’re not guided.
  • There is plenty of time to do it as long as you don’t get stuck too much on rabbit holes, take brakes and sleep.
  • Take notes for your report along the way. You need to make sure you get all code snippets during your exam time to avoid freaking out when you later write the report.
  • You cannot copy applications from the exam machines to your own. Consider that when you decide what tools you’ll use for your analysis.
  • Before the exam try to create your own work methodology and make sure you stick to it. Why? Staying organised, avoiding rabbit holes and making sure you don’t miss any checks. More on this later.
  • Book your exam as soon as possible, as first available date can be a couple of months away. This also happened to me, but fortunately I managed to catch someone else’s canceled slot, a month earlier than initially booked.
  • Have a backup Internet connection for the exam. I usually have great, reliable Internet, so I didn’t bother to get one. (Bad) luck had it, that the second day of theOSWE exam, my Internet connection was down for almost 2 hours. Tried using mobile tethering, but the proctoring software wouldn’t work on it, so I couldn’t actually continue the exam. Don’t be like me.

OSWE Exam Methodology

The AWAE course does a great job on explaining the presented vulnerabilities. There are some opinions online that the course doesn’t go into enough depth in terms of vulnerability discovery. I do not agree with that, as I think that it pretty much covers everything you need to know for the exam. My opinion is that the key factor is to be organised.

Here’s a broad overview of my plan for assessing an web-app:

  1. Explore the website, having Burp or some other proxy tool record traffic. Check public & authenticated web pages.
  2. Make notes of important functionalities like: authentication endpoints (login, password reset), admin area, file upload, forms, restricted stuff, etc.
  3. See source code: find how routes are handled, find responsible code for the functionalities identified earlier (and look at additional stuff your initial discovery might have missed).
  • I usually prioritise unauthenticated functionalities, authentication mechanisms (like password reset) and session management code. Manual analysis is required to properly understand the inner workings of each.
  • Then I go for injection vulnerabilities. Use RegEx to search for common SQL keywords. If the app uses a ORM, manual analysis of the database functions will help identify the proper pattern to search for. XSS may be easier to discover using a black-box approach by just spraying polyglot payloads.
  • Once that’s done, search for programming-language specific issues. I made notes on what vulnerabilities you can encounter, besides the ones already described above.
    • Consider deserialisation. I was a Java developer, so I know that deserialisation in this case is done when calling method “readObject()”. So in my notes, I added “search for “readObject()” as my todo note when I encounter a Java app. Similar for .NET. Or “eval” in javascript apps. You get the point.

Once you have all the notes with the things you need to check, grouped by programming language, you can take your mind off that and focus on the actual tasks at hand. Having a plan like this worked for me and I hope it does for you.

My thoughts on the course

The AWAE course does a great job on teaching you how to exploit web-applications by finding vulnerabilities and chaining them together to obtain remote code execution. The thing I enjoyed the most is learning how impactful can several seemingly unimportant vulnerabilities be when chained together.

The course does a great job on explaining why each issue is a problem and how to exploit it. My mind was first blown by magic hashes and PHP Type Juggling. Then I was amazed by the number of ways one could spawn a shell via SQL injection. .NET was an unknown for me when starting this course, so I got particularly good value in this area.

Overall I was pretty happy with the course and exam experience. Great value for the money, like other Offensive Security courses.

Should I take the OWSE certification?

If it fits your needs, then don’t hesitate to pull the trigger and go for it! For me, as an Application Security Engineer dealing heavily with web-apps, it was a no brainer. I read code and do security audits as part of my daily job, so not only did I get a lot of knowledge from the course, but it also validated what I already knew (keeping away that nasty imposter-syndrome!).

Helpful resources on AWAE/OSWE:

  • The Web Application Hackers Handbook 2nd edition – the entire book is great, but it has a chapter dedicated to white-box analysis (Chapter 19 – Finding vulnerabilities in source code)