Security Blankets
Tuesday, 22. November 2005, 22:56:46
Note: My security work has mostly been in dealing with service architectures and intrusion detection (and partly in bars, which is surprisingly similar in most of the basic concepts and approaches). I haven't got a monopoly on making mistakes, so I intend to revisit and edit this any time I learn something should be changed... (Also, it's not really necessary to be a heavy security and web geek to understand the ideas in here, I hope. Whether that makes them intreresting or not is another question).
Security on the Web is pretty important. At Opera we work hard on in, and according to Secunia (who watch over this area pretty carefully we are normally better than either Internet Explorer or Mozilla/Firefox at not exposing ourselves to new attacks, and at fixing problems fast and effectively.
The early Web didn't really address security - it left it to a seperate layer (primarily SSL - the https URIs that you often see are the most obvious example) that was developed as the need arose, and could be put in place because of the clean seperation of layers. For many years the US government stopped this being available to the whole world, but as newer and better systems became available they could be dropped into place. This seperation of layers is an important theoretical principle, with some practical benefits - you can be surer of your security when it is not bound up with every other function that you are developing, and testing is more straightforward.
As the Web has become more complex and dynamic, to offer more useful services, new types of security requirement have appeared. When pages were static, or had a simple form that could talk to the server that gave it to you, SSL was fine. "XSS" (cross site scripting) actually appeared with forms that would pretend to be one site but were really talking to another, giving, say, your address and phone number to badguys.com instead of to niceFolks.org. Technologies like Frames and Javascript, as well as offering new possibilities, made it easier for a site to pretend to be something else, and even to use a real site as a kind of "trojan horse" to fool the user into trusting it.
At the same time users have learned more about how the Web works, and browsers have developed ways of helping them check that they are not being tricked. The little yellow bit in the Opera address bar tells you who owns the site you are connected to, and how good the security is (on a scale of 0 to 3). Browsers also block the most obviously dangerous cross-site access. In general, a script from dodgyDevelop.com cannot access your information on myBank.com unless the site itself has a copy of the script that it delivers because it trusts it. When these blocks are not in place you can get the kind of problems Jim Ley has noted recently in development projects.
(Development is like this - the trick is to release a service in a way that doesn't expose other risks by getting the layers right. One of the common processes is to use expert crackers to find bugs before releasing software - this is standard QA. In the Open Source world, the theory is that so many people look at the work that problems are picked up and solved. In some cases this works well, in others not, according to the actual results).
Although this security approach is helping to keep us from being caught out by a malicious attack, it comes at a price. The idea of the Web is that you can use a service you find. Of course you need to know, when anyone in the world can offer a service, whether you can trust it. This is not new to the Web. Most people are already wary about b eing offered millions of dollars by someone they don't know who says they were stolen in a far-off country, and many are wary of giving money to people who claim to be collecting for some good cause, but can't show who they are. Trust networks are things people have in the real world, but interfaces and systems for building them on the Web are not yet mainstream, and are not necessarily simple to create at the moment. So we live with the cross-site restrictions as a simple answer, winning something and losing something.
In accessibility, I have had a long-running discussion with my good friend John Foliot about how to deal with making keyboard access better for people who need it. A key disagreement we have is on whether it is better to get rid of existing content along with broken implementations, or whether we should take an architecture that is clearly flawed, and adapt it in ways that let us keep using the existing web, at the price of taking longer to work towards the system we would like. In that case I believe that the value of the existing Web is high, and we should keep it, since we can minimise the practical cost.
In this case, the security model is not yet built into the specifications that describe how the services themselves can be built. It seems to me that we are better keeping it out - making sure that we can change the model we have now for a better one (both in actual security and in minising the downsides of the implementation) as soon as it is readily available. The idea of writing the security model we should be using into the specifications for the formats we use strikes me as wrong on two levels.
In other words, I am worried that we are giving ourselves the relatively comforting protection of a security blanket instead of growing up and thinking about real security as adults who decide for themselves what to trust.
Comments are actively sought here. This is complex stuff, and more brains working on it is a good thing IMHO.
Security on the Web is pretty important. At Opera we work hard on in, and according to Secunia (who watch over this area pretty carefully we are normally better than either Internet Explorer or Mozilla/Firefox at not exposing ourselves to new attacks, and at fixing problems fast and effectively.
The early Web didn't really address security - it left it to a seperate layer (primarily SSL - the https URIs that you often see are the most obvious example) that was developed as the need arose, and could be put in place because of the clean seperation of layers. For many years the US government stopped this being available to the whole world, but as newer and better systems became available they could be dropped into place. This seperation of layers is an important theoretical principle, with some practical benefits - you can be surer of your security when it is not bound up with every other function that you are developing, and testing is more straightforward.
As the Web has become more complex and dynamic, to offer more useful services, new types of security requirement have appeared. When pages were static, or had a simple form that could talk to the server that gave it to you, SSL was fine. "XSS" (cross site scripting) actually appeared with forms that would pretend to be one site but were really talking to another, giving, say, your address and phone number to badguys.com instead of to niceFolks.org. Technologies like Frames and Javascript, as well as offering new possibilities, made it easier for a site to pretend to be something else, and even to use a real site as a kind of "trojan horse" to fool the user into trusting it.
At the same time users have learned more about how the Web works, and browsers have developed ways of helping them check that they are not being tricked. The little yellow bit in the Opera address bar tells you who owns the site you are connected to, and how good the security is (on a scale of 0 to 3). Browsers also block the most obviously dangerous cross-site access. In general, a script from dodgyDevelop.com cannot access your information on myBank.com unless the site itself has a copy of the script that it delivers because it trusts it. When these blocks are not in place you can get the kind of problems Jim Ley has noted recently in development projects.
(Development is like this - the trick is to release a service in a way that doesn't expose other risks by getting the layers right. One of the common processes is to use expert crackers to find bugs before releasing software - this is standard QA. In the Open Source world, the theory is that so many people look at the work that problems are picked up and solved. In some cases this works well, in others not, according to the actual results).
Although this security approach is helping to keep us from being caught out by a malicious attack, it comes at a price. The idea of the Web is that you can use a service you find. Of course you need to know, when anyone in the world can offer a service, whether you can trust it. This is not new to the Web. Most people are already wary about b eing offered millions of dollars by someone they don't know who says they were stolen in a far-off country, and many are wary of giving money to people who claim to be collecting for some good cause, but can't show who they are. Trust networks are things people have in the real world, but interfaces and systems for building them on the Web are not yet mainstream, and are not necessarily simple to create at the moment. So we live with the cross-site restrictions as a simple answer, winning something and losing something.
In accessibility, I have had a long-running discussion with my good friend John Foliot about how to deal with making keyboard access better for people who need it. A key disagreement we have is on whether it is better to get rid of existing content along with broken implementations, or whether we should take an architecture that is clearly flawed, and adapt it in ways that let us keep using the existing web, at the price of taking longer to work towards the system we would like. In that case I believe that the value of the existing Web is high, and we should keep it, since we can minimise the practical cost.
In this case, the security model is not yet built into the specifications that describe how the services themselves can be built. It seems to me that we are better keeping it out - making sure that we can change the model we have now for a better one (both in actual security and in minising the downsides of the implementation) as soon as it is readily available. The idea of writing the security model we should be using into the specifications for the formats we use strikes me as wrong on two levels.
- Using a new format specification will mean copying the security information into that specification. This seems like a bad approach
- More seriously, it makes it harder to replace the model with a better one, since it needs to be teased out of the specification, and in the worst case replaced with a new set of specifications, something that takes a very long time to put in place.
In other words, I am worried that we are giving ourselves the relatively comforting protection of a security blanket instead of growing up and thinking about real security as adults who decide for themselves what to trust.
Comments are actively sought here. This is complex stuff, and more brains working on it is a good thing IMHO.
WIDGETIZE
Alexey Feldgendler # 23. November 2005, 05:35
And if not proven mathematically, no approach can be trusted as safe. It it's safe for now, it just means that noone has yet invented a way to compromise it. If a spec is released which documents a security model currently thought of as safe, it can just make things worse if a fundamental flaw is later discovered in that model.