Web Exploitation

Challenges related to finding and exploiting vulnerabilities in web applications and web servers. Common vulnerabilities are SQL injection, cross-site scripting (XSS), and server side request forgery (SSRF). Web-based application challenges require you to detect, exploit and search through different vulnerable web applications.

Web application vulnerabilities

A website/web application vulnerability is a weakness or misconfiguration in a website that allows an attacker to gain some level of control of the website, and possibly the hosting server.

SQL Injection (SQLi)

SQL injection is a code injection technique, used to attack data-driven applications, in which malicious SQL statements are inserted into an entry field for execution. This is a method to attack web applications that has a data repository or a database backend. The attacker would send specially crafted SQL statements that is designed to cause some malicious action. SQL injection occurs due to failure to validate user input.

Let us take the following SQL statement below. The application will crash because the SQL statement is incorrectly formatted (extra single quote at the end of the statement).

SELECT * FROM users WHERE username='''

With the knowledge that a single quote will cause an error in the application, the SQL statement can be further modified as shown below.

SELECT * FROM users WHERE username='' OR 1=1

1 is indeed equal to 1. This equates to true in SQL, which will cause the return every row in the table because each row that exists must be true.

It is also possible to inject comments and termination characters like – – or /* or ;. This allows one to terminate SQL queries after your injected statements.

Command Injection

Command injection involves a web security vulnerability that allows an attacker to execute arbitrary but unauthorised commands on the host operating system. Similar to SQL injection, command injections also occur due to failure to validate user input that goes into a system shell. It is very common to see this vulnerability when a developer uses the system() command or its equivalent in the programming language of the application.

For example, see the code snippet below.

import os

domain = user_input() # google.com

os.system('ping ' + domain)

Under normal conditions, the above code snippet will ping the google.com domain. However, consider what will happen when the following user_input is supplied: ping ; ls

Because of the additional semicolon, the os.system() function is instructed to run two commands. In addition to the empty ping command, the ls command will also be executed!

Command injection is a very common means of privilege escalation within web applications that interface with system commands.

Directory Traversal

Directory traversal (or file path traversal) is a vulnerability where an application takes in user input and uses it in a directory path. Any kind of path controlled by user input that isn’t properly sanitized or properly sandboxed could be vulnerable to directory traversal.

Consider the following example:

<img src="/loadImage?filename=123.png">

The loadImage URL takes a filename parameter and returns the contents of the specified file. The image file is stored on disk in the location /var/www/images/. Using the filesystem API, the filename is appended to the base directory: /var/www/images/123.png.

If the web applications lacks the necessary defenses, an attacker can request the following URL to retrieve an arbitrary file from the server’s filesystem:

https://insecure-website.com/loadImage?filename=../../../etc/passwd

In the above example, the sequence ../ is valid within a file path and causes one step up in directory structure. Therefore, three consecutive ../ sequences step up from /var/www/images/ to the filesystem root, finally to read /etc/passwd. On Unix-based systems, this is the standard file containing user accounts registered on the system.

Cross Site Scripting (XSS)

Cross Site Scripting or XSS is a vulnerability where a user of a web application can send JavaScript commands that is executed by the browser of another user of the same application. This is a vulnerability because JavaScript has a high degree of control over a user’s web browser.

For example JavaScript has the ability to:

  • Modify the page (called the DOM)
  • Send more HTTP requests
  • Access cookies

Reflected XSS is when an XSS exploit is provided through a URL parameter. For example:

https://test.org?data=<script>alert(1)</script>

Stored XSS is different from reflected XSS in one key way, the exploit is stored on the website itself.

Imagine a website that allows users to post comments. If a user can submit an XSS payload as a comment, and then have others view that malicious comment, it would be an example of stored XSS.

Cross-Site Request Forgery (CSRF)

CSRF is a malicious attack where a user is tricked into performing an action he or she didn’t intend to do. An example, a third-party website will send a request to a bank web application that a user is already authenticated against and perform money transfers.

Broken Authentication & Session Management

Broken authentication and session management occur when authentication credentials and session identifiers are not protected at all times. These vulnerabilities can give attackers access to user accounts and even the ability to compromise an entire system using an admin account.

Insecure Direct Object References (IDOR)

IDOR is a vulnerability that occurs when a web application exposes a reference to an internal implementation object e.g., files, database records, directories and database keys, which allows hackers to manipulate it to gain access to a user’s personal data.

Web Exploitation Tactics

The are key steps to follow when apply web exploitation tactics. The steps are reconnaissance, scanning, gaining access, escalating privileges and maintaining access. The last step is, however, not common in web exploitation challenges since, once you escalate privileges, you are most likely able to access all the hidden flags.

Reconnaissance

Attempts to gain as much information about the target, in this case the web application or web server, as possible. Reconnaissance can include both active (directly engaging with the target to gather information) and passive (collecting information on a target without directly interacting with it – exploring publicly available information) tactics.

Check and explore the source code. Right-click on the website and click on “View Page Source“. This will display the HTML code for the webpage. Check for hardcoded strings, hidden strings or hints left in comments. Also, check for JavaScript files for additional client-side activity. JavaScript can be either included as a separate file or in the HTML file itself by using a special tag (<script>). As an alternative, you may utilize the inspect functionality to view the webpage’s header source. The page may be accessed by right-clicking it and choosing “Inspect“. It’s important to check the CSS files as well, as they can contain links to other files or potential hints.

Attempt to identify what web server/programming language/backend is being used? This will allow for the discovery of vulnerabilities. The programming language can be identified by changing the extension on the main page of the app. Try various extensions like:

  • index.php
  • index.cgi
  • index.html

To validate this, check and explore the 404 page that is generated. This can also be useful to determine what server is being used. Try to browse to a non-existent URL like /THIS_PAGE_DOESNT_EXIST to see what comes up. On Apache/NGINX servers, default 404 pages can leak which OS is used, as well as the server’s version. At this point, if it is still not possible to determine what backend is running, check the headers of the HTTP responses for the server header. Burp Suite can be used to analyze both the source code and the request/response headers.

Check for for common files/folders, such as

  • /robots.txt
  • /.git/ (Git repository)
  • /.svn/ (Subversion repository)
  • /.hg/ (Mercurial repository)
  • /admin
  • /login

There are tools (dirb or DirBuster) that can automate the process to directly traverse the website looking for helpful information that can be exploited.

Scanning

Scan the web application/web server for known vulnerable services, weaknesses or misconfigurations. Common vulnerability scanning tools are

Gaining Access

Gain access to the backend web server by exploiting previously discovered vulnerabilities or weaknesses. This is achieved by creating a reverse shell to the web server or using vulnerabilities (see above) to gain access.

Tools that can be used to gain access:

Escalate Privileges

Exploit a bug, design flaw, or configuration oversight in the operating system or software in the website application to gain elevated access to resources normally protected from the website or the normal user. There are different techniques used to perform privilege escalation. These techniques mainly do not require specific tools to execute but a rather good knowledge of the system within which the website is hosted in order to perform the privilege escalation.

Techniques:

  • Enumeration: gather and exploit critical system information that can help them gain a further level of access to the system.
  • Kernel Exploits: some Linux legacy kernel versions are excluded from security patches. Discovering vulnerable kernel versions would only require compiling and running an exploit to gain further access.
  • SUDO Right Exploitation: exploit a user’s SUDO access in Linux systems to gain account administrator root privileges.

Write-ups

Write-ups of Web Exploitation CTF Challenges:

Tools and Resources

Web exploitation is a vast topic, for more information please visit PortSwigger’s Web Security Academy.

For exposure to OWASP Top Ten web vulnerabilities, check out the OWASP Juice Shop.

Practice

The following TryHackMe rooms offer practical exercises to grasp the topics discussed above.