OSCP Prep – Episode 9: Web App Attacks

This week, I decided to take a small detour and study web application testing before continuing to post exploitation techniques. Like any software, web applications may have a range of vulnerabilities when secure coding methods are not followed. Vulnerabilities in web applications are most commonly associated with improper input handling, allowing attackers to inject malicious strings of code which manipulate the back-end database or execute commands.
The three types of web application attacks I will be covering are SQL injection, cross site scripting, local file inclusion and remote file inclusion.

SQL Injection

The first and most commonly known web application attack is SQL injection. This is something I was already quite familiar with, having done a database course at University with a heavy focus on using SQL commands to query a database for specific information. However, because it is so commonly used in web application testing, I decided to quickly go through some of its use cases from a penetration testing perspective.

Many web applications store data in a back-end database, often based on SQL. Typically, we won’t have direct access to the back-end database to run SQL queries (if we did, that would obviously be a very big security issue). However, it is possible for the web application to not correctly sanitize the users input when interacting with forms that read data from this back-end database. In these cases, it may be possible to input strings of SQL code to manipulate the queries sent to it. Successful SQL injection attacks could provide read access to sensitive data, or in the worst case scenario provide shell access to the underlying operating system.

An example of SQL statement that could be useful to an attacker is:
SELECT username FROM users WHERE username=’ ‘ or ‘1’=’1′ AND password =’ ‘ or ‘1’=’1′

because the or ‘1’=’1′ will always be true, this SELECT statement simply returns the first username in the user table (disregarding that users username or password).
Essentially, the statement is saying if the username is ‘ ‘ OR 1=1 then select the first username. Obviously, the first section of ‘ ‘ will not return any usernames, but the second statement 1=1 will always be correct (or true). The database then accepts the query as being correct, and returns the first username in the database.
The same logic can be applied for passwords. The website hacksplaining does a good job walking you through the steps to execute a SQL injection, complete with a hands on example. The same statement is used, where the 1=1 function enables the database to be queried.

sql1Typing ‘ or 1=1– in the password field can a very basic way to gain access.

sql2 The SQL code works by circumventing the password requirement, where the or ‘true’ section of the script provides the access.
The explanation and basic hands on example can be found at: https://www.hacksplaining.com/exercises/sql-injection#/start

Another way SQL injection can be exploited in web applications is through the use of the Kali Linux tool SQLMap. Providing this tool with a target URL, it can test for SQL injection vulnerabilities and provide the output of various injection queries.
Some options that can be used in SQLMap are:
–dump – this dumps the contents of the databse
os-shell – uses the database to attempt to gain shell access on the underlying system.

SQL injection can be a very effective method of gaining control or information over a database or system. Because MS SQL often runs as a privileged user, the amount of access the queries have are often significant. It is therefore extremely important for secure coding practices to be implemented at all stages of development, along with proper input validation and frequent penetration tests before the web application is released into production.

XSS – Cross Site Scripting

Another extremely common security vulnerability found in web applications is Cross Site Scripting (XSS). XSS is a code injection attack that allows an attacker to execute malicious Javascript on the browser session of the victim.

There are two main types of XSS attacks:


These attacks occur when the attacker injects code into the websites database, and users who visit fall victim to the code when it is executed. The attack is called ‘persistent’ or ‘stored’ because the code is stored on the web application server and persists there, executing in the browser of each user who visits the site.

The diagram below, from the excellent site https://excess-xss.com/ provides an example of a persistent XSS attack


  1. The attacker uses one of the website’s forms to insert a malicious string into the website’s database.
  2. The victim requests a page from the website.
  3. The website includes the malicious string from the database in the response and sends it to the victim.
  4. The victim’s browser executes the malicious script inside the response, sending the victim’s cookies to the attacker’s server.


These attacks occur when a user sends the request with the XSS attack included, meaning the malicious string originates from the victims request. There may be social engineering techniques used to trick the victim into sending the request, for example by providing a link with the code contained that executes once the victim accesses the site. These attacks are called ‘reflected’ because the attack is reflected to the web application by the victim, rather than originating from the attacker.
Reflected attacks may be more successful if the link uses a shortening service, such as bit.ly.

The diagram below, again from the excellent site https://excess-xss.com/ provides an example of a reflected XSS attack


  1. The attacker crafts a URL containing a malicious string and sends it to the victim.
  2. The victim is tricked by the attacker into requesting the URL from the website.
  3. The website includes the malicious string from the URL in the response.
  4. The victim’s browser executes the malicious script inside the response, sending the victim’s cookies to the attacker’s server.

As usual, there is a tool available in Kali Linux that can test a web application for XSS vulnerabilities, and reveal the extent of control that can be leveraged from them. It is known as BeEF, or Browser Exploitation Framework. BeEF works by ‘hooking’ a browser to acting as if it was browsing on the BeEF server, or by using the BeEF JavaScript hook as a payload in the presence of a known XSS vulnerability.

Local File Inclusion and Remote File Inclusion

Another common vulnerability, local file inclusion refers to the ability to read files that should not be accessible through the web application. This may be due to the permissions of the web application allowing it to access files from the rest of the file system, or by incorrectly displaying files that should be locked to the user.

Remote File Inclusion
vulnerabilities allow attackers to load  files which execute malicious scripts that are not hosted on the web server. By tricking the web server into loading and executing a remote script, it is possible to run commands on the underlying system to gain access.

Web application security is a huge area of information security, and is far more extensive than what was covered in this post. As web application continue to increase in use, it is extremely important for developers and vendors to implement secure coding practices throughout all stages of development. In particular, input handling is a must to ensure would-be-attackers are unable to inject malicious strings of code when presented with forms.
More on web application security can be found at the Open Web Application Security Project (OWASP) website: https://www.owasp.org/index.php/Main_Page

One thought on “OSCP Prep – Episode 9: Web App Attacks

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s