Musings about Coding, Business and other Geek Stuff Live and Direct from somewhere on the planet
February 27, 2004
The Browser Threat Model

Many Java developers work in the financial web applications sphere. Yet most know very little about security and threat models. Since the browser is the main entry point into our applications, it is one of the primary tools we need to analyze when figuring out threat models.

A threat model is a type of threat that we are trying to secure ourselves against. A common mistake by naive developers (and marketeers) is to pronounce a system secure. What you really need to do is find out what are the possible bad things that could happen and secure against it. This is called threat modelling.

Ian Grigg has been one of the most vocal critics of SSL’s lack of a distinct threat model. See Whats your threat model? for more info. He couldnt find any prior good analysis of the browser threat model so as any good critic does he has worked on coming up with a document describing the browser threat model

He first lists various well known threat models on the internet and then identifies the ones specific to browsers. The three main ones being:

Phishing

These are the attacks that have become common place at the moment, most often on PayPal, but also on banks.

To Phish you normally would send a spam containing a fake email pretending to be from a given financial institution. This would give you some url to login to say your paypal account and change your password. The url would redirect you to their fake site, which harvests the passwords thus giving access to the users funds.

This is one of the largest and most serious problems at the moment. There are a range of different solutions, which like AISD treatments are probably best taken together in coctails. Ian mentions some high tech solutions such as improved SSL userinterface. There are also various relatively lowtech solutions, we as web developers can use to identify fake sites.

Eavesdropping

This has allways been relatively easy on the internet. With WIFI its become childsplay. One of my favorite tools to scare the bejezus out of managers to take this serious is to demonstrate Ettercap running on my notebook in a clients office. For use with WIFI first “break” the hard security using a tool such as AirSnort

As Ian points out the only real way to secure against this is by using encryption. SSL is the obvious tool to use here. For us Java developers, please lets encrypt the RMI/CORBA/SOAP/XMLRPC etc traffic as well. We almost never do this, leaving huge security holes.

While Ian mentions that privacy is generally the main victim in this. When we are talking about financial applications this is very important. When we also at the same time pass clear text authenticating tokens such as passwords along, we have even further issues.

Man in the Middle

This is the most celebrated threat model and the one which SSL’s CA’s were supposed to protect us against. Essentially this is a fake site between the user and the server. This intercepts and modifies or grabs the requests.

Ian writes:

There are extraordinarily few reports of MITMs. Some reports come from demonstrations.

There are no known reports of MITMs over the SSH network, which is arguably the highest prized network to attack, as it could create the pool of hacked machines to further deploy attacks. Likewise, OpenPGP and SSL have not experienced any successful MITMs that have been reported.

DNS has been “poisoned” several times, resulting in email and web sites being diverted. The former was for a privacy attack (salacious emails being revealed in political campaign) and the latter was a demonstration of the weakness of DNS.

MITMs remain the stuff of legend. Because of their poor filtering characteristics, and their active tracks and evidence, they remain the tools of only a select few fringe attackers with obscure interests.

I agree pretty much with this. Phishing and Eavesdropping are potentially a lot more serious, allthough less sexy. The expense introduced by the CA’s into the whole process of protecting against this kind of attack has left us much more open to the others.

DOS

Finally but not least Ian mentions DOS, which he classifies as a browser threat. This is when a machine is taken over by a trojan or virus and is part of a distributed denial of service attack against some server, such as the recent mydoom family.

I am not sure I agree that this is a browser threat model. I would say that this is more of a generalised threat model against:

  • Normal PC’s
  • Web servers

While serious these attacks dont really involve the browser though, so I dont think it can really be seen as a valid part of this list.

There are various other kinds of attacks that I think should be included in the list as they do include the browser. The most important being Cross Site Scripting which is a combination of browser and server related (and yes this is our responsibility as developers to test for).

A good resource for web application developers is OWASP who are attempting to raise awareness amongst us developers. See their 10 most critical web application security vulnerabilities I wouldnt be suprised if you found some in your own apps. Everyone does. Most of these aren’t browser threats, but you really should check it out anyway.

Posted by pelleb at February 27, 2004 10:44 AM
This entry was posted in the following Categories: Crypto & Security
Comments

The reason for adding the DOS attack was that it does effect the overall experience. It is, practically speaking, a threat. But, there is sod all that can be don about it, so it is the classical example of a threat that is listed in a threat model, and then given a quick dismissal in the security model.

Threat models - having discussed this recently - are comprehensive models; whereas security models are filtered by risk and return. As we can't get much return from a DOS defence, and as the only risk is "lost time", it pretty much always gets dropped.

Mind you, you've got me on cross-site scripting... I've no idea what that's about :-/

Posted by: Iang on March 10, 2004 11:15 PM
Post a comment
Name:


Email Address:


URL:


Comments:


Remember info?