2

Aside from using browser headers, I want to blacklist/whitelist browser and plugins from my site so that I can prevent these older unpatched systems from (1) being a general user of my site (2) removing those 'targets' from would-be-attackers reach.

My goal is to define some kind of endpoint security standard for users who access my site, but without directly managing the environment, as they are customers.

Is there a standard way to use Whitelisting or Blacklisting to control browser access to my site?

For example, I want to prevent any browser that has outdated Flash, but I want to permit them if they have no Flash at all.

makerofthings7
  • 50,488
  • 54
  • 253
  • 542
  • What threats, directed at whom, are you trying to defend against? See the faq. – nealmcb Feb 06 '11 at 16:25
  • 1
    This seems hard and fragile. Why not just directly address any CSRF vulnerabilities that your site has? – nealmcb Feb 06 '11 at 17:28
  • This is a mitigation technique, just like any other. Even though my developers are under contract to produce reliable code, my business's reputation is at stake for any information leak, destruction, or alteration that may occur. – makerofthings7 Feb 06 '11 at 17:35
  • 1
    It's a crummy, ineffective mitigation technique. You seem to be assuming that the browser blacklisting is an effective or useful way of mitigating CSRF vulnerabilities; I don't think that assumption is valid. How about explaining what problem you're actually trying to solve? – D.W. Feb 06 '11 at 20:00
  • I'd guess that your business could also suffer from users that can't use it without making changes to their browsers which affect their usage of other sites - its a complex world out there.... – nealmcb Feb 07 '11 at 02:08
  • I've been investigating a new cloud based service called CloudFlare (www.cloudflare.com) that purports to provide a web application firewall for web sites. They have been somewhat sketchy on exactly what their service does. Has anyone else looked at Cloudflare? If so, what do you think? – Bill Frank Feb 06 '11 at 19:20

2 Answers2

6

First off: This is absolutely the wrong way to solve CSRF problems. CSRF vulnerabilities are a problem in your site, not in the browser. Blacklisting certain browsers is not going to solve your CSRF vulnerabilities. CSRF is not browser-specific and cannot be prevented through browser blacklisting.

Detecting browser versions: There are various ways to detect what browser version and plugin versions the user is using. For browser version, you can use the User Agent. For Flash, you can use the Flash player detection kit. For Java, see Sun's java update check. You'll want to check Quicktime, too, but I'm not sure how to do that. Note, however, that detection of the browser version and plugin versions is difficult in Internet Explorer.

Knowing which versions are insecure: Maintaining the list of known-vulnerable browser and plugin versions is more difficult. I think it's probably too much work to reasonably expect an ordinary site to maintain. For browsers, a partial starting point is Yahoo's list of A-grade browsers, but they don't maintain which version is the latest known-good version and which versions are known to have vulnerabilities.

Suggestions: If you must check for outdated/vulnerable browser and plugin versions, I suggest that you look closely at the Mozilla plugin check website, which checks whether you have any obsolete or vulnerable plugin version installed. It supports Firefox, Safari, Chrome, and Opera, and partially supports IE. You might want to copy or use their methods. See also Mozilla's JSON interface to their plugin version database.

Bottom-line recommendation: I think you're asking the wrong question. I think your question has some hidden assumptions and premises that are faulty. Browser blacklisting is not an effective way of fixing or mitigating CSRF vulnerabilities. And I think the question is unclear on the threat model. I suggest that you re-ask the question afresh, this time starting with the actual problem you are trying to solve and the constraints you are working within, rather than making assumptions about what the best solution is (e.g., assuming that browser blacklisting is the best solution).

D.W.
  • 98,860
  • 33
  • 271
  • 588
  • +1 for each of the 5 answers embedded here! – nealmcb Feb 07 '11 at 02:05
  • Great answer and links. I removed CSRF from the question. I want to encourage (force) my end users to either be up-to-date and patched, or not have the software at all. I can't control the endpoint, but I only want patched workstations as customers. – makerofthings7 Feb 07 '11 at 02:20
0

I don't think there is any particular way to accomplish this. You need to create a list of browsers and plug-ins that are good/bad, and figure out a way to pull out the necessary info from the user agent. The problem with this is that certain plugins don't add themselves to the user agent. SilverLight didn't (doesn't?) because of compatibility issues.

Following that, I don't think blocking requests from these sorts of browsers will solve any CSRF attacks because these can occur on new browsers that are fully patched, running no plugins, and if an attacker were really trying to do something wonky, they could just spoof a user agent that works.

Steve
  • 15,215
  • 3
  • 38
  • 66
  • I don't intend to rely on `User Agent`. In fact for Flash I'll be using their [version detection kit](http://www.adobe.com/products/flashplayer/download/detection_kit). Other vendors may have similar `.js` ways of testing object versions – makerofthings7 Feb 06 '11 at 17:12