A collection of raw exercises ideas, before they are refined and inserted in user stories.
Path Traversal | OWASP Foundation
Website Structure: Suppose we have a simple website structure with the following directories:
/home/ (contains user home directories)/public/ (publicly accessible files)/server/ (server-related files)/admin/ (admin-related files)/
|-- home/
| |-- user1/
| |-- ...
|
|-- public/
| |-- index.html
| |-- about.html
| |-- user_uploaded_file.txt
| |-- ...
|
|-- server/
| |-- secrets/
| |-- flag.txt
|
|-- index.html
|-- about.html
|-- contact.html
|-- files.php
Target File:
The sensitive file we want to access is located at: /server/secrets/flag.txt
Website Description:
The website allows users to access certain public files.
The website employs a simple mechanism to serve files based on user requests. The URL structure might look like this: http://example.com/files.php?file=user_uploaded_file.txt
Attack Description:
The potential vulnerability lies in improper input validation, allowing an attacker to manipulate the input and traverse beyond the intended directory structure.
Suppose an attacker discovers that the website is vulnerable to path traversal. Instead of requesting a file in the public directory, the attacker may craft a malicious request:
<aside>
💡 The exercise is to craft the query:
http://example.com/[][][][][][]
Blocks:
files.php ? file= ../ ../ server/ secrets/ flag.txt
Solution:
http://example.com/files.php?file=../../server/secrets/flag.txt
Tip: start from the end
</aside>
Website Description:
Imagine a simple login system where users can log in with their username and password: the login functionality is implemented using SQL queries to check user credentials against a database.
Target:
The goal is to bypass the login mechanism and gain unauthorized access by exploiting SQL injection vulnerabilities.
Website Structure:
The website has the following components:
http://example.com/login.phpusers containing columns username and password.The login system is vulnerable to SQL injection, and the injection point is the user input fields for username and password.
The login query is something like:
SELECT * FROM users WHERE username='$username' AND password='$password';
The website does not properly validate and sanitize user inputs, allowing an attacker to manipulate the SQL query.
Craft a SQL Injection Attack:
Assume that you already know a valid username (e.g., admin, arthur, giacomo) but you need to bypass the password check: your goal is to bypass the login and gain unauthorized access.
<aside> 💡 The exercise is to craft the post request payload for the password field: SELECT * FROM users WHERE username='$username' AND password='$password';
Username: admin
Password: dropdown between:
OR '1'='1';' AND 1=1 --' OR 1=1 --AND '1'='1'; --The login query processed if the attack is correct is:
dropdown between:
As a result, the query returns *True *****and the user logs in as {dropdown between: arthur, admin, giacomo}
</aside>
pytest: helps you write better programs — pytest documentation
Website Structure: Suppose we have a simple python project with structure:
/
|-- src/
| |-- calculator.py
| |-- ...
|
|-- tests/
| |-- test_calculator.py
| |-- ...
File to be tested:
And suppose we want to write unit tests for these functions:
# calculator.py
class Calculator:
def add(self, a: float, b: float) -> float:
return a + b
def multiply(self, a: float, b: float) -> float:
return a * b
def subtract(self, a: float, b: float) -> float:
return a - b
def divide(self, a: float, b: float) -> float:
if b == 0:
return 0
return a / b
Test Description:
We are building our testsuite with pytest. Place the blocks in the correct order to make it work properly:
# test_calculator.py
from calculator import Calculator
class TestCalculatorMultiplication:
def test_multiplication_with_positive_numbers(self):
calculator = **[-------]**
output = calculator.multiply(2, 5)
assert output == 10
def test_multiplication_with_negative_numbers(self):
calculator = Calculator()
output = **[----------------------]**
assert output == **[---]**
def test_multiplication_with_negative_and_positive_number(self):
calculator = Calculator()
output = **[----------------------]**
assert output == **[---]**
class TestCalculatorDivision:
def test_division_with_positive_numbers(self):
calculator = Calculator()
output = calculator.divide(10, 2)
assert output == 5
def test_division_with_negative_numbers(self):
calculator = Calculator()
output = **[----------------------]**
assert output == **[---]**
def test_division_with_negative_and_positive_number(self):
calculator = Calculator()
output = calculator.divide(24, -6)
assert output == -4
<aside>
💡 Blocks in the right order (to be present as shuffled):
Calculator()
calculator.multiply(-3, -5)
15
calculator.multiply(4, -6)
-24
calculator.divide(-15, -3)
5
</aside>
In this beginner-level exercise, students will match fundamental unit testing concepts with simple scenarios related to a basic website. The goal is to introduce the core ideas of unit testing in a very easy-to-understand format.
Match each basic unit testing concept in the left column with the correct scenario for a simple website in the right column. Drag and drop each concept to its corresponding match.
A. A tool used to execute your test cases. B. A collection of several test cases. C. A single scenario to test a specific function of the website. D. Checking if the website's output matches the expected result. E. Setting up a simulated user environment before running each test.
<aside> 💡
</aside>
Welcome to Mission 5
In this mission, you will explore SQL injection UNION attacks, a common technique used by attackers to manipulate and retrieve data from a database.
SQL injection occurs when an attacker can inject malicious SQL code into a query, potentially leading to unauthorized access or data disclosure. UNION attacks specifically involve injecting a SELECT statement to combine results from two or more queries.
Your goal is to understand how SQL injection UNION attacks work and how to prevent them by implementing proper input validation and parameterized queries in your applications.
🔗 Useful Resource: OWASP SQL Injection Prevention Cheat Sheet
Note: Be cautious when practicing SQL injection, and only perform these exercises in controlled environments or with explicit permission. Unauthorized SQL injection attempts on real-world websites are illegal and unethical.
The database consists of a table named real_data and we want to know what’s inside it.
<aside>
💡 You have a vulnerable query
**SELECT** * **FROM** dummy_data **WHERE** **id**='<user_input>'
If you input 1 it gets back: 1, dummy value1, 3, another_value1, lollo, 4
</aside>