GNUCITIZEN

I think the idea is a good one, and is already being used for VPN connections. A computer is put into “Limbo” until it is verified to have certain applications, and they are up to date.

I don’t think it would be successful, if the goal was to report on all applications a client computer has before it connected to a host web site.
However, I do believe it is possible for Operating Systems and Anti-virus/Anti-Spamware applications to report their presence, status and whether or not they are up-to-date to the browswer (actually to a file which the browser could parse).
This way, the host web site could interrogate the browser to find out if the operating system is up to date on hot-fixes, a anti-virus is being used and it is also up to date before allowing it full access.
In today’s movement towards Web 2.0 architecture; I think your idea is right on track… and I too, can see this happening in the near future.

Repeat after me: You cannot trust the client! At least in a VPN environment you can use certs and digital signatures to ensure the integrity of the binary client. This can’t happen with a browser without significant re-architecture.

I understand your solution is aimed at protecting legitimate users. So you assume no one would bypass the restrictions/enforcement applied to the client just to gain access to the site. Ignoring the social engineering opportunities here (”Hello, please upgrade to Acrobat 31337, here is the URL…) I am very wary of this idea mainly because of the mistakes devs will make when they are using something that “verifies the integrity level.” It’s trivial for the devs to make the small (and faulty) logical leap and think that now the client is somehow trusted. I can easily imagine a dev using this system saying something like “well, if they got this far, I know they are safe, so let’s do [insert bad security practice here].”

I think this idea is interesting, but I worry that it will create a false sense of security in the client that causes devs to make silly mistakes. Of course, they are already making silly mistakes… :-)

Instead of Anti-Virus the current buzzwords would either be “Content Filtering” or “Endpoint Compliance” depending on which particular aspect you’re talking about. Either way, Anti-Virus isn’t ambiguous — it’s just wrong. ;-)

It’s a really interesting idea in general, but here’s one problem I see — if the user’s browser is compromised, /ANY DATA/ from the browser is suspect. That means your windows.antivirus or windows.firewall object is too. The threat isn’t that the /user/ will try to bypass the protection to access the site, so much as it is that malware on the machine (or malscripts, or whatever) will try to bypass the protection for the site.

Of course, even in that case, if you assume that the client has a period of time where he’s not infected but is vulnerable and visiting the site, this idea might work to help get him to upgrade faster, so it’s still got potential.

You’ll run into the exact same situation that Cisco finds themselves in now with their NAC being subverted:

http://www.darkreading.com/doc....._id=120852

Actually, I think the term Application Layer Firewall should be used to protect all sides involved in communication, servers (applications) and clients equally. Although ModSecurity is typically seen as a solution to protect the server-stuff this is just a matter of perception. For example, you can configure Apache to work as a forward proxy, add ModSecurity to it, and configure your the network to force all clients to go through Apache for their HTTP needs. In this situation ModSecurity will protects the clients, as it allows you to inspect the content before it is delivered. While it is true that ModSecurity is better equipped to protect the server-side this is only the current situation. Improving support for forward-proxy deployments in on my TODO list.

FYI, I have already experimented with content injection in ModSecurity (i.e. a server-side Greasemonkey). This feature will be published later this month as part of ModSecurity v2.2-dev1 and discussed in my presentation at OWASP Europe in Italy in May (http://www.owasp.org/index.php.....7/Agenda).

I’m sorry, but this solution just won’t work. If you have an application that is vulnerable to XSS, you can’t implement JavaScript functionality that would reliably protect the client. There is no way to prevent my injected JavaScript from simply overwriting all of your functions, for example.

The only way to implement real client-side protection is to incorporate that functionality into the browser. There are a number of Firefox plugins that attempt to address this problem, like Firekeeper. I’m not sure how well they work, but at least they have the potential to help address the problem. JavaScript just isn’t able to do that.

I don’t think anyone made the claim this would be the security invention of the century.

To be honest; I don’t trust one single appliance, application, user, administrator or client which touches a network. Every one of them can be defeated.
Hence security professionals implement a policy of “defense in depth”.

Saying that something won’t work because… displays ignorance.
“What if it becomes compromised…” pretty much works on everything.

Firewalls won’t work, because… they can be compromised. Proxy’s won’t work because they can be bypassed. Certificates won’t work because I can make a copy of it. VPN’s won’t work because of all of the above. Wireless won’t do because the signal can be intercepted and decrypted. Can’t use Windows, UNIX, Linux, Oracle or thousands of applications because there are vulnerabilities to them.

It is easy to say something will not work or cannot be done. What makes you the big dollars and gives you credibility, is finding out ways to make it work.

The idea is still a good one. Another possible future choice for defense in depth.

I personally believe that you cannot dictate security controls to a customer. In your example, if Joe is unable to access site.com due to patching issues, I would think that Joe would simply go to competitors.com and perform his transactions elsewhere. VPN is not really a good analogy for this since most VPN users have no other choices. For websites (especially ecommerce), individuals do have a choice.

Inmy opinion, the only way to ensure that a site is secure is a multi-pronged approach:

- Ensure that security is a fundamental part of the defined SDLC that is used to create the web application.

- Have a defined response plan to be able to evaluate, prioritize, test, and remediate vulnerabilities found within the application’s architecture and the application itself.

-Realize that there is always going to be a risk in doing business on the web and take server side controls to mitigate that risk. One item that I am surprised that I do not see used more is something that banks/credit card issuers do to help protect themselves: profile the normal usage of an application and alert on behaviour that falls outside the norm.

Application firewalls, at least in my experience, seem to cause some more issues than what they solve. I know of multiple businesses that deployed app firewalls where it became harder to ensure that the applications were written with security in mind. Input validation was not focused on because “the appfirewall does that for us”. Product management started to spend money that was currently allocated to security functionality on other items since “the application firewall does a better job”. Deploying application firewalls requires a lot of level setting on the amount of security that it truly gives an organization.