1

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

enter image description here enter image description here

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")>

enter image description here

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:

enter image description here

enter image description here

enter image description here

enter image description here

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.

enter image description here

How can I exploit it?

3
  • 2
    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, 2021 at 17:40
  • Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer.
    – Community Bot
    Nov 29, 2021 at 22:46
  • 1
    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, 2021 at 21:41

2 Answers 2

3

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.

1

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.