Sign up ×
Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

A robust outgoing firewall will protect against desktop applications directly connecting to the internet without your permission. However, as the browser is a generally authorized application for internet access, I have begun to see more applications circumvent this by forwarding a URL request to the browser. This is especially suspicious when the GET query includes long cryptic strings...

Does anyone know of any Windows or cross-platform solutions that either ask the user for confirmation before proceeding to the URL or at least check against a whitelist/blacklist beforehand?

For my purposes, any block that only occurs after the browser has attempted to reach the URL is unsuitable; although this is common for somewhat different reasons in a corporate setting.

Clarification: This user confirmation of outgoing URL should only be for URLs requested from outside the browser. i.e. Some OEM bloatware or a blackbox freeware app decides to open a browser window without permission to on install, uninstall or some other hermetic app decision.

share|improve this question
Some extra information: Registering an Application to a URI scheme. If no one posts an answer that can intercept and confirm external URI invocation to a browser before the bounty is up; I'll investigate and post a PowerShell solution that acts as the default URI handler (assuming that could even work). –  LateralFractal Oct 22 '14 at 9:01
the problem with such a solution is that a external app can still execute " iexplore.exe " or similiar (replace iexplore.exe with your favorite browser, but a malicious app could easy try them all until one succeeds if the malicious app cannot detect which browser the victim has installed). Thats why the protection must reside INSIDE the browser! –  sebastian nielsen Oct 22 '14 at 11:58
@sebastiannielsen If the browser can distinguish between external and internal URI requests, then that's a nice place to put it; perhaps via an add-on. But if it can't, then exec() style invocation could, one hopes, be caught by the inter-process security monitoring of high-end firewalls; leaving the operating system resource handler as the largest hole. But any answer that discriminates between external and internal requests is great. –  LateralFractal Oct 22 '14 at 12:08
Its exactly what I mean. You download a open-source GPL browser, then modify it to differentiate between external and internal requests, and also add a confirmation dialog for external requests, and also on top of this, add other security features to prevent unauthorized browsing. –  sebastian nielsen Oct 22 '14 at 12:26
@sebastiannielsen - you could move iexplore.exe to sdklfkhdslkfj.exe –  paj28 Oct 22 '14 at 16:38

5 Answers 5

up vote 1 down vote accepted

There's actually a simple solution to this: build an application that takes a single command line parameter (the URL) and launches the browser directly with that URL after a confirmation box is shown. Set this application as the default browser.

When the system sees a ShellExecute or CreateProcess with a http:// URI as the target, it passes off execution to the default browser as set in the registry. Your program can intercept that before handing it off to the real browser.


int main (int argc, string[] argv)
    if (argc != 1)
        return -1;
    string url = argv[1];

    if (MessageBox("Are you sure you want to go to " + url + "?", YesNo) == Yes)
        CreateProcess("path/to/firefox.exe", url);
        return 0;
        return -1;
share|improve this answer
Thanks! The ShellExcecute and CreateProcess clued me in to the type of interception I needed to look for. I found this tool: PickBrowser. The tool allows for choice of any (or none) of the installed browsers for opening an link invoked by the operating system. It meets my particular requirements. –  LateralFractal Oct 23 '14 at 11:22

Another solution is to build or modify a existing browser, to not allow any type of external URL typing. You could even have it to use a screen keyboard or such to prevent malicious programs from using SendKeys(); and you could have scrambling screen keyboard and much other security features, And user confirmation if the browser is called externally with a URL as argument. Then you simply only approve this browser in your firewall.

share|improve this answer
A vector that directly manipulates an existing browser instance's input buffer or UI hooks is possible but uncommon outside of explicit malware caught by virus scanners; and in any case blockable by most classes of inter-process firewalls. The attack vector most common and least addressed is simply a mime type or URL opening request passed from an app to the operating system to the default browser. Hence I'd like to know if any method general to message-passing in Windows or any specific confirmation prophylactics for major browser exist. –  LateralFractal Oct 22 '14 at 8:17
The only way you could go is to modify a existing open-source browser, like firefox, to add your own security features. Another idea is to uninstall all browsers, and deregister the default URL handler. Then you have a Portable firefox somewhere stuffed away, with a different filename, that you use for browsing. Theres a small chance that malware may go and search for a browser on the filesystem if no default URL handler is registred. –  sebastian nielsen Oct 22 '14 at 8:54

There are a few different approaches.

One option would be to implement a content filtering proxy. You could install one locally or at the network level. You could force a whitelist and then configure it to prompt on every URL that is not in the whitelist. However, I imagine for most people working with a whitelist is a huge pain. However, many content filtering proxies maintain blacklists or have heuristics to analyze a page before loading the page.

Many browsers and search engines now identify truly malicious pages before they are loaded as well.

