27

Could receiving in a text or an email, a URL link just like https://security.stackexchange.com/questions/ask of a website, which could be a pernicious one, ever pose a security problem at all? What I am asking is that: if I receive such a link but do NOT click on it, will it ever do harm to my account, computer or other website I will ever visit?


Edit: As a specific example, I would like to ask about the situation for receiving a link, https://down[.]nnjah68[.]me/app.php/Mjl1to, in WhatsApp.

6
  • 3
    If the link is not shown as plain text, but processed in any way (even just to highlight it), there could be an exploitable bug in the parsing code, such as a buffer overrun. Unlikely, but possible. – dbkk Feb 8 at 21:39
  • 3
    Some apps generate previews of links. They might send some information to those websites; and the preview image/snippet could contain something you might not want to see. – Salman A Feb 9 at 9:08
  • 1
    @SalmanA To give an example if an app that does that do that: outlook's default is to show a link preview: support.microsoft.com/en-us/office/… – user2705196 Feb 9 at 17:56
  • 1
    @dbkk Adding to what you said about bugs in a URL parser, there could also be bugs in the text rendering engine, e.g. soyacincau.com/2020/04/24/… – Nayuki Feb 9 at 19:53
  • 2
    There was once a chrome bug where hovering over (or clicking) the link http://a//%%30%30 would cause the tab to crash (see superuser.com/questions/977604/… and e.g. 9to5google.com/2015/09/22/…) - this is an example of a URL-parsing bug, though I don't think it was ever exploitable in any interesting way. – Pokechu22 Feb 10 at 1:23
44

Many browsers send "pings" to any links on a page by performing a DNS query on them to populate the cache. This makes clicking the link faster because the IP is already in the DNS cache. In theory, a bug in this code could be exploitable simply because the link is there. In practice, this isn't an issue. Just because a link exists doesn't mean it can do much to you.

17
  • 3
    @Hans Yes, it is a malware analysis/detection site. It's a popular one. Obviously it does not have a 100% detection rate, however, so use it only with that limitation in mind. – forest Feb 7 at 3:38
  • 23
    wait, so my browser is phoning home to every link on every page I visit? The owner of every link I ever see gets a ping when I do? – benxyzzy Feb 7 at 13:40
  • 12
    @benxyzzy: Possibly, yes, depending on browser, version, settings, plugins, add-ons, etc. For priming the DNS cache, a simple DNS lookup would be enough and arguably both more efficient and more privacy-conscious, but OTOH, you'd miss out on redirects that way. – Jörg W Mittag Feb 7 at 20:30
  • 4
    This seems like a huge privacy issue since any link posted by anyone on a comment section (blog, news, social media or here) would be able to track all visitors. Do you have any source for this or any additional information (which browser are affected, which version, etc.) ? – zakinster Feb 8 at 8:44
  • 9
    @forest Do you have any reference for this ? The only documented behaviour I could find is link prefetching which supports dns-prefetch but it only concerns external resource links (HTML <link> tag for css, js, etc.) not hyperlinks (HTML <a> tag). – zakinster Feb 8 at 9:26
35

