AWAE Course Review

2022 is off to a great start for me – I recently passed my Advance Web Attacks and Exploitation (AWAE) exam and earned my Offensive Security Certified Expert (OSWE) Certification.


I previously achieved my OSCP (Offensive Security Certified Professional) in 2018 and knew then that I wanted to ultimately earn my OSCE (Offensive Security Certified Expert). However, I had other commitments – I was enrolled in both Oregon State University Post-Bacc in Computer Science Program and the SANS Institute’s Graduate Certificate for Penetration Testing. I had other commitments and had to put my goal of earning OSCE on hold.

In August 2021, I had completed by SANS graduate certificate program and most of my courses for OSU (I’m currently completing my final class) and I had extra bandwidth to again pursue my OSCE.

The AWAE is one of three certifications needed from Offensive Security to achieve OSCE – the other two being OSEP (Offensive Security Experienced Pentester) and OSED (Offensive Security Exploit Developer).

Who is Offensive Security

If you’re not familiar with Offensive Security, they are the company responsible for creating the most popular Linux Distro in use for penetration testers and security practitioners – Kali.

They also provide training and certifications in the various field of penetration testing, e.g. windows/linux/Mac exploit development, black box penetration testing techniques and methodologies, web application penetration testing, etc.

Offensive Security Courses

Offensive Security certifications are arguable the most well-respected in the INFOSEC community – even by those who scorn certifications.

This is because you are required to demonstrate hands-on practical ability to launch a successful penetration test.

The AWAE exam is a proctored exam where you’re given access to a VPN with vulnerable web applications. You’re required to identify the vulnerabilities in those web applications and write your custom script to exploit them. There are no hints and you can’t phone a friend.

What is AWAE

Anyone who has take other penetration testing courses know that the field is very broad – there are different phases/aspect of a pen test engagement. AWAE is focused solely on exploiting Web Applications.

AWAE Syllabus

In the Penetration Testing With Kali Linux (PWK)/OSCP course, the approach was from a black box perspective – you had no prior knowledge about what services the VMs were running. You were taught the process of scanning, enumerating, then exploiting machines.

In AWAE is a course in white-box penetration testing. You know the vulnerable service is a web application and you’re given access to source code.

In the PWK/OSCP there were 40+ machines to exploit, in AWAE there 6+. The number of targets is smaller, but you’re digging through thousands of lines of code to discover vulnerabilities.

AWAE/OSWE differs from PWK/OSCP in that you write your own exploit – typically in python. The general strategy is exploit authentication then achieve a shell, i.e. remote code execution.

The instructor walks you through on processes and methodologies to identify vulnerabilities in the different web applications and how to exploit them.

If PWK/OSCP is a mile wide and one inch deep, then AWAE/OSWE is a mile deep and one inch wide.

Recommended Pre-requisites

AWAE is an advanced course, if you’re new to cybersecurity or penetration testing, this is not for you. I recommend you have a baseline level of knowledge and skills prior to taking the course:

  • Scripting Language, recommend Python
    • Needed because you have to write your own exploits for the exam
    • Python recommend because this is what’s used in the course
  • Understanding of routes/endpoints in web application
  • Preferably familiar with one web application framework, e.g. nodejs express, django, php ruby on rails
    • If you know one, that should give you sufficient exposure to understanding how web applications are built,
  • General understanding of vulnerabilities in Web applications e.g. sqli, xss, csrf, etc.
    • no need to be an expert, you’ll get tons more instruction during the course
  • Understand how to read regular expressions e.g. “.*?var.*?sql.*?=.*?query.*?
  • Be comfortable using IDE for debugging e.g. Visual Studio, or Eclipse. In the course you’ll be debugging in VS Code a lot
  • Foundational understanding of programming:
    • Control Structures (if, while, for, etc)
    • Data Structures (dictionaries, lists, arrays, etc)
    • Data types (strings, ints, floats, booleans)


As stated before you have 48 hours to exploit a certain number of vulnerable web applications. You have another 24 hours to write a penetration testing report.

  • The exam is proctored, you’ll be required to verify your ID and to perform a sweep of the room you’ll be taking the exam in.
  • Take breaks regularly. Examining thousands of lines of code will wear you down quickly. During the first day I took an hour long break roughly every four hours. In the second day, I needed a 10-15 minute break every hour. I probably could’ve planed breaks a better
  • Do plan to get one solid block of sleep. I did not execute this properly, learn from my mistake. I was in bad shape during the second day.
  • You can’t have your phone with you in the same room.
  • You’ll need to notify the proctor anytime you leave and return to your computer.
  • Don’t get stuck going down a rabbit hole. If an avenue you’re going down an avenue that you thought might lead to an exploitation but doesn’t, don’t be afraid to take a step back and examine another route.
  • Take down notes about your thoughts and methodology on the vulnerabilities you discovered.
  • TAKE SCREENSHOTS REGULARLY! It’s easy to get caught up in the engagement. Don’t be that guy who get all the ‘proof.txt’ and ‘local.txt’ files but forgets to take screenshots showing how you got them. You will fail if report is lacking.


I was really happy with the course, I learned tons of new techniques and methodologies to exploit web applications. I absolutely feel that I came away from the course a more knowledgeable security practitioner – both in theory and in practical, hands-on application. I think it was money well spent.

I expect that I will be enrolling in the OSEP course in the near future and the OSED following that. God willing, I’d achieve those two certs and become an OSCE.

Thanks for visiting,



Tutorial: A webapp vulnerable to XSS


In this tutorial we’re going to cover the following topics:

  • Creating Nodejs routes
  • Creating a Handlebars templates
  • Writing a webpage vulnerable to XSS exploit

Nodejs Router:

I’m going to introduce you to Routers, instead of explaining (probably in later post), I’ll just show you by example. To start we’ll need to add a new route in our ‘app.js’ file:

new route to http://<your ip addresss>/xss
  • ‘app.use’ :: this will bind a route – ‘/xss’ – the the middleware layer that we want to use, i.e. ‘xss.js’
  • Easier explanation :: anytime a user visits the ‘/xss’ route in our web application, e.g., it tells the server to execute the functions defined in the ‘./xss.js’
  • We have to define a new file names ‘xss.js’ in the same directory as the app.js file. Note, if we instead defined the middleware as ‘./public/xss.js’, then we have the have folder named public in the same directory as the ‘app.js’ file, and within that ‘public’ folder, we would need to define ‘xss.js’

Define ‘xss.js’

Create and open a file named ‘xss.js’ in the same directory as ‘app.js’

touch xss.js 

If we listed all of the contents in the current directory (ls -al), it should like the following:

Open up the ‘xss.js’ in an text editor:

vim xss.js

Screenshot of the skeleton code:

skeleton code of ‘xss.js’ file

I’m going to try and explain what’s going on here and hope this makes sense.

Recall in the ‘/wagmi’ route, anytime this endpoint is visited it executes a function that defined inline:

visting /wagmi executes an inline function

The ‘/xss’ route also needs a handler/function that is executed. In this instance we’re ‘importing’ – through the use of ‘require’ – the functions from the ‘xss.js’ file. Because we’re importing the function, then the ‘xss.js’ file must export a function, which it does. Notice the use of ‘module.exports’:

xss.js returns the handler/function that will be called for ‘/xss’ route

Hopefully, this explains what’s going. If not, just hit the “I believe button’ and copy the code. Moving on we have to define what handler will be doing when the ‘/xss’ route is visited.

We define that as so:

Note, do not get confused with ‘/’, root, endpoint. This is not defining the route for, it’s defining the handler for the http://127.0.01/xss/

Recall that in the ‘app.js’ file it’s redirecting all traffic to the ‘/xss’ endpoint to the ‘xss.js’ file. Using ‘/’ means we are using the root ‘/xss’ endpoint. In the ‘xss.js’ file, if we instead use ‘/subdirectory’, instead of ‘/’, we would be defining the route for

Quick description of what’s going on inside the handler:

  • we initialize variable ‘context’ which will be a dictionary
  • we set dictionary key name ‘text’, i.e. context.text’ to value in query parameter ‘text’.
  • we send a response back to the client that visited the ‘/xss’ endpoint.
    • we use our templating engine – ‘handlebars’ – to create the html page
    • we pass the context variable for ‘handlebars’ templating engine to use.

We have to tell our web app to use the handlebars templating engine. Let’s do that now.

Handlebars Template Engine

In the ‘app.js’ we have to configure our web app to use the handlebars templating engine:

add the highlighted lines of code into you app.js file
  • We are importing (i.e. require) the handlebars package
  • We are telling handlebars the default html script to be included in all of our html pages
  • We are setting the web app template engine to handlebars

Recall the directory structure in the first tutorial:

Directory structure of our web application

This is a standard layout when using the ‘handlebars’ template engine. It’s important specifically to have the ‘views’ and the ‘view/layouts’ directories.

In the ‘layouts’ directory, is where we define the ‘main.handlebars’ template, this will be included in every html page our web app responds with.

The ‘views’ directory will have the specific handlebars/html templates for our routes. We do this because, presumable, we’ll have different html for different endpoint, we don’t want the same html for all of our webpages, that would be boring.

Screenshot of my main.handlebars template:

html code inside ‘main.handlebars’

