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.

Improve this question
6
  • What threats, directed at whom, are you trying to defend against? See the faq.
    – nealmcb
    Feb 6, 2011 at 16:25
  • 1
    This seems hard and fragile. Why not just directly address any CSRF vulnerabilities that your site has?
    – nealmcb
    Feb 6, 2011 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 6, 2011 at 17:35
  • 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 6, 2011 at 19:20
  • 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 6, 2011 at 20:00

2 Answers 2

Reset to default
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).

Improve this answer
2
  • +1 for each of the 5 answers embedded here!
    – nealmcb
    Feb 7, 2011 at 2: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 7, 2011 at 2: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.

Improve this answer
1
  • I don't intend to rely on User Agent. In fact for Flash I'll be using their version detection kit. Other vendors may have similar .js ways of testing object versions
    – makerofthings7
    Feb 6, 2011 at 17:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .