Better Exfiltration via HTML Injection | by d0nut

This is a story about how I (re)discovered an exploitation technique and took a bug with fairly limited impact to a 5 digit bounty by bypassing existing mitigations.

André Baptista and Cache-Money were working on a very strange bug. It started off as a simple character-set bypass and through a crazy series of steps evolved into HTML injection somewhere else in the target (not full-blown XSS, though, due to DomPurify). It was a cool chain and they could tell they were onto something big, but the next step was giving them a fair bit of trouble.

After hearing about the progress they made, I jumped in to see if I could offer any assistance in escalating this bug. At this point, we determined the worst we could do was a fairly effective clickjacking attack. 0xACB (Andre) and Cache-Money had a beautiful idea on how to chain a couple more attacks together to potentially achieve a high impact vuln, but I had different ideas.

After we determined that DomPurify allowed style tags by default, I became fairly interested in how we could leverage CSS to do more than just manipulate the DOM. If you’ve read some posts of mine already, you’ll know that I’m no stranger to CSS injection exploitation. Unfortunately, this page both had frame protection and required some user interaction to trigger the injection. It seemed that if we wanted to exfiltrate something sensitive it would take a long time (over the course of many days) to perform the leakage. Of course this is a fairly weak, error-prone attack and would, at best, yield a low 4 digit bounty on this target.

I needed a way to get the browser, without reloading, iframes, or additional user interaction, to reevaluate multiple CSS payloads to make an attack like this work. Additionally, we had limitations on the length of the payload we could inject setting us back even further. It didn’t really seem possible to exploit this using just a