GNOME Bugzilla – Bug 256160
Warn on faked, phishing link URI's
Last modified: 2021-05-19 11:45:37 UTC
This is not an easy thing to do, but I think it would be extremely valuable if GtkHTML when used in evolution loudly pointed out links like: <A> href="http://www.securecitibank.us/scripts/email_verify.htm">https://web.da-us.citibank.com/signin/citifi/scripts/email_verify.jsp </A> (From a well-constructed steal-your-password mail that took me a few seconds to be sure it was a fake). Note that the attacker might do things like: - Insert zero-width Unicode characters into the link text - Put comments / <span> tags, etc. into the link text - Use Unicode characters that are similar appearance to '/' But I think it should be possible to have something that makes it quite hard; (and if evolution has different heuristics than outlook, then...) A bare minimum would be to have some sort of tooltip or status-bar display of moused-over URI's, but I think assuming that the user is savvy enough to realize the problem from a subtle display is assuming too much.
evo 1.5 already displays links in status bar
we should forbid stupid users to use evo and computers and internet at all instead. ;-p
*** Bug 300424 has been marked as a duplicate of this bug. ***
...and that's exactly the problem that owen describes, there are many, many possibilities that URI's can be faked. so if we would introduce such a feature, the user itself gets more and more uncautious because he expects evolution to warn him if it's a faked link. so evolution would be guilt/responsible if the user has not been warned and offers private data. (you get the idea.) anyway, copying the comments from duplicatre bug 300424 here: An idea of a friend of mine: If Evolution receives an HTML email that contains a link like this: [a href="http://bad.guys.net/"]https://secure.paypal.com/[/a] In the case that the shown link (ie: the part the user sees) starts with http: or https: then it should check to ensure that the href URL is equal to the URL that is shown to the user. If it isn't, it should do something appropriate (like give a warning, disable the link, show the correct link URL, etc). ------- Additional Comment #1 From Ryan Lortie (desrt) 2005-04-13 04:45 UTC ------- Few things to think about: (writing htp instead of http to prevent bugzilla auto-linking) [a href='htp://death/'] htp://life/[/a] [a href='htp://death/'][span]htp://life/[/span][/a] [a href='htp://death/']h[b][/b]tp://life/[/a] etc But since 99.99% of the time there are no tags inside of a link, these are fairly marginal cases. ------- Additional Comment #2 From Luis Villa 2005-06-03 18:12 UTC ------- No comment why? This is a big feature that lots of other clients are picking up; we need to think about doing the same. snip.
*** Bug 312310 has been marked as a duplicate of this bug. ***
adding "phishing" to the summary to find this more easily.
*** Bug 316796 has been marked as a duplicate of this bug. ***
I think there's not a complexity problem. If the toString contents of the link is an HTTP URL, and if it's not URL-wise equal to the HREF of the link, show a warning. Otherwise, not. There are standard algorithms to determine if two URLs are not equal. Section 3.2.3 of the HTTP 1.1 standard says how to compare two HTTP URLs. It's pretty easy. It's also algorithmically pretty easy to flatten HTML inside an <a> tag to just get the text nodes inside.
Imagine <a href="http://paypwnedpal.com/">http://pay<size=basically-invisible>pwned</size>pal.com/</a>
Further idea on this subject... all of the major web sites have "fraud reporting" email addresses (ebay, paypal, the various banks etc etc). We could write a plugin that adds a "Report This Email as a Fraud" action to the context menus when a likely phishing attack is discovered, and makes it easy to submit it to the correct response address for the site being faked. It would compose an email for you to the correct address, with the bogus email as an attachment. The user can then review the report email, and choose to send it if desired.
The simplest solution, as already suggested, would be to pop up a warning dialog showing the actual link about to be opened. The user can be asked to skip or continue the action. Of course, the warning should be only trigerred when the link is clicked. Mouse hover is already handled in a more non-intrusive manner through the status bar message. There was a bounty for the mouse hover message which is already resolved [ref. http://lists.ximian.com/archives/public/evolution-patches/2004-January/003949.html]. Now, we additionally need to hook a warning dialog in the link_clicked signal, AFAIT. Since this part is handled by shell/mail, moving it there.
In 2.5.4 the status bar seems to be removed. This is a major problem, as now there is't even a possibility for the user to check the urls manually.
the status bar has not been removed, it's just not always displayed. you can enable it in the "view" main menu. also see bug 248425.
*** Bug 546495 has been marked as a duplicate of this bug. ***
Moving this to Mailer.
*** Bug 422709 has been marked as a duplicate of this bug. ***
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines and create a new enhancement request ticket at https://gitlab.gnome.org/GNOME/evolution/-/issues/ Thank you for your understanding and your help.