From c7dc315315826a4092dda6b9b5896485513470bb Mon Sep 17 00:00:00 2001
From: Yan <yans@yancomm.net>
Date: Thu, 6 Feb 2025 00:15:16 -0700
Subject: [PATCH] debug tips

---
 web-security/xss-rf-get/DESCRIPTION.md       | 14 ++++++++++++++
 web-security/xss-stored-alert/DESCRIPTION.md | 12 ++++++++++++
 web-security/xss-stored-html/DESCRIPTION.md  |  8 ++++++++
 3 files changed, 34 insertions(+)

diff --git a/web-security/xss-rf-get/DESCRIPTION.md b/web-security/xss-rf-get/DESCRIPTION.md
index f17fc9f..eca2dad 100644
--- a/web-security/xss-rf-get/DESCRIPTION.md
+++ b/web-security/xss-rf-get/DESCRIPTION.md
@@ -5,3 +5,17 @@ This can be done in a number of ways, including using JavaScript's `fetch()` fun
 This challenge implements a more complex application, and you will need to retrieve the flag out of the `admin` user's unpublished draft post.
 After XSS-injecting the `admin`, you must use the injection to make an HTTP request (as the `admin` user) to enable you to read the flag.
 Good luck!
+
+----
+**DEBUGGING:**
+This level adds an additional bit of complexity to the injected script: the `fetch()`.
+Now, three things can go wrong:
+
+1. The `<script>` HTML injection.
+   Again, verify that using View Source or Inspect Element in the DOJO's Firefox.
+   Log in as `guest` (or modify the script so that you can log in as `admin` in practice mode) and play around graphically.
+2. The JavaScript itself.
+   Verify this by checking Firefox's JavaScript console for errors and by using print-debugging (to the Firefox console by doing `console.log`).
+3. The GET request that you'll trigger using `fetch()` or whatnot.
+   You can, again, debug this in Firefox by looking at the Network tab of the Web Developer Tools.
+   Have the tab open, trigger your attack, and see what's happening with the actual request.
diff --git a/web-security/xss-stored-alert/DESCRIPTION.md b/web-security/xss-stored-alert/DESCRIPTION.md
index 3f90ea7..4d7f81b 100644
--- a/web-security/xss-stored-alert/DESCRIPTION.md
+++ b/web-security/xss-stored-alert/DESCRIPTION.md
@@ -22,3 +22,15 @@ In the previous level, you injected HTML.
 In this one, you must use the exact same Stored XSS vulnerability to execute some JavaScript in the victim's browser.
 Specifically, we want you to execute the JavaScript `alert("PWNED")` to pop up an alert that informs the victim that they've been pwned.
 The _how_ of this level is the exact same as the previous one; only the _what_ changes, and suddenly, you're cooking with gas!
+
+----
+**DEBUGGING:**
+Here, we need a slightly more advanced approach to debugging.
+Two main things can go wrong here.
+
+1. First, you might not be injecting your `<script>` tag properly.
+   You should check this similar to the debugging path of the previous challenge: bring it up in Firefox and View Source or Inspect Element to make sure it looks correct.
+2. Second, your actual JavaScript might be buggy.
+   JavaScript errors will show up on your Firefox console.
+   Pull up the web development console in the DOJO's Firefox, load the page, and see if anything has gone wrong!
+   If it hasn't, consider resorting to print-debugging inside JavaScript (you can print to the console with, e.g., `console.log("wtf")`.
diff --git a/web-security/xss-stored-html/DESCRIPTION.md b/web-security/xss-stored-html/DESCRIPTION.md
index ef193fc..18c0507 100644
--- a/web-security/xss-stored-html/DESCRIPTION.md
+++ b/web-security/xss-stored-html/DESCRIPTION.md
@@ -31,3 +31,11 @@ You will now have a `/challenge/victim` program that simulates a victim user vis
 Set up your attack and invoke `/challenge/victim` with the URL that will trigger the Stored XSS.
 In this level, all you have to do is inject a textbox.
 If our victim script sees three textboxes, we will give you the flag!
+
+----
+**DEBUGGING:**
+How do you debug these sorts of attacks?
+The most common thing to go wrong in this simple scenario is that the resulting post-injection HTML is invalid.
+Here, the View Source functionality of your browser can help.
+You can either try launching your attack against the web browser in the DOJO's GUI Desktop (e.g., set up the XSS, then visit with the DOJO's Firefox rather than with `/challenge/victim`), and View Source, or just use curl and read the result.
+The result, after you inject your payload, should still be valid (but newly-evil) HTML!