Bypass WAF to perform XSS?

Question

I am trying to find an XSS in website protected by Cloudflare. I use Burp to find which HTML tags allowed.

Only the <script/> is tag disallowed. I tested multiple payloads to pass the WAF and this one is not blocked:

<img src=ddd onerror=alert%26%230000000040"1")>

The payload is inserted inside a <li> HTML tag (list) with another arabic text. How can I escape or close it to trigger an alert error? When I check the source code I found that my payload is reflected in four places:

When I read about &lt and &gt they are some kind of char filters so I url encode my payloads to this:

%3Cimg%20src%3Dddd%20onerror%3Dalert%26%230000000040%221%22%29%3E

Then run it, but I still did not get an alert, but bypassed &lt + &gt.

How can I exploit it?

Just as a suggestion and not so much a technical comment / recommendation but personally when I execute security assessments or penetration tests and discover a WAF, I abort my assessment. All you're doing is testing the WAF and not so much the application itself, it's a waste of time and money. — Jeroen, Nov 29 '21 at 17:40
Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. — Community, Nov 29 '21 at 22:46
Bypassing cloudflare's WAF is trivial (an extra parameter just called `on` before the actual event handler will do it). Bypassing the HTML output encoding is a different matter entirely! I have no idea why you think you've achieved that; you haven't. Every one of those screenshots shows the output being encoded correctly (safely). — CBHacking, Dec 27 '21 at 21:41

score 3 · Answer 1 · edited Dec 27 '21 at 22:37

The source snippets you shared show that the application is properly encoding the brackets and other characters needed for this XSS attempt to work, so even though the keywords onerror and alert are making it through the filter, the XSS won't work this way from what you have shown us. The inspection screen shows the decoded text because the DOM Inspector shows a view of the DOM, not the source code.

score 1 · Answer 2 · edited Dec 27 '21 at 22:37

To build off of @mcgyver5's answer: although you won't be able to directly get a XSS payload working like in your examples, you may be able to get one working if they handle the escaped characters improperly. Certain aspects of JS do not respect HTML character encoding (escaping). As a basic example for you, imagine that your payload is <img src=x onerror=alert(1)> and that gets escaped and placed into a <div>, like this:

<div id="test">
    &lt;img src=x onerror=alert(1)&gt;
</div>

Now, @mcgyver5 is absolutely correct in that the escaping of the your payload will prevent your XSS payload from executing; however, it is completely contextual whether it will, thereafter, get executed. For example:

<div id="test">
    &lt;img src=x onerror=alert(1)&gt;
</div>
<script type="text/javascript">
            const userContent = document.getElementById('test').innerText;
            document.getElementById('test').innerHTML = userContent;
</script>

In the above example, your XSS payload will execute just fine. Why? Because the developer, in this example me, gathered your HTML encoded XSS payload with innerText, which does not respect HTML encoding (it will extract your payload as the original string you supplied the site with). Then, the developer (me) reassigned that div with innerHTML, which will then execute your XSS. So, just as a FYI, if you dig deeper you may be able to get XSS working leveraging developer JS mistakes.

Bypass WAF to perform XSS?

2 Answers2