Possible security concern with <img src="data64... >

[tengkuizdihar]

I'm creating a local note application. My goal is to locally store images so it can be viewable even when the original src=<http url> is dead. Currently I'm doing it by fetching the image with GET from a URL, getting the actual binary for the image, then presenting it to the browser. You can see it the implementation in url_to_file function in my PR.

Should I be concerned that the data being put in my data64 thingy is malicious? Can it be a whole can of worms of XSS? Is there any unnoticed vulnerability in my PR?

The PR related to this question: https://codeberg.org/solver-orgz/treedome/pulls/92

[simonhyll]

I'm just some random guy online, research my answer before you rely on it and assume I'm one of the hackers trying to lull you into a false sense of security so I can later exploit your app:

If the URL goes to an SVG file those can potentially execute javascript. To mitigate this vulnerability make sure you set up CSP that prevents execution. However, since you're saving the image and serving it from your own site CSP probably won't be sufficient. The best way to mitigate this for you I feel would be to wrap the img tag in an iframe, allowing images to work as per usual without the security issues. It's usually the simplest solution for external content that can't be validated using regular CSP tactics like checksums and nonce values.

This XSS attack is primarily relevant for SVG files and an alternative way of guarding against attacks would be to sanitise the image before saving/displaying it by scanning it for included javascript.

This is the only way I know of that your approach might be exploited, the URL going to a malicious SVG, you data64 it, serve it from a place that your CSP settings allow script execution in.

[tweidinger]

In Tauri's case the answer is a bit more nuanced for the upcoming 2.0 version and wrapping into an iframe might not be the catch-all solution in all cases. The new IPC is way faster but has issues understanding origins of messages beyond windows.

Following the linked PR, I think you came up with a reasonable approach of sanitizing. I can recommend https://github.com/cure53/DOMPurify for handling the untrusted images, as most of the web trusts this library.

Additionally, I can recommend Simon's approach of using an iframe wrapping all/each image with additionally disabled script execution but this will cause background aware svgs (adapting to dark/light theme) to stop working.