1

For generating PDFs in our web application we have a simple service that accepts a chunk of HTML from the client, wraps it in a standard template, does a couple of simple transforms (like replacing image URLs with inline base64 strings) and renders it as a PDF.

For testing and debugging it is often useful to see what HTML is getting passed to the PDF generator after the wrapping/transform step. However, I'm not entirely convinced that adding this option isn't going to expose some sort of security issue.

If a user is allowed to POST a chunk of arbitrary HTML that gets returned back to them, is there some way that an attacker could take advantage of this?

Improve this question
3
  • 3
    How aware is the user of what it sends, i.e. does she sends data might have been prepared by an attacker? Like blindly uploading some local file one got by mail or maybe upload caused by a CSRF attack? And how is the "returning back" exactly done: as inline (rendered) HTML, as the HTML source (i.e. shown as text), as a downloadable file, ...
    – Steffen Ullrich
    Jul 21, 2021 at 17:58
  • If you just want to see the HTML code return it as Content-type text/plain. That should mitigate a lot of risks as long as there are no clients involved that ignore the Content-type.
    – Robert
    Jul 21, 2021 at 18:33
  • The HTML would be returned as text/html so it is rendered on screen. Forcing it to text/plain would make it much less useful. Under normal circumstances the user doesn't have any control over what is sent, they click a button on the screen and it sends the innerHTML of a particular element. But yes there is the CSRF issue.
    – SystemParadox
    Jul 22, 2021 at 13:33

0

Reset to default

Your Answer

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

Browse other questions tagged or ask your own question.