You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When sending http(s) links containing a login credential portion in a chat (ie https://login@website.com/) the full link is highlighted, and we can use this to trick a user into thinking the link points to a different website than the one he is going to go if he clicks on the link (eg. https://google.com@tricked.com ).
See this screenshot as an example :
As you can see, I intentionally used a long URL looking like a product page from Amazon, with some tracking information in the URL. The typical URL a user might paste in a conversation. But if you look closely in the bottom left, this link will in fact open the Rick Roll video on Youtube.
For info, here is the text used : https://www.amazon.fr∕Expert-Python-Programming-practices-programming∕dp∕1789808898∕ref꞊sr_1_5&dchild꞊1&keywords꞊python+programming&qid꞊1624472662@youtu.be/dQw4w9WgXcQ
Additionally, the hyperlink detection algorithm sometimes behaves very weirdly and I managed to make it interpret and delimit links in very wrong ways - but those just result in erroneous hyperlinks, so I'm not very worried about them.
Steps to reproduce
Send a http(s) URL containing a login credential information.
What should happen instead
I'm not sure if this would be considered a vulnerability, but it sure is a thing that could lead to phishing.
I noticed when trying to do the same thing on Discord, all the login credential part of the URL is stripped away. I think a good middle-ground would be to specifically highlight the login credential part and the URL part of the link differently, so that the user can understand where the real URL is.
The most extreme way would be to not interpret such strings as hyperlinks.
Version information
Platform: Tested on Web (probably the same in application)
Browser: Chrome will open the link without any warning, Firefox at least warns the user that the link he just clicked is trying to log them in to the website using a login (and display this login, which is the fake URL part
The text was updated successfully, but these errors were encountered:
I literally just realized the [hyperlink_text](https://google.com) syntax is allowed... which makes this issue a non issue because anybody can use anything as the text part of the hyperlink.
Can a maintainer delete this issue entirely, or close it ?
Description
When sending http(s) links containing a login credential portion in a chat (ie https://login@website.com/) the full link is highlighted, and we can use this to trick a user into thinking the link points to a different website than the one he is going to go if he clicks on the link (eg. https://google.com@tricked.com ).
See this screenshot as an example :
As you can see, I intentionally used a long URL looking like a product page from Amazon, with some tracking information in the URL. The typical URL a user might paste in a conversation. But if you look closely in the bottom left, this link will in fact open the Rick Roll video on Youtube.
For info, here is the text used :
https://www.amazon.fr∕Expert-Python-Programming-practices-programming∕dp∕1789808898∕ref꞊sr_1_5&dchild꞊1&keywords꞊python+programming&qid꞊1624472662@youtu.be/dQw4w9WgXcQ
Additionally, the hyperlink detection algorithm sometimes behaves very weirdly and I managed to make it interpret and delimit links in very wrong ways - but those just result in erroneous hyperlinks, so I'm not very worried about them.
Steps to reproduce
What should happen instead
I'm not sure if this would be considered a vulnerability, but it sure is a thing that could lead to phishing.
I noticed when trying to do the same thing on Discord, all the login credential part of the URL is stripped away. I think a good middle-ground would be to specifically highlight the login credential part and the URL part of the link differently, so that the user can understand where the real URL is.
The most extreme way would be to not interpret such strings as hyperlinks.
Version information
The text was updated successfully, but these errors were encountered: