The lab

Here is how PortSwigger describes it

This lab contains a reflected cross-site scripting vulnerability in the search query tracking functionality. The reflection occurs inside a JavaScript string with single quotes and backslashes escaped.

To solve this lab, perform a cross-site scripting attack that breaks out of the JavaScript string and calls the alert function.

The last lab dropped our input inside an HTML tag, but this one lands it inside a JavaScript string in a <script> block, and with the obvious way out sealed off we end up climbing out one level higher than the string itself.

The idea#

This time our input is not sitting in plain HTML, it is baked into a piece of JavaScript, inside a string like var searchTerms = 'OURINPUT'. The classic way to attack that is to close the string with a single quote and then write your own code after it, turning harmless text into live JavaScript.

The catch is right there in the lab title. Single quotes and backslashes are both escaped. If we send a ' to close the string, the site turns it into \', which JavaScript reads as a literal quote character that stays safely inside the string. And if we try to defeat that by sending our own backslash first, that backslash gets doubled too, so we can never line things up to escape out. The string itself is locked.

So we stop fighting the string and look at where that string actually lives. It lives inside a <script> element, and that element is part of the HTML page. The HTML parser reads the page before JavaScript ever runs, and it has one rule that trumps everything, when it sees the text </script> it ends the script block, full stop, no matter what the JavaScript inside thinks is going on. That is the door. The quote is guarded, but the angle brackets are not, so instead of breaking out of the string we break out of the whole script.

Step 1 - find where the input lands#

I searched for logicbreaker and then hunted for that word in the page source.

there it is, sitting inside a Javascript string in a script block, something along the lines of var searchTerms = 'logicbreaker'. So whatever we type is being planted straight into running Javascript, which is exactly the kind of spot we want, as long as we can get out of that string.

Step 2 - test the quote and hit the escaping#

The natural first probe is a single quote, so I searched for test'logicbreaker to see what the site does with it.

It comes back escaped. Our ' has been turned into \', which means the quote no longer closes the string, it just becomes a quote character living inside it. Trying to cancel that with a backslash of our own does not help either, because the site doubles backslashes as well. The string breakout is genuinely dead, which is the whole point of this lab, it forces us to find another way.

Step 3 - break out of the script tag instead#

Since the quote is a lost cause, we ignore the string completely and go after the element it lives in. Here is the payload.

</script><script>alert(1)</script>

Here is why this works and what each half is doing. Our input is being reflected somewhere inside the current <script> block, and the HTML parser scans that block's raw text for a closing tag. The instant it reads our </script>, it decides the script has ended, right there in the middle of that string, because to the HTML parser a closing script tag beats any idea of JavaScript string context. That first half is not attacking the string at all, it is slamming the whole script shut from the outside.

With the original script closed, the second half is a completely fresh script of our own. <script>alert(1)</script> is just a normal script element that runs alert(1), and since the site only bothered to escape single quotes and backslashes, our angle brackets pass through untouched and the browser treats this as real markup. The page loads, the browser reaches our injected script, and the alert fires.

With this, the lab is solved!