In Internet Explorer you can configure Security Zones and apply different levels of security based on this. For example, you can add sites to the "Trusted" sites which you apply less scrutiny on and then there are "Restricted" sites which are more or less a black list. There is a general setting for the "Internet", you can customize the level for Internet sites (which are of course exclusive of those in the "Trusted" list) to do things like disable plugins, disable downloads, etc. I do not believe you could require a prompting for each site in the Internet zone, but I think sites in the Restricted zone can either be blocked or force the user to clear a warning message. I am not sure if the Zone settings affect other browsers since there is some integration with IE's internet settings and the OS.

There are also any number of plugins for the various browsers to add blacklisting, heuristics and plenty of other security features. One that might be a good fit for your needs is Web of Trust, which has implementations for multiple browsers.

share|improve this answer
Unfortunately these approaches don't discriminate between URI requests external to the browser and normal user activity within the browser. –  LateralFractal Oct 22 '14 at 1:06

I would suggest this: Use a Proxy, which initially blocks all requests. For each blocked request, to authorize them, you would have to type a captcha or Another challenging factor that the malicious program will NOT be able to pass.

If the captcha is passed, then the site in question will be permanently added to a whitelist allowing it to pass everytime. Of course, the system should not even pass the DNS request Before the url is confirmed.

You could also have a "log" where you can type like http://proxylog.localnet/ and see all sites that have been blocked and allowed. And unblock important third party sites that for example load script content. (and possible to remove sites from the whitelist)

Using a local software to block external calls to the webbrowser is not secure! A malicious program can Always bypass this - Think of clickjacking, remote Control (VNC style), and so on. It could even do a SendKeys('{ENTER}'); as soon as you click the adress bar in your adress bar to type your own url. And as soon the url is loaded, its too late.

A captcha solution will prevent access for any malicious urls, which will in turn prevent any software from connecting to the attacker for remote Control. So this would make a moment 22 for the attacker: To remote Control, he would need his server approved, but to get his server approved, he need remote Control. Thus the only way to bypass the system would be to build a captcha decoder, but if the captcha is good, it should be pretty impossible.

The good thing with this is that it will make your system "learn", eg each time you authorize a site, it will be saved, thus the system will automatically learn which sites you regularly visit, thus you will get captchas every minute the very first hour you use the system basically, but gradually you will almost never have to type a catpcha.

share|improve this answer
I have an outgoing firewall whitelist and the per-app granularity is usually sufficient. The concern is unauthorised or unrecognised applications proxying information through another authorised application (the browser). A whitelist at a forward proxy level is unworkable as every conceivable website accessed in normal browsing would need to be managed. A blacklist would better / easy to scale, but you still need to know what to block before it occurs. –  LateralFractal Oct 22 '14 at 8:09

I have not seen anything pivot between the browser and the user that can inform them before the connection is made. Any add-on or application would take a serious beating processing so many variables. Let's have a look:

Requester (via browser whether initiated or not) --> browser --> Go get this

How far do you think you'd be able to process the iterations when bad.cgi changes every N amount of minutes, seconds, etc? Forget the iterations, what are you planning on doing when the request becomes:

Requester --> browser -->

The connection is/was already initiated. For all you know, the malice could occur on the URL shortening service before being passed off to a legitimate page.

My view when it comes to malware/malicious sites/networks, is blacklisting on the OUTBOUND side of the equation. I noted the mention of "security zones" which don't always work. There have been instances, where malware authors buy legitimate ad space to infect visitors. Imagine the following: Malicious attacks purchases ad words/graphics on say It is a whitelisted site, the browser in its "security zones" wisdom would allow the connection through. There is no definitive method to stop this from happening, no matter how deep your "deep packet inspection" is.

On the flip side of the equation, remember, we (you) are trying to stop your machine from making a bad choice (connection). Malware/malicious website operators often program quite a few different mechanism to "get out" e.g.:

maliciousSomething --> try getting here --> Interwebs ; if fail then ;
try getting here instead --> Interwebst ; if fail then ;
generate obfuscation --> try getting here

What is the commonality here? ... The destination "here" where "here" can be isolated on not only the corp. firewall, but on local firewalls as well (local as in Windows firewalls). Downside of this is, malicious authors compromise machines all the time, so blacklisting, whitelisting is a losing battle.

If things are "that extreme" where security is of the "utmost" priority, then I'd recommend using a proxy (Squid or so) along with netsed, and outright stripping potentially dangerous strings before the connection is made. e.g.

machineOnNetwork --> --> proxy --> interwebs
proxy --> before I send you anywhere... Let me regex check and replace things --> interwebs

That too becomes cumbersome since you'd have potentially an infinite amount of regex rules at the end of the day. What you posted is an ongoing battle most AV vendors go through on a daily, as well as software developers. I'd love to see your solution at the end of the day. If you ask me, there are only bandaids to this problem.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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