This pathway is designed to give an introduction to web applications and how to exploit them. The first module “How The Web Works” is covered in the Pre-security pathway, and the final module “Web Hacking Fundamentals” is covered in the Complete Beginner pathway. Therefore I will only cover the two new modules in this room, “Introduction to Web Hacking” and “Burp Suite”, to allow me to cover them in more detail.

Introduction to Web Hacking

This module starts with how to enumerate a website to discover vulnerabilities. The first room is Walking an application, which includes some manual ways to do this, including looking at the page source and using Developer Tools.

The next room, Content Discovery, is more of the same, covering different ways to uncover content on a website using 3 different techniques, manual, OSINT and Automated. The manual enumeration includes things like checking robots.txt and sitemap.xml, as well as investigate the HTTP headers of a website. The OSINT section includes techniques and tools such as Google Dorking, Wappalyzer and The Wayback Machine. It also covers looking at common online services such as GitHub and S3 buckets. The automated content discovery makes use of tools such as Gobuster and ffuf.

Next up is Subdomain Enumeration, which covers the process of finding valid subdomains for a domain as a way to expand the attack surface. This included looking as SSL/TLS certificates to find domain records. It also looked at tools like DNSRecon and Sublist3r. It also covered looking for virtual hosts using Gobuster and ffuf.

The next room was Authentication Bypass. The first thing covered was bruteforcing credentials using ffuf. It then looked at gaining access due to logic flaws in the programming. Finally it looked at tampering with cookies, especially those set in plain text to gain access to the table. In the event that a cookie is not in plain text, we can look at either decoding it in a decoding tool (such as the one in Burp Suite), or attempting to crack the hash with a rainbow table.

Up next was Insecure Direct Object References (IDOR) and how these can be exploited. This type of vulnerability can occur when a web server receives user-supplied input to retrieve objects (files, data, documents), too much trust has been placed on the input data, and it is not validated on the server-side to confirm the requested object belongs to the user requesting it. A simple example is an id being present in the URL, and a user being able to change the id and access pages that are not their own. IDs can be hashed or encoded, but a good test to check for this vulnerability is to create two accounts and see if you can swap the IDs and still see the same page. IDOR may not be present in the address bar, so it is important to look around.

Local File Inclusion (LFI) and Remote File Inclusion (RFI) are vulnerabilities commonly found and exploited in various programming languages for web applications, such as PHP, that are poorly written and implemented. It is also possible to use path traversal inside an address bar to gain access to pages and directories not normally accessible to the standard user. Remote File Inclusion allows an attacker to host a file on their own server, and serve it to the target using a command, or malicious URL. This file can then be run on the server to give the attacker RCE. The number one way to handle LFI, RFI and path traversal is to never trust user input, and to have proper input validation.

The next room covered Server-side Request Forgery (SSRF). This is a vulnerability that allows a malicious user to cause the web server to make an additional or edited HTTP request to the resource of the attacker’s choosing. There are two types of SSRF:

• Regular: Data is returned to the attackers screen
• Blind: SSRF occurs but no information is returned to the hacker

Common places to look for SSRF include when a full or partial URL is used in a parameter in the address bar, or a hidden URL field in a HTML form. Common fixes to SSRF include adding a Deny or Allow list to limit where a user may visit or request data from.

Next up is Cross-site Scripting (XSS). This is an injection attack, and occurs when malicious JavaScript gets injected into a web application with the intention of being executed by other users. The common test code for XSS is:

<script>alert(‘XSS’);</script>

which creates a pop-up saying “XSS” if the injection works. There are four different types of XSS:

• Reflected XSS happens when user-supplied data in a HTTP request is included in the webpage source without any validation.
• Stored XSS is when the payload is stored on the wb application (in a database, for example) and then gets run when other users visit the site or webpage. In order to test for stored XSS, you need to test every point of entry where it seems like data could be stored and then shown back to users.
• DOM-based XSS is where the JavaScript execution happens directly in the browser without any new pages being loaded or data submitted to the back-end code. Execution occurs when the website JavaScript code acts on input or user interaction. This means that crafted links could be sent to potential victims, redirecting them to another website, or steal content from the page or user’s session.
• Blind XSS is where the payload gets stored on the website for another user to view, but in this instance, you can’t see the payload working or be able to test it against yourself first.. When testing for blind XSS, you need to ensure your payload has a call-back (usually a HTTP request), so you know if and when your payload is being executed.

Next is Command Injection. This is the abuse of an application’s behaviour to execute commands on the operating system, using the same privileges that the application on the device is running with. This can allow a user to execute commands without direct access to the machine through something like an interactive shell. Blind injection means there is no direct output from the application when testing payloads. As with a lot of web vulnerabilities, one of the key remedies for this vulnerability is to not trust user input and sanitise it accordingly. It is possible to bypass such filters by escaping malicious characters, so it can also be important to not populate system commands with user input.

SQL injection is an attack on a web application database server that causes malicious queries to be executed. When a web application communicates with a database using input from a user that hasn’t been properly validated, there runs the potential of an attacker being able to steal, delete or alter private and customer data and also attack the web applications authentication methods to private or customer areas. There are three common types of SQL injection:

• In-Band SQL Injection: This is the easiest type to detect and exploit; in-band just refers to the same method of communication being used to exploit the vulnerability and also receive the results, for example, discovering an SQL Injection vulnerability on a website page and then being able to extract data from the database to the same page
• Error-based SQL Injection: This type of SQL injection is the most useful for easily obtaining information about the database structure as error messages from the database are printed directly on the browser screen. This can often be used to enumerate a whole database.
• Union-based SQL Injection: This type of injection utilises the SQL union operator alongside a select statement to return additional results to the page. This method is the most common way of extracting large amounts of data via an SQL injection vulnerability

To avoid SQL injection attacks, it is important to validate user input, and escape it. It can also help to create prepared statements to ensure the SQL code structure doesn’t change when user input is supplied.

Burp Suite

The basics of Burp Suite are covered in the Complete Beginner pathway, where it covered how the framework operates, and how to intercept and modify requests to hack web applications. This module then covered more of the tools in Burp Suite in great detail.

First up was the Repeater. This allows us to craft and/or relay intercepted requests to a target at will. In layman’s terms, it means we can take a request captured in the Proxy, edit it, and then send the same request repeatedly as many times as we wish. This ability to edit and resend the same request multiple times makes Repeater ideal for any kind of manual poking around at an endpoint, providing us with a nice GUI for writing the request payload and numerous views (including a rendering engine for a graphical view) of the response so that we can see the results of our handiwork in action.

Next up was Intruder, which is a powerful tool that allows for automated and customisable attacks. It provides the ability to modify specific parts of a request and perform repetitive tests with variations of input data. Intruder is particularly useful for tasks like fuzzing and brute-forcing, where different values need to be tested against a target. It has four different attack modes for various different types of attack.

Then the module covered the Decoder, Comparer and Sequencer. Decoder can be used for decoding and encoding payloads, which can be helpful for prepping data for transmission to the target. The comparer allows us to take two captured requests or responses and compare them for differences. Sequencer allows us to look at the randomness of tokens generated, such as session cookies or CSRF tokens.

Finally, the module covered the extensions interface, which allows the user to manage and monitor the installed extensions, activate them or deactivate them for specific ports, and view important details, output, and errors related to each extension.