debug tips

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.

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")`.

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!