Fun little CSS injection turned full-read SSRF thanks to an (imo) overly powerful PDF generator.

Getting into it, the CSS injection was straight forward, there was a configuration option for the color of text, this color was reflected directly into the page’s CSS (for the PDF). The value was reflected into the color property with minimal sanitization. The sanitization was enough to prevent breaking completely out of the CSS <style> tag though, but they could inject other properties. Playing with that they first discovered a blind SSRF, any url(...) directive would be fetched by the PDF generator allowing them to cause a request but not get much information back.

The PDF generator in use had useful feature though, prince-pdf-script a CSS property intended to be used to include JavaScript to be run when the PDF was opened. They didn’t actually have much luck getting JavaScript to run, but it supported using the url(...) directive to specify the location of the JavaScript file. The file’s contents would then be included as a JavaScript object inside the PDF, even if it wasn’t JavaScript. This allowed for reading local files, and making requests to remote hosts with full disclosure of the body. They used this to to find and query internal APIs and have the bug triaged as a critical.

I also want to shout out their first failed attempt to use the blind SSRF. They tries to disclose whether or not domains were up/down by doing a sort of timing attack based on the image loading time and time between requests. It turned out to inconsistent to use, but was a cool idea.