HTML Injections -1: Adding a Vulnerable Code

Walkthrough Documentation: Understanding How Vulnerabilities Are Introduced and Exploited in a Web Application

Introduction

This guide follows the steps demonstrated in the video, explaining how vulnerabilities are introduced into a web application, how they are later exploited, and the security risks that arise from poor coding practices. The focus is on understanding how PHP and HTML work together, how user input is processed, and where weaknesses can occur.

Video Reference:

https://www.youtube.com/watch?v=twH-Sfcgzpw

Step 1: Setting Up the Vulnerable Code

The instructor starts by modifying index.php to introduce a vulnerability.

1. Navigating to the Target Web Application

• The instructor accesses YourBank.com, a simulated banking website.

• They minimize the browser and open WinSCP to access the server files.

2. Finding and Editing the PHP Script

• Inside the lab4 directory, they locate a PHP script that contains embedded HTML.

• They open index.php and modify the action attribute in a form.

What the Action Attribute Does

html

CopyEdit

<form action="display_name.php" method="POST"> <input type="text" name="username"> <button type="submit">Submit</button> </form>

• This form sends the inputted username to display_name.php when submitted.

• This change introduces a vulnerability, as the page will later display user input without proper validation.

Step 2: Running the PHP Script and Observing the Output

1. Refreshing the Page to Apply the Changes

• The instructor refreshes the browser to load the modified index.php.

• They enter the username "Alice" and submit the form.

2. Observing the Results

• The username Alice is displayed on the webpage.

• This confirms that display_name.php takes user input and outputs it directly onto the page.

Step 3: Understanding the Page-to-Script Relationship

The instructor performs a page-to-script comparison, explaining how the HTML and PHP interact.

1. Understanding How the div Element Positions the Output

html

CopyEdit

<div style="text-align: right; width: 95%;"> <?php echo $_REQUEST['username']; ?> </div>

• The <div> aligns content 95% to the right, making "Alice" appear on the right side.

• The PHP script inside it retrieves and echoes user input.

2. The Role of $_REQUEST

• The $_REQUEST['username'] function grabs the submitted username from the form.

• This displays user input directly onto the page, making it vulnerable to exploitation.

Step 4: Identifying and Exploiting the Vulnerability

Since display_name.php does not validate or sanitize input, it becomes vulnerable to Cross-Site Scripting (XSS).

1. How an Attacker Would Exploit This

Instead of entering "Alice", an attacker could enter:

html

CopyEdit

<script>alert('Hacked!');</script>

If the PHP script blindly echoes user input, this would execute JavaScript in the browser.

2. Why This is Dangerous

• Attackers could steal cookies, redirect users to malicious sites, or inject keyloggers.

Step 5: Redirecting and Persisting Data Across Pages

The instructor explains how users who register are redirected and how their usernames persist.

1. The Registration Process

• Users register on a separate page.

• They are redirected back to index.php.

• The username field remembers the value using the same token ID.

How This Works in PHP

php

CopyEdit

<?php if (isset($_REQUEST['username'])) { echo $_REQUEST['username']; } else { echo "Please log in again"; } ?>

• If the form has been submitted, it displays the username.

• If not, it prompts the user to log in again.

Step 6: Copying and Editing the Code

The instructor then:

1. Copies the modified script.

2. Pastes it into index.php under the <body> tag to apply the changes.

3. Adjusts the action attribute again to point to checklogin.php.

What Happens Next

• Instead of displaying input, the form now sends data to checklogin.php, likely introducing a new authentication step.

Security Risks and Exploits

The instructor explains how this setup can be exploited if security measures are not in place.

1. Cross-Site Scripting (XSS)

🚨 Vulnerability:

• Since user input is printed directly onto the page, attackers can inject malicious JavaScript.

🔴 How an Attacker Would Exploit This:

• Entering <script>alert('Hacked!');</script> would execute JavaScript in the browser.

• Attackers could steal session cookies or inject phishing content.

✅ Prevention:

php

CopyEdit

echo htmlspecialchars($_REQUEST['username']);

• This escapes special characters, preventing JavaScript execution.

2. Session Hijacking

🚨 Vulnerability:

• If usernames are stored in URLs, attackers can modify them to impersonate others.

🔴 Example Exploit:

• A URL like yourbank.com/index.php?username=Alice could be modified to:

  pgsql

  CopyEdit

  yourbank.com/index.php?username=Admin

• If the site blindly trusts this data, an attacker could spoof another user.

✅ Prevention:

• Use sessions ($_SESSION) instead of passing data in URLs:

  php

  CopyEdit

  session_start(); $_SESSION['username'] = $_POST['username'];

3. SQL Injection (If Usernames Are Stored in a Database)

🚨 Vulnerability:

• If the checklogin.php script does not use prepared statements, attackers could manipulate database queries.

🔴 Example Exploit:

• Entering ' OR 1=1 -- as the username in a vulnerable login form could bypass authentication.

✅ Prevention:

• Use prepared statements:

  php

  CopyEdit

  $stmt = $pdo->prepare("SELECT * FROM users WHERE username = ?"); $stmt->execute([$username]);

Conclusion

This walkthrough explains:✅ How vulnerable code is introduced through improper input handling.✅ How XSS can be used to exploit web applications.✅ How passing user data between pages introduces risks.✅ How attackers could manipulate authentication.

Final Thoughts

🔹 Developers should always sanitize user input before displaying it.🔹 Session-based authentication is safer than storing data in URLs.🔹 Prepared statements prevent SQL Injection attacks.