Tell HN: Immersive-translate plugin may expose you to XSS attacks

3 pointsby simonmysun2 anni fa5 comments

This post might not directly concern English-speaking users, but I know there are many users (at least many Chinese speaking users) browse Hacker News with immersive-translate plugin[1]. The plugin has https://news.ycombinator.com included in its default list of sites to translate.

I recently identified a potential XSS injection target. When users navigate to a specific piece of content using the plugin, malicious code could be executed by their browser. This allows the possibility of cookies being stolen or other malicious activities. I have reported in their issue tracker[2].

Example:

    <button src="/404" a button<script>alert(456)</script></button>

If you translate the above content using immersive-translate, you’ll see a popup. Moving your mouse over the translated content could trigger another popup.

Suggestions:

  - For Immersive-Translate users: Until this issue is fixed, I recommend disabling the default translation of Hacker News content and only translating content that has been manually reviewed.
  - For Hacker News admins: To mitigate this risk, you might consider adding a `Content-Security-Policy` header in the server responses or including a `<meta http-equiv="Content-Security-Policy" content="xxx">` tag in the HTML `<head>` section.

[1]: https://immersivetranslate.com/

[2]: https://github.com/immersive-translate/immersive-translate/issues/2022

5 comments

simonmysun2 anni fa

Screenshots to prove: https://imgur.com/a/vaKVo52

moritzwarhier2 anni fa

Nice advice about the CSP, but ultimately the issue is with the browser add-on?

simonmysun2 anni fa

Yes. The issue is caused by the browser add-on. Before they get it fixed, I think it's better to notify HN users who use it.

They said in previous posts that they are using `DOMPurify` to sanitize the code, but it turns out that it did not work well.

moritzwarhier2 anni fa

So I'm not informed about this particular case, but DOMPurify does work correctly AFAIK.

It's an old project though and I've always refrained from using it in favor of sanitizing user input in other ways (or letting library code do it for me).

It might be that they used this library wrong. It might also be that it's more of a research project.

There's a reason I guess that none of the popular UI frameworks/libraries have DOMPurify as a dep.

It boils down to a separation similar to prepared statements.

Disallowing direct string interpolation into DOM subtrees is the way to go, esp when user-controlled data is involved. You can't achieve XSS by assigning .textContent on a DOM node, for example.

That's why the DOM API is a thing and innerHTML is equivalent to eval regarding security.

simonmysun2 anni fa

I might have indicated it's DOMPurify's problem. Sorry I didn't mean that.

The browser add-on is unfortunately not open source and I don't want to spend a lot of time to investigate it. According an earlier issue (#1437), they should have fixed it already. I guess the later envolvements changed that.

I agree with you that what DOMPurify does should be cared of by the Browser.