This might prevent people posting links into posts. I think Reddit has been doing this for ages.
Would this be possible? Or do people think that this unnecessary as there haven't been any attempted scams?
Here's on link to a site:
Here's a malicious link to another site that looks like the first:
Although the two links appear to be the same, if the user clicked on the second link, they'd be taken to a site that I've just made up to show the problem (www.thisisascamsite.com)
If you click on the two links you'll see what I mean.
Could SN prevent the obfuscation of links to prevent spam and protect users?
Maybe I'm wrong. I've got a page not found on the second one. So links are safe @k00b ?
reply
No, you are right, this is indeed possible:
This is my markdown:
[www.duckduckgo.com](http://www.thisisascamsite.com/)
Not sure what you tried with your markdown.
Good catch. I'll create an issue for that when I woke up.
reply
reply
Also, if you find anything else that someone could abuse, please follow our responsible disclosure policy: https://stacker.news/faq#responsible-disclosure :)
No worries if you didn't know, but now you know ;)
reply
Should I delete the post?
reply
Nah it's fine
reply
Sure đź‘Ť
reply
Does reddit add a redirection warning or do they not allow formatting a link as a markdown link?
reply
I thought the latter. But I'd really ask someone who knows better than me. I just landed lucky on this one!
reply
I always check the url syntax by hovering mouse on it, before I click on it.
Don't trust. Verify. :))
reply
Good observation.
This app might be interesting too. No malicious link. Just a link to the GitHub hehe: URLCheck (Allows analyzing (or sharing) URLs before opening them.) https://github.com/TrianguloY/UrlChecker
reply
Isn't this how the web is meant to work (hypermedia)? And also a normal markdown feature?
I've been using this and it is very helpful to keep the texts clean.
Perhaps a better approach would be a notification after clicking the links, telling the user he is leaving SN and being sent to X (where X is the real place he is being redirected to).
reply
Perhaps a better approach would be a notification after clicking the links, telling the user he is leaving SN and being sent to X (where X is the real place he is being redirected to).
Adding a redirection warning for every link would be detrimental to UX, I think. I think the better solution is to prevent formatting links as markdown links. So if something is already a link, you can't use the []() syntax.
I noticed Github is also vulnerable to this.
reply
I'm not sure I would caracterize this as a vulnerability, this is exactly how markdown is supposed to work and the web is supposed to work. I don't see websites being marked as vulnerable because someone includes:
<a href="https://website2.com">https://website1.com</a>
Anyhow, it doesn't hurt to forbid urls in the [] part of [](). I think it is reasonable compromise.
reply
I would consider it a vulnerability since it can be abused by attackers.
In your example, as long as the input is trusted, I would also not mark the website as vulnerable. However, if the input is controlled by users and thus not trusted (as is the case here), the website would be vulnerable to phishing attacks.
For example, read more here:
An open redirect vulnerability occurs when an application allows a user to control a redirect or forward to another URL. If the app does not validate untrusted user input, an attacker could supply a URL that redirects an unsuspecting victim from a legitimate domain to an attacker’s phishing site.
Another example would be if our Markdown engine would not already sanitize the () part, XSS would be possible using this: [https://stacker.news/items/194732](javascript:alert(1))
The () part is fortunately replaced with javascript:void(0): https://stacker.news/items/194732
Github just doesn't apply the formatting in this case.
So I don't think it's a big difference between XSS like this and allowing malicious links to consider something a vulnerability or not.
reply
deleted by author
reply
deleted by author
reply