XSS on an's security blog

Reflected XSS protected by CSP, with CSP bypass | Expert

Fri, 03 Jul 2026 13:32:16 +0800

Let’s try testing the search function. As usual, we insert our canary string and see what sticks: Unlike previous labs, this lab has CSP enabled, with very strict directives too. But just to be sure, we should test the waters to see if those directives are all bark but no bite. Let’s try a simple alert payload: Looks like the parser recognises the payload as valid HTML! But unfortunately the CSP is one step ahead by blocking every inline script instances. The good news for us is that we can assume all tags and events are not filtered.

Reflected XSS protected by very strict CSP, with dangling markup attack | Practitioner

Wed, 01 Jul 2026 10:10:16 +0800

At first, I was struggling to make use of dangling markups to obtain the CSRF token needed for exfil. What I didn’t realise is that Chrome has long banned dangling markup exploitation by essentially blocking certain characters such as angle brackets. So that’s bust.

Coming back to the problem, I first tried tinkering around the comment functionality to see what sticks. However, all the useful characters are encoded, and there are no vulnerable client-side JS vectors to bypass these unlike last labs:

Exploiting cross-site scripting to capture passwords | Practitioner

Wed, 01 Jul 2026 08:52:16 +0800

I first struggled to solve this because I was leaning towards a solution that does not require user interaction. Something like a list of autofilled passwords being defined somewhere in the DOM, tried Googling to hell and back but no budge.

Turns out I had to swallow my pride and come up with a solution that requires interaction. Turns out it’s simpler that it sounds. All you have to do is wait for the browser to fill the passwords, detect it using onchange then grab the credentials.

Exploiting XSS to bypass CSRF defenses | Practitioner

Tue, 30 Jun 2026 16:20:16 +0800

In the spirit of this problem, we can simply set up a similar payload as shown here:

<script>
setTimeout(function(){
 var token = document.getElementsByName('csrf')[0].value;
 var data = new FormData();

 data.append('csrf', token);
 data.append('email', 'hijacked@test.com');

 fetch('/my-account/change-email', {
 method: 'POST',
 body: data
 });
}, 100);
</script>

Exploiting cross-site scripting to steal cookies | Practitioner

Tue, 30 Jun 2026 14:19:16 +0800

(dont rlly like this lab because of paywall) First, to steal cookies we must know the attributes of them. By using the Developer Tool, we can see that our cookie session does not have HttpOnly flagged. This means client-side JS can read cookies via document.cookie, making our job easier.

As usual, we try to insert our canary and see what’s up: This is a bit of a logic jump but I tried inserting angled brackets and found out that it wasn’t encoded like other labs. I then attempted to insert a simple alert payload, lo and behold the parser recognises the payload as HTML. We can assume that there are no encoding filter or WAF blocks, meaning we can build our payloads no problemo.

Reflected XSS into a template literal with angle brackets, single, double quotes, backslash and backticks Unicode-escaped | Practitioner

Tue, 30 Jun 2026 13:48:16 +0800

(lab’s name is a bit of a handful)

As usual, let’s first insert our canary into the search form to see what’s the buzz:

While all our special characters are encoded thus no traditional payloads, notice that the page is trying to build the message dynamically using client-side JS. And backticks are used rather than single or double quotes, meaning we can probably inject JavaScript template literals within the message itself.

Stored XSS into onclick event with angle brackets and double quotes HTML-encoded and single quotes and backslash escaped | Practitioner

Tue, 30 Jun 2026 09:25:16 +0800

Since the only useful functionality on this lab is commenting, we begin by inserting our canary into the comment form and some special characters to see what sticks. Good practice.

While checking the source, we see that everything is HTML-encoded, even the backslash is escaped. This entry is bust.

But we haven’t checked out how our comment is rendered in Elements yet. Maybe this will lead to something interesting?

Notice that our controllable website input is reflected inside a JavaScript quoted tag attribute. We can infer that it tracks traffic to our website or something, that doesn’t matter. What matters is that we now know there is a way to break away the existing JS code and insert our payloads.

Reflected XSS in a JavaScript URL with some characters blocked | Expert

Mon, 29 Jun 2026 10:23:16 +0800

Let’s try insert our canary string into the comments, with some special characters to boot to see what sticks As reflected in the source, almost everything save for ;$%() are URL encoded, severely limiting our payload capability. Checking the HTML content in Elements also reveal that all our input is treated as text.

After much tinkering, I realised I have been focusing too much on comments while ignoring the little Back to Blog button at the end of the page. This might be interesting.

Reflected XSS into a JavaScript string with angle brackets and double quotes HTML-encoded and single quotes escaped | Practitioner

Mon, 29 Jun 2026 09:45:16 +0800

As usual, we first try to insert our canary string along with special characters to see what sticks:

Notice all of the characters are encoded, save for one trailing backslash at the end. Since single quotes are escaped, we should expect the same for backslashes and see two of them rather than one. This means backslashes are not escaped, and we can use this to our advantage.

We can insert our own backslash character before a single quote to neutralize the backslash that is added by the application.

Reflected XSS into a JavaScript string with single quote and backslash escaped | Practitioner

Mon, 29 Jun 2026 09:11:16 +0800

We first try to insert our canary string into the search form on the main page, and view the result in DOM Invader

As we can see, the canary falls into a document.write sink. Upon closer inspection of the source code, we can discover this JS snippet:

Notice that the single quote is escaped. Double quotes and angle brackets are URL encoded, evident on the query string, before being written into the HTML. But whatever input we type will be assigned to the variable searchTerms first, without any encoding save for single quotes.

Reflected XSS in canonical link tag | Practitioner

Fri, 26 Jun 2026 16:22:16 +0800

First, we’ll need to understand what are canonical tags. In HTML, it always lives in head and looks like this:

<link rel="canonical" href="https://example.com/main-site">

If example.com has many endpoints other than the main one, a search engine bot splits up the SEO ranking power, which is what dictates the visibility of a site, across all these URLs. To fix this, developers usually add a canonical tag to all those pages that points back to the main URL, which essentially means telling the search engine bot to give all visibility to the main site instead.

Stored XSS into anchor href attribute with double quotes HTML-encoded | Apprentice

Fri, 26 Jun 2026 15:40:16 +0800

After tinkering with the comment functionality, notice that the backend will directly takes whatever inside the website input box and attach it to the href anchor as shown here. One thing to note is that the http: prepend filter is not present for this lab:

So we can simply use the payload javascript:alert(1) to solve the lab. Simple

Reflected XSS into attribute with angle brackets HTML-encoded | Apprentice

Fri, 26 Jun 2026 15:13:16 +0800

As with any, we try inserting our canary into the form to see what comes. In this case we will try searching for ihvkjueb"<>& Notice that while the angle brackets are encoded, " isn’t. And we can escape the value attribute and add it this payload:

" autofocus onfocus='alert(1)'

This will autofocus the input form right after the page loads, which will trigger alert calls indefinitely.

Reflected XSS with some SVG markup allowed | Practitioner

Fri, 26 Jun 2026 14:19:16 +0800

Similar to this problem, we first try to find out which tags are allowed and which are not using Intruder as follow: The tags available are animateTransform, image, and svg. title is also allowed but it doesn’t assist much in delivering payloads so we will skip it for now.

So we are given three building blocks. One may craft a payload as follow:

<svg><image width=10 height=10 src/onerror=alert(1)></svg>

But it doesn’t work. Using animateTransform to add the event indirectly also does not work. Using other events does not work. Once again, we use Intruder to brute our way to which events are accepted and which aren’t: All but one event is blocked, and that is onbegin. It is essentially onload but for SVG animation elements. So we can craft a payload as follow:

Reflected XSS with event handlers and href attributes blocked | Expert

Fri, 26 Jun 2026 10:03:16 +0800

Similar to previous problems, first we shall pass through Intruder to see which tags are accepted Some of the valid tags are <a>, <animate>, <image>, and <svg>. This is a huge flag for an svg tags ecosystem. Since the href attribute is blocked by the WAF, perhaps somehow we can sneak that through indirectly without alerting the firewall?

The answer is using the <animate> tag, with its convenient attributeName and values attributes, it allows us to indirectly modify the parent tag’s attributes and their values. Thus we can craft a payload as follow:

Reflected XSS into HTML context with all tags blocked except custom ones | Practitioner

Fri, 26 Jun 2026 09:41:16 +0800

When we launch Intruder to zero in which tags are accepted, all of them returns a 400 which makes common payloads obsolete However, we haven’t tested for custom tags yet. Whenever we invent a tag, such as <test>, the browser treats it as an HTMLUnknownElement. In the DOM, HTMLUnknownElement is a direct child of HTMLElement interface, meaning it inherits every Global Attribute that standard HTML elements (like <div> or <span>) have.

Reflected XSS into HTML context with most tags and attributes blocked | Practitioner

Thu, 25 Jun 2026 14:59:16 +0800

If we try a standard XSS payloads using img or script, the built in WAF will block the request. We can try other tags manually, or we can use Burp Intruder to first do a sweep of which tags are accepted, and which aren’t. You can find a list of common XSS payloads on PortSwigger’s XSS Cheat Sheet Notice the only the body tag returns a 200. We shall use this information and narrow our attribute range for the tag. There are a few attributes accepted, notably being onresize. Without needing user interaction, this is a holy grail among attributes used for XSS payloads. With that said, we can craft a payload as follow:

Stored DOM XSS | Practitioner

Thu, 25 Jun 2026 14:30:16 +0800

Really took a long time with this one due to not knowing enuf JS syntax

Upon closer inspection of the source, the comment body seems to be added into an innerHTML sink for display, which is a huge red flag opening up to Stored XSS payloads. There is a peculiar custom function escapeHTML() which does as it says on the tin. It filters out < and >, effectively blocking most XSS payloads, at least in theory. This only encodes the first occurences of those two brackets, which mean our payload can simply be:

Reflected DOM XSS | Practitioner

Thu, 25 Jun 2026 09:31:16 +0800

As per the usual, when we try inserting our canary into the search functionality, the result falls into the eval sink which is very dangerous.

Upon closer inspection of the stack trace, we find out the function that manages sending our search requests. The developer here did not use JSON.parse() safely but dump the raw response text from the server directly into eval. This opens up opportunities for XSS.

To exploit this, we should think of a way to escape this JSON string. One might try to append "}, but " is safely encoded as \" so it won’t work. However, we can add another backslash, \\", the two backslashes in a row will confuse the parser and interpret this as an attempt to print a literal backslash, completely ignoring "!

DOM XSS in AngularJS expression with angle brackets and double quotes HTML-encoded | Practitioner

Wed, 24 Jun 2026 15:40:16 +0800

First, we try to punch the search functionality by inputting our canary string into the search bar. Notice that our string will be written inside the HTML source, which opens up room for XSS payloads.

There is also an ng-app attribute inside the body tag, which means when the webpage loads AngularJS will be in control of whatever inside that tag. When a directive is added to the HTML code, we can execute JavaScript expressions within double curly braces. This technique is useful when angle brackets are being encoded.

DOM XSS in jQuery selector sink using a hashchange event | Apprentice

Wed, 24 Jun 2026 15:16:16 +0800

Once we check the source for our homepage, we see that there is a peculiar JS code snippet. It is a $() selector sink that picks up whatever inside window.location.hash, then try to find an h2 element under the blog-list class containing that value.

If value is found, then it scrolls down to that. Here in our example is an h2 tag being scrolled down to, notice #Wedding in the URL. One notable thing is that the backend doesn’t filter elements such as <, >, or HTML tags such as script, img. We can try this by inserting those into the hash and view the response.

DOM XSS in jQuery anchor href attribute sink using location.search source | Apprentice

Wed, 24 Jun 2026 09:21:16 +0800

When we check out the Submit Feedback, notice that there is a returnPath query string hanging out in the URL.

If we look closer to the source code, we find out that this returnPath handles the redirect after clicking on the Back button, evident by its #backLink ID.

The JS code naively takes whatever value of returnPath inside the window.location.search sink and add that as an attribute of the a tag. We can then insert this payload inside the URL:

DOM XSS in innerHTML sink using source location.search | Apprentice

Tue, 23 Jun 2026 15:56:16 +0800

We can manually inspect the JS source, or use the DOM invader to help locate our sinks as follow:

Here our sink is innerHTML, note that the innerHTML sink doesn’t accept script elements on any modern browser, nor will svg onload events fire. This means we will need to use alternative elements like img or iframe. Event handlers such as onload and onerror can be used in conjunction with these elements.

DOM XSS in document.write sink using source location.search inside a select element | Practitioner

Tue, 23 Jun 2026 14:57:16 +0800

Upon viewing the source, we see that this script has a document.write() sink that writes out the select form in the HTML. It queries for the value of storeId param and attaches it to an <option> tag as shown.

Upon attaching a storeId query param into the URL, the DOM Invader captures our random string present within the HTML, and confirming that the sink in question is indeed document.write():

DOM XSS in document.write sink using source location.search | Apprentice

Tue, 23 Jun 2026 14:38:16 +0800

This is quite a straightforward lab, but I want to emphasize on the use of Burp Browser’s DOM Invader.

The “canary” here is pp591rlt, which is an unpredictable and uncommon string that we can inject into different sources to see which sinks they flow into. Included in the string are special characters ", <, and >. This helps test whether the browser will sanitize the quotes and brackets or not.