Add Hyperlink-Security

[klopeksbackyard]

As far as I know, you can only completely enable or disable access to websites (sumatrapdfrestrict.ini, LinkProtocols = ). Adobe Acrobat Reader offers various options: block all web access, allow only specific sites (whitelist), block specific sites (blacklist), allow web access but issue a warning, or allow all web access without a warning. I know this isn’t REAL protection, but can you add a warning?

It would be really cool to have a warning with customizable text. Example: A user clicks a hyperlink in SumatraPDF. A pop-up appears with the text: "You are trying to access the URL 'https[://]blablabla[.]com/download/malware.exe'. Are you sure you want to do this? If this URL seems suspicious to you, please send us (HelpDesk) this URL or this PDF—we will investigate both for you." In other words, a pop-up with OK/Cancel buttons and a free-text field (including the URL) before the URL actually is accessed.

Whitelists and blacklists would be technically more secure, but they are extremely time-consuming to maintain and are therefore likely to be impractical in real-world scenarios.

However, SumatraPDF currently opens hyperlinks directly without any confirmation—even if you clicked on the link by accident and didn’t actually intend to. In my experience, PDF files from phishing emails rarely contain complex JavaScript; instead, they usually just contain hyperlinks.

Therefore, a way to control hyperlink behavior would be a real security improvement.

PS: Yes, hyperlinks can already be displayed with a blue border. I'm already familiar with this feature—and I think it's good!
PPS: I only added the []-brackets in order to avoid creating an actual link. Brackets are not part of the feature-request.

[kjk]

The reality of such confirmation dialogs is that they don't improve security. They just condition people to ignore frequent and annoying warning messages which actually makes things less secure because people will start ignoring actually important warnings.

[klopeksbackyard]

A lot of security measures rely on barriers. For example, when emails are initially displayed in plain text. Or a restricted view that doesn’t allow access to all features right away. Or that you have to hold down the CTRL key to make links clickable. I wouldn’t go so far as to say that none of this works. At the very least, such measures prevent accidental clicks.

I am the IT security officer and have access to many of the phishing emails we receive. And when it comes to clickjacking in particular, SumatraPDF has unfortunately not performed very well so far.

A warning dialog would give users the option to cancel if they click unintentionally. With a freely configurable text, I could also 1. remind users of our guidelines and their own responsibility and 2. offer users the option to send me PDFs that seem suspicious for analysis.

I get your point - I really do! But we receive more phishing emails with hyperlinks in PDF files than phishing emails with JavaScript in PDF files (to be honest, we don’t get any of those at all). And that’s why, in this regard, a hardened Adobe Acrobat Reader is somehow better than SumatraPDF - which I think is a bummer, because I’d actually like to deploy SumatraPDF as the default PDF viewer across the entire network.

[GitHubRulesOK]

@kjk the main complaint is that it should be ideally a failsafe that a user can then ignore

So many pdf readers will on first click to an offsite link
throw a warning then user can turn warnings off
so THEY are THEN responsible for SELF clickjacking as they were first warned and then ignored that protection

[klopeksbackyard]

No, I do NOT want to deceive my users or shift all the blame onto them. That’s not how we operate here.

In my view, there are two separate issues here:

1. SumatraPDF does not protect against clickjacking (hidden links, accidental clicks).

2. There are certain things that CANNOT be 100% secured technically. These include email and the internet. In my opinion, we’re already doing more here than many others, but there’s simply a residual risk. And this residual risk can only be managed through organizational measures. I think it’s reasonable—and not unreasonable—to address those residual risks that cannot be resolved technically through official guidelines. One technical solution, for example, would be to maintain blacklists and whitelists. But I’m sure you’ll agree with me when I say that’s not practical. So, what’s your approach to dealing with malicious links in phishing PDFs?

In the absence of a better solution, I would be in favor of displaying a warning here (possibly a warning for domains that haven’t been defined as internal or secure—that would still be feasible from an organizational standpoint). I’d like to have a better solution, but I don’t have any ideas. I don’t think it’s a good idea to open malicious links (that haven’t been intercepted technically in some way beforehand) directly.