<!doctype html>
<title>My Page</title>
        <!--bootstrap setup -->
        <meta charset="utf-8">
        <meta name="viewport" content="width=device-width, initial-scale=1">
        <script src=""></script>
        <link rel="stylesheet" href="" integrity="sha384-ggOyR0iXCbMQv3Xipma34MD+dH/1fQ784/j6cY/iJTQUOhcWr7x9JvoRxT2MZw1T" crossorigin="anonymous">
        <link rel="stylesheet" href="" integrity="sha384-AYmEC3Yw5cVb3ZcuHtOA93w35dYTsvhLPVnYs9eStHfGJvOvKxVfELGroGkvsg+p" crossorigin="anonymous"/>
        <script src=""></script>

        <script src=""></script>
        <script src=""></script>


In my main, I include the sources for bootstrap and jQuery. This is where you ideally put styling sources that you want rendered for all of your pages. This is a benefit of using templating engine – you minimize the amount of code that is repeated. You need this because I’m using bootstrap styling.

We now need to define the index.handlebars file, the file that is rendered when someone visits the ‘/xss’ route.

Creating an XSS vulnerable Webpage

In the ‘xss.handlebars’ file write the following code:

<h1>Cross Site Scripting Test</h1>
  <div class="container">
          <form action="/xss" method="get">
                  <div class="form-group">
                          <label for="text">Input Text Here:</label>
                          <textarea class="form-control" name="text"></textarea>

                  <button type="submit" class="btn btn-primary">Submit</button>
          {{#if text}}

The important parts:

  • We creating a form element
    • The form element has a textarea/text box, where the user can provide input
    • The textarea/text box has a ‘name’ attribute of ‘text’, this is equivalent to a variable. When the types in input and submits, the user’s input is set to the ‘name’ variable
    • when submitted it performs a ‘GET’ request to our ‘/xss’ route
  • Notice the Block of code defined between {{#if text}} … {{/if}}, handlebars supports if statements.
    • If the handlebars engine is passed a variable named ‘text’ it will generate that into the html
    • {{text}} (double brackets) will escape special characters
    • {{{text}}} (triple brackets) will not escape, it will generate the exact string that the user inputs into the form.

Save the file.

Testing the web application

At this point we should be ready start up our web applications.

Navigate out of your ‘views’ folder where you edited the ‘index.handlebars’ page and into the directory where your ‘app.js’ file is. The contents of your current directly should like so:

Startup the web application:

node app.js

Open up a Google Chrome browser and browse to

Insert the following into the text box:


Click ‘Submit’. You should’ve receive a text box popup stating “wagmi”:

text box pop up with

Congratulations! You not only completed fully function web application, you wrote one that was vulnerable to XSS.

Vulnerable Piece of Code

unescaped user input

The culprit that results in an XSS vulnerability is the use of triple brackets in the handlebars templating engine. Handlebars will render the user input exactly as written, there is not escaping/sanitization of user input.

A quick fix would be to use the double brackets to render variable passed into the handlebars template, this would escape special characters.

Another option could be to perform user input sanitization in our middleware. I’ll leave this to you to research what node packages are available to sanitize user inputs.

Anyway, I hope you found this tutorial enlightening. In the next few tutorials, I want to go over how to connect your web application to a Database and introduce sql injections.



Apple MAC Software Engineering Tutorial Vim Web Development

Tutorial: Your first Web App

Greeting Frens,

Welcome to the first of many tutorials that I will be publishing.

In this tutorial I’m going to show you how I setup my development environment. I’m going to going be writing a series of tutorials on how to write, exploit, and secure intentionally vulnerable web applications.

I’m documenting my Capstone Project for my Computer Science Degree from Oregon State University.

Admittedly, this will be fairly dry, but its necessary, we’ll building off this in the coming months.

Development Environment:

  • OS: MAC OS Monterrey
  • Z shell (zsh) command line environment
  • NodeJS Packages:
    • express
    • express-handlebars
    • router
    • body-parser

Environment Setup

When I’m coding I use the command line and vim – neovim to be exact – a lot. You can use an IDE instead of vim when writing code, but I recommend getting good with the command line and text editors (vi, vim, etc.), especially if you plan for a career on penetration testing.

Step 0 (optional, only for MAC users) – install home-brew:

$ /bin/bash -c "$(curl -fsSL"

Step 1 – install nodejs and npm:

Ensure that that homebrew is updates:

$ brew update

Install node and node package manager (npm)

$ brew install node

If you’re using a Debian flavor (i.e. ubuntu, kali, mint, etc), instead of ‘brew’ it would be ‘apt’

Step 2 – Create a working directory and navigate to it:

$ mkdir working && cd working

Step 3 – Directory Structure:

You’ll need to create a directory structure that looks like so:

If you’ve been following along ‘./OSU/vulnerabilites’, would be ‘./temporary’. ‘./temporary’ is the main directory.

The ‘./temporary’ parent directory will have to sub-directories – ‘./public’ and ‘./views’.

The ‘./views’ sub-directory will have a sub-directory – ‘./layouts’

Ignore all the other files for now.

Also, if you’re wondering, the screenshot above is from neovim text-editor. I’ll create another tutorial explaining my setup and plugins.

Step 4 – Install node packages:


$ npm install --save <package_name>

npm :: node package manager, binary that installs packages

install :: tells npm to install a package. We can use ‘i’ instead of ‘install’

–save :: tells npm to write and save the package name to the ‘package.json’ file

Install express package:

$ npm i --save express

Express is a minimal and flexible Node.js web application framework that provides a robust set of features for web and mobile applications.[1]

Install express-handlebars:

$ npm i --save express-handlebars

Handlebars is a web application templating engine. If you don’t what this is, I’ll probably cover this another post, or you can Google it. Short answer: it makes creating dynamic web pages easier.

Install body-parser:

$ npm i --save body-parser

body-parser is need to parse the parameters in a ‘POST’ or ‘GET’ request.

Install router:

$ npm i --save router

Router object is probably not needed, but it’s good to use anyway. Maintaining multiple routes in the main app (app.js) can get cumbersome.

After installing these packages, node will create two new files in the main directory (‘./temporary’) – package.json and package-lock.json. There will also be a new directory – ‘./node_modules’.

Your First Web Applications – Hello World

Step 0: Create app.js file and open with an editor:

$ touch app.js
$ vim app.js

This file is under the parent ‘./temporary’ directory. Also note, I’m using vim edit the file, you could optionally use an IDE.

Step 1: Create Express Object:

const express = require('express');
const app = express();

Here we are creating an express objectThe ‘require’ statements are equivalent to ‘import’ statements in other language. Express is the middleware/framework/etc. whatever you want to call it that allows us to create our webapp/web server.

Step 2: Create a route:

app.get('/wagmi', function(request, response){

This is a route handler. ‘app.get’ is specifying a handler for an HTTP GET request to the ‘/wagmi’ endpoint on our web application.

HTTP basics:

  • Uniform Resource Identifier (URI):
    • Uniform Resource Locator (URL) ::
    • Uniform Resource NAme (URN) :: ‘/wagmi’
  • URL is a subset of URI. It provides information about the location (i.e. domain name which gets mapped to an IP address by DNS). You can input an IP address directly in here.
  • URN is a subset of URI. It provides the name of the specific resource you are trying to access of a target location. In this case it’s the ‘/test’ endpoint.

Note: our Webb will not be located at, we’ll be running it on our local machine, it’ll be http://localhost or

‘function(request, response)’ is a callback function the this executed whenever someone browses to ‘/test’ endpoint of our web appp.

‘request’ is an object that contains information about the HTTP request that raised the event.

‘response’ is the response object of the server. When the handler for route ‘/wagmi’ is triggered, the server will response with the message “WAGMI!”.

Step 3: Set up the listening port:

app.listen(31337, function(){
    console.log("web app started...");

This tells the the web app to listen on port 31337 and then prints out a message to your command line terminal.

After this we save and exit the text editor (:wq) or IDE.

The final product should look something like this:

Step 4: Start the web server:

$ node app.js

Step 5: Browse to your web application

Open up a browser and go to

If you made it this far, Congratulations!!

In this module we covered how to setup a development environment and then we built a very simple web application.

We did not use all the node packages that we installed, e.g. body-parser and router, but we will in future tutorials.

In the next tutorial I’m going to create a simple web page with a Cross Site Script Vulnerability.

Until then, Cheers!


Hello World!

Greetings and welcome to my blog – Francis’s Microsdose.

My name is Francis (go figure) and I am cyber security engineer in the Defense Industry. I’ve been in this field for nine years and counting.

I hold B.S. in Mechanical Engineering, US Naval Academy, M.S. in Cyber Security Engineering, University of San Diego. I’m currently pursuing my B.S. Computer Science from Oregon State University (one class remaining) and M.S. Computer Science from Georgia Institute of Technology (eight classes remaining). I should be complete with my B.S. by spring of 2022.

I also hold numerous Cyber Security Certifications – CISSP, GCIH, GPEN, GWAPT, GXPN, and OSCP (I’m most proud of this one). I’m currently pursuing Offensive Security’s Advance Web Application and Exploitation Certification and hoping to ultimately my Offensive Security Certified Expert Certifications

I started out this blog to: share advice on how to make it in the Cybersecurity field; document and share tutorials of my past, present, and future penetration testing challenges; and just share my thoughts on anything cybersecurity related.

I hope your ass passionate about cybersecurity as I am and that this site proves to be a useful resource.