Reflected XSS into a JavaScript string with angle brackets HTML encoded
The following is my documentation on PortSwigger’s Academy labs.
End goal: Perform a cross-site scripting attack that breaks out of the JavaScript string and calls the alert function
Remember when we did this? Well this lab has accounted for our previous method of calling the alert function by placing our search queries into a JavaScript string. Before we continue, let’s have the recipe before the background.
Reflected XSS into a JavaScript string with angle brackets HTML encoded
𓌉◯𓇋 Servings: 1
𓎩 Prep Time: 5 Minutes
𓐐 Calories: ∞
Print
Directions
- Submit a string into the search box, in this case, we’ll use “1nfornography”.
- Once entered, inspect our page and look at the source code. Notice now that our string query has been reflected inside a JavaScritp string? Let’s break out of it!
- Combine your ingredients and place the following payload into the search box:
- Observe as our recipe calls up an alert
- Serve. Congratulations! The lab has been solved! Add salt to flavor.
There we have it, the recipe, but a good chef needs to know why the ingredients work together to cook them properly, so let’s break it down…
When inspecting the source before we entered the payload we observed the following under the script tag: var searchTerms= ‘1nfornography’ ; Notice that our search term is now in a quoted string? Our payload, ‘-alert(1)’ takes advantage of the fact that it is already under a script tag, it just needs to break out of those single quotations to be read as a script function. We do this by single quoting it itself to do so. This does something tricky, see, the first quotation in ‘-alert(1)-‘ closes out the quotation automatically placed onto our search term by the page. Likewise, the second quotation at the end of our payload is then closed out by the other quotation automatically placed onto it. Now when we look at the backend we see this:
See how our payload is now ‘ ‘-alert(1)-‘ ‘ ? We’ve successfully neutralized the quotations—with quotations. The script tag now recognizes our alert function.
Possible prevention methods:
According to PortSwigger “Some applications attempt to prevent input from breaking out of the JavaScript string by escaping any single quote characters with a backslash. A backslash before a character tells the JavaScript parser that the character should be interpreted literally, and not as a special character such as a string terminator.”1 However, if the application fails to escape the backslash character itself we can effectively do the same thing we did today, but by swapping out our quotations with backslashes. I suspect that we will run into this scenario in later labs. I recommend this PortSwigger page for more advice on how to properly prevent XSS attacks.
Notes
This is the last “apprentice” level lab for XSS attacks and I am eager to start on the “practitioner” level. Though I have completed all of the SQLi labs, I may return to a few if only to document them as I have here as writing these posts greatly helps my comprehension of the material. I have a habit of taking a bit and running with it too long, so I am weary (and you should be too) that I may write these like a recipe again.
I used the following resources in this exercise:
- PortSwigger’s XSS Cheat Sheet
- Lab solution
- Countless hours of griefing my Chefs while on the line
- PortSwigger “Cross-site scripting contexts” ↩︎
Filed under: Cybersecurity,Pentesting,PortSwigger Academy,XSS attack - @ December 21, 2023 11:48 am