Some software will automatically fetch any URL it sees, even if you don't click it. A few examples:

  • Browsers that are configured to pre-fetch certain URLs so that they load instantly after clicking (this isn't default on any major browser I'm aware of, but I've seen it).
  • Messaging clients that show a preview of the page (text and/or image thumbnail) when you send or receive a message with a link.
  • Browser extensions that pre-fetch certain links to check the page for malware (part of some AV suites).

In any of these cases, a vulnerability in the HTTP client (browser, AV software, messaging app or server, etc.) could be exploited by an attacker. However, such vulnerabilities are relatively rare unless the client supports JS (it is very hard to make a JS engine fully secure, though of course the developers try) and often sandboxed to limit the damage even if they are vulnerable.

Also, note that - in an ideal world where everything works correctly - fetching a URL would always be safe (it shouldn't be possible for fetching a URL to do anything harmful) and wouldn't even be state-changing (GET should be idempotent). Obviously, the real world is not nearly so ideal, since both software vulnerabilities and websites that ignore various standards exist. However, because those things exist, and for privacy reasons (fetching a URL always exposes, at a minimum, an IP address), automatically fetching URLs is relatively rare.

Just looking at a link (without fetching/visiting it) isn't going to be dangerous unless your text rendering library has some seriously wacky bugs, and most likely they could be set off by non-link text in a situation like that anyhow.

5
  • 4
    "vulnerability in the HTTP client" – I believe you mean HTML client there, although of course the HTTP client may also have a vulnerability. While HTTP is much simpler than HTML and HTTP clients are typically well-tested, we had a rapid evolution recently with the introduction of HTTP/2, HTTP/3, SPDY, and QUIC in rapid succession, which are much younger, less mature, and less well tested than HTTP/1.1. While the server cannot force the client to upgrade to one of those younger protocols, clients do that all by themselves anyway, at least up to HTTP/2. – Jörg W Mittag Feb 7 at 20:35
  • 7
    No, I definitely meant HTTP. Although many HTTP clients are also HTML clients, the reverse is not necessarily true, see for example libcurl. Fetching a URL is 100% HTTP and 0% HTML, though rendering the result of the fetch might (or might not!) involve HTML. After all, an HTTP response can be literally any content type, most of which have nothing to do with HTML (common ones being JSON, various images or videos, any any sort of executable code in binary or script form), or have no content type at all (errors, redirects, 201 responses, etc.). – CBHacking Feb 8 at 6:40
  • If your HTTP client also does something with the response, such as trying to parse / render / execute / etc. it, then of course that's additional attack surface. If it merely writes it to a file or console - as curl does by default - then it's possible whatever other software eventually consumes the output will be harmed by it but the problem won't be that you fetched a URL, it's that you fed a malicious input to some program that couldn't handle it. That's a problem, but it's not a "fetch a URL" problem except in the obvious sense that obviously the result of fetching a URL is untrusted. – CBHacking Feb 8 at 6:44
  • 1
    Upvote, but the answer would be more awesome with one or two examples of browsers that pre-fetch, messaging clients that preview, and (popular) browser extensions that pre-fetch. Or if anyone else can contribute that information in the comments it could also be handy, purely for knowledge's sake. – stevec Feb 8 at 15:52
  • I added a specific example of an app and a link to my question. You may use that example in your answer. – Hans Feb 8 at 17:26
10

Yes We can be pretty sure this can happen, because something very similar to it did: https://www.nbcnews.com/tech/security/android-flaw-could-let-hackers-take-over-phone-text-n399016

Stage-fright: There was a bug that got named Stage-fright which was in the image or video-processing on Android. Because some apps will "view" media automatically to generate a preview, the app automatically runs the media through the buggy library without the need for user intervention.

Back to your question: Currently, many messaging apps, including Discord, generate a preview of links that are sent to you. If a similar bug were to come back, it would almost certainly affect people who view the link without opening it, since the app needs to render the link preview.

3
  • Right, but Stagefright (bug) as nothing to do with an URL!? If just an example, I think this could be specified. – F. Hauri Feb 8 at 9:57
  • I added a specific example of an app and a link to my question. You may use that example in your answer. – Hans Feb 8 at 17:26
  • @Hans In your specific example, almost certainly, no. I haven't used the app, but it would be considered a security hole. Even if it did exist, such a bug would probably be patched by now, either by the OS, What'sApp patching it in the app, or blocking such URLs on the What'sApp server. – Patrick M Feb 12 at 19:42
0

Shortly

  • Yes but, if you use confined tools or smartphone.
    As already metioned in many answer there, confortable applications, with previews, pre-download and so on is subjet to software vulnerabilities (in tool himself or in system libraries).
    Of course, this kind of security issues is mostly quickly published and patched.

  • Near no, if you use text tools in VT console, without picture and preview.
    For sample, I use mutt mailer, without binding and I manually check attachment when I don't simply ignore them (mostly enterprise logo and other useless tips)
    So if a want to acceed to an url, I have to copy-paste them...(I use xterm wich don't offert to automatically open browser by clicking on URL)

1
  • I added a specific example of an app and a link to my question. You may use that example in your answer. – Hans Feb 8 at 17:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.