Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Homograph attack (Security) #84

Open
zxlin opened this issue Sep 11, 2019 · 2 comments
Open

Homograph attack (Security) #84

zxlin opened this issue Sep 11, 2019 · 2 comments

Comments

@zxlin
Copy link

zxlin commented Sep 11, 2019

Issue

This lib, even the Github viewer itself, is vulnerable to a homograph attack - meaning that we can leverage a seemingly innocent link e.g. http://ebаy.com to redirect users to actually http://xn--eby-7cd.com

Imagine if a user posts a link like this into a forum and has other susceptible users click on it.

Homograph normalized: http://ebаy.com (hover over the URL to see the browser decode the URL)

Actual equivalent IDN (punycode): http://xn--eby-7cd.com

Further reading

https://en.wikipedia.org/wiki/IDN_homograph_attack

Potential remediation

https://en.wikipedia.org/wiki/IDN_homograph_attack#Defending_against_the_attack

We can leverage punycode (https://en.wikipedia.org/wiki/Punycode) to display the URL instead of the normalized URL. This could be a configurable option for the lib so the user of the lib can choose their risk profile. But I would recommend setting the use of punycode to true by default so we can avoid the security issue as described.

https://www.npmjs.com/package/punycode is a popular lib for JS.

Originally reported by @Mik317 to our security program

@Mik317
Copy link

Mik317 commented Sep 11, 2019

Hi :),
I know some platforms doesn't care about this risk because they have further checks on external redirections (Github it-self adds this issue as out of scope), like redirection banner and similar, but this issue is mostly fixed and accepted as valid, due to the fact it's possible to fight them via a secure implementation, and not via any browser defense.

In my bug hunter's experience, I got always fixed this type of issue (also other researchers... https://hackerone.com/hacktivity?order_direction=DESC&order_field=popular&filter=type%3Apublic&querystring=homograph sees mostly this issue fixed), so I suggest you to do the same, as it's a bad behavior that can be avoided without lots of changes :)
Let me know if you need any help in fix retest and I'll be happy to help you :)

Best, Mik

@nodabladam
Copy link

I believe the manual workaround is

import punycode from "punycode";
...
const componentDecorator = (href, text, key) => (
   <a href={href} key={key} target="_blank" rel="noopener">
      {punycode.toASCII(text)}
  </a>
);
...
<Linkify componentDecorator={componentDecorator}>
   ...
</Linkify>

saghul added a commit to saghul/jitsi-meet that referenced this issue Sep 25, 2020
Decode URLs using punycode when rendering, so when http://ebаy.com is sent
we render http://xn--eby-7cd.com/ instead.

Ref: tasti/react-linkify#84
saghul added a commit to jitsi/jitsi-meet that referenced this issue Sep 25, 2020
Decode URLs using punycode when rendering, so when http://ebаy.com is sent
we render http://xn--eby-7cd.com/ instead.

Ref: tasti/react-linkify#84
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants