Decoding the Web: Exploring the Depths of Exploitation | CTF Newbies
Solving Web CTF enhances our skill to do bug bounty programs where we find web vulnerabilities in real world Web applications and report it. In return, either we get paid or get Hall Of Fame.
The most common Web Vulnerabilities are:
1) SQL INJECTION
SQL injection enables an attacker to manipulate the queries that an application sends to its database. This manipulation grants the attacker unauthorized access to view data within the database.
Furthermore, SQL injection can escalate to remote code execution, potentially granting the attacker control over the web server where the application is hosted.
Despite being an older vulnerability, SQL injection remains prevalent in various forms, largely due to improper sanitization of user inputs, which allows them to be directly inserted into SQL queries. It allows the attacker to create, read, update, alter, or delete data stored in the backend database.
How does SQL injection work?
Imagine a website that authenticates users based on username and password. The URL looks like this:
https://www.example.com/auth/username=user&password=mypassword
The vulnerable code on the server looks like this:
<?php
$username = $_GET['username'];
$password = $_GET['password'];
$result = mysql_query("SELECT * FROM users WHERE username='$username' AND password=’$password");
?>When this request is reached at server, if the username and password are placed in an SQL query directly without any filtering or sanitization, it will look like this:
SELECT * FROM users WHERE username='user' AND password='mypassword'
It retrieves all columns where username is user and password is mypassword.
Now if I change the URL like the following:
https://www.example.com/auth/username='&password=mypassword
The resultant query would be like this:
SELECT * FROM users WHERE username='' AND password='mypassword'
We closed the string where the username was supposed to be there.
Now if we make the URL as
https://www.example.com/auth/username=' OR 1==1 -- &password=mypassword
The Resultant query would look like:
SELECT * FROM users WHERE username='' OR 1==1 -- AND password='mypassword'
What does the ‘ OR 1==1 -- payload mean and do?
The ' closes the string literal in the query where the actual username is supposed to come. The OR operator checks whether either of the condition results is true.
The 1==1 condition is always true. So the whole where clause returns true.
The -- comments out the rest of the query.
Now what happens when the query is executed in the database?
It retrieves all columns(*) from table users where the username is TRUE (because 1==1 is always true) and comments out the rest of the query.
This way we can essentially bypass the authentication method of websites.
The above input is the most common approach used for SQLi. The injection allows the attacker to pull all the registered users from the database.
2) Command Injection
Command Injection or Remote Code Execution(RCE) is one of the most dangerous vulnerabilities that exists. It allows an attacker to run OS commands on the web server through the vulnerable web app. It allows an attacker to take complete control of the server. The attacker can read or edit files, read user information, read or edit source codes, delete important files, break the server, get internal network details, etc.
How does Command Injection work?
If a web app takes user input and executes it in a shell in the server. It could be used to execute OS commands on the server.
Imagine a web app takes an IP address as user input to test the ping on the given IP address.
The code on the server looks something like this:
import os
domain = user_input() #IP address
os.system('ping ' + domain)If the user gives an IP 10.10.10.1 as input, the command would look like this. ping 10.10.10.1
If we could add some OS commands we could execute any command on the server.
The attacker could put 10.10.10.1; ls as input, and the resultant command would look like this:
ping 10.10.10.1 ; ls
after pinging the IP, ls lists the files in the present directory
In this way, we can execute any OS commands on the server including spawning a reverse shell to our system and gaining full access to the server.
You can use a pipeline to inject the system by entering the following input into the field.
127.0.0.1;ls
After the results of PING, we can see the list of files in the current directory. (ls lists all files in the current directory)
Further, we can even spawn in reverse shell from the host server to our server.
3) DIRECTORY TRAVERSAL
It is a type of HTTP exploit in which a hacker uses the software on a web server to access data in a directory other than the server’s root directory. If the attempt is successful, the threat actor can view restricted files or execute commands on the server. Directory traversal is also known as directory climbing, backtracking and file path traversal vulnerabilities. It is similar to Structured Query Language injection (SQLi) and cross-site scripting (XSS) in that they all involve code injection.
How does directory traversal work?
Imagine a web application that serves files based on user input, such as a file download feature. The application takes a file path from the user and serves the corresponding file. However, the application does not properly validate or sanitize the input, allowing the attacker to manipulate the file path and access files outside of the intended directory.
For instance, suppose the application serves files from the directory /var/www/files/. A legitimate request might look like this:
<http://example.com/download?file=example.txt>The application would serve the file example.txt from the files directory. However, an attacker can manipulate the file parameter to access sensitive files outside of the files directory. For example:
<http://example.com/download?file=../../../../../etc/passwd>In this case, the attacker used ../ to traverse the directory structure several times and then accessed the /etc/passwd file, which typically contains user account information. If the application is vulnerable, it will serve the contents of /etc/passwd to the attacker, potentially exposing sensitive information.
Impact of a directory traversal attack
One of the significant impacts of a directory traversal attack is unauthorized access to sensitive information. By exploiting vulnerabilities in the application’s file-handling mechanisms, attackers can traverse directories and access files containing critical data such as user credentials, configuration files, or proprietary information. This can lead to severe consequences such as data breaches, identity theft, or compromise of intellectual property.
From the above example, the attacker can overwrite the sample.php file by using the directory transverse.
4) CROSS-SITE REQUEST FORGERY
Cross-Site Request Forgery (CSRF) is an attack that forces authenticated users to submit a request to a Web application against which they are currently authenticated. CSRF attacks exploit the trust a Web application has in an authenticated user. (Conversely, cross-site scripting (XSS) attacks exploit the trust a user has in a particular Web application). A CSRF attack exploits a vulnerability in a Web application if it cannot differentiate between a request generated by an individual user and a request generated by a user without their consent.
How does Cross-Site Request Forgery work?
Imagine there’s a banking website where users can transfer funds to other accounts. The website uses a simple HTML form to perform fund transfers:
<form action="<https://bank.com/transfer>" method="post">
<input type="hidden" name="amount" value="1000">
<input type="hidden" name="toAccount" value="attackerAccount">
<input type="submit" value="Transfer Funds">
</form>Now, imagine an attacker creates a malicious website and embeds the following HTML code:
<img src="<https://bank.com/transfer>" style="display:none" onload="document.forms[0].submit()">When a user who is logged into the banking website visits this malicious website, their browser automatically sends a request to https://bank.com/transfer with the parameters amount=1000 and toAccount=attackerAccount, effectively transferring $1000 to the attacker's account.
Impact of a Cross-Site Request Forgery Work
One significant impact of CSRF attacks is that they enable unauthorized actions to be performed on behalf of the victim without their knowledge or consent. Attackers can exploit CSRF vulnerabilities to trick authenticated users into unknowingly performing actions on web applications, such as transferring funds, changing account settings, or submitting forms. Since the requests originate from the victim’s browser with their authenticated session, they may go unnoticed by the victim until it’s too late, leading to financial loss, data corruption, or other adverse consequences.
5) Cross-Site Scripting (XSS)
Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser-side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.
How does a Cross Site Scripting attack work?
Imagine there’s a vulnerable website that has a search feature allowing users to search for products. The search query is displayed on the search results page without proper input sanitization. An attacker exploits this vulnerability to inject malicious JavaScript code into the search query parameter.
Vulnerable Website:
<html>
<head>
<title>Product Search</title>
</head>
<body>
<form action="/search" method="get">
<input type="text" name="q" placeholder="Search products...">
<input type="submit" value="Search">
</form>
</body>
</html>Exploited Search Query Parameter:
Suppose the attacker enters the following search query into the search field:
<script>alert('XSS Attack!');</script>Search Results Page (Vulnerable):
The search results page displays the search query without proper input sanitization:
<html>
<head>
<title>Search Results</title>
</head>
<body>
<p>Search results for: <script>alert('XSS Attack!');</script></p>
<!-- Other search results here -->
</body>
</html>When a user visits the search results page, the injected JavaScript code executes in the context of the vulnerable website. In this case, it displays an alert dialog with the message “XSS Attack!”.
Impact of a Cross-Site Scripting attack
Compromise of Sensitive Information: One significant impact of an XSS attack is the potential compromise of sensitive information. Attackers can exploit XSS vulnerabilities to steal cookies, session tokens, or other authentication credentials from unsuspecting users. This compromised information can be used to impersonate users, perform unauthorized actions on their behalf, or gain unauthorized access to their accounts and sensitive data.
How to prevent a Cross-Site Scripting attack
Preventing Cross-Site Scripting (XSS) attacks involves implementing various security measures within web applications.
- Input Validation and Sanitization:
- Validate and sanitize all user input, including form fields, URL parameters, and cookies, to ensure they do not contain malicious code.
- Use server-side input validation to enforce strict rules on input data formats and lengths.
- Sanitize output by encoding user-generated content before displaying it in web pages. Use HTML entity encoding, JavaScript escaping, or other appropriate encoding techniques to prevent the interpretation of user input as executable code.
2. Content Security Policy (CSP):
- Implement a Content Security Policy (CSP) to mitigate XSS attacks by specifying the allowed sources of content, scripts, and other resources that can be loaded by the web page.
- Utilize CSP directives such as
script-src,style-src, anddefault-srcto restrict the domains from which scripts, stylesheets, and other resources can be loaded. - Enable the
script-src 'nonce'orscript-src 'strict-dynamic'directive to prevent inline script execution and only allow scripts with trusted nonces or hashes to execute.
We could use the following payload to detect XSS in any web app:
<script>alert(1)</script>
RESOURCES
- CTF walkthroughs: Do a google search for walkthroughs or writeups of CTFs when you are unable to solve a CTF.
- Twitter Accounts of Infosec researchers: Infosec researchers often share their new research or tricks on their Twitter pages.
- Stackoverflow: Search for answers to commonly asked questions on technologies you are trying to hack.
