Security holes can be found everywhere in software. It can be a problem by the way a programming language is used; it can be a problem with the conception or the use of an un-secure protocol; it can also be a problem of interaction with other software or libraries; it can be a problem with his interaction with the operating system, or it can be a problem with the way users use it.
These problems are real, and many people and billion dollars are spent to try to cope with them. However nothing is perfect and the result is currently seen as marvel by someone and terrible by others.
If a security problem is found, you can bet that an advisory will follow; a patch of the software in cause will be distributed. Software developers thought about developing systems to ease the burden of software updating imposed to users. Some systems are good, others are more debatable. In a case or another, the problem is the same: users need to perform some type of task to patch their software to secure their systems. With the number of software they daily used, they can hardly keep them up-to-date, with or without having the will to do it.
What if they do not own, on their computer, the software they are using? It is sure that not owning them on their computer does not make the code surer, but will the updates be faster? You bet. Think about it. You are using certain functionalities given by a certain web services, web application, API, etc. Someone find a security hole in the thing, and then wrote and publish an advisory about the found security hole. Normally, thousands or millions of people would need to download and install a patch to get rid of the bug and re-secure their systems. But if the same code is use by all these users, you only have to change that code to automatically patch all users. It is probably the greatest security advantage we have by using such online software.
I recently unintentionally tested the concept with Bloglines. I found a bug in their system (in fact it was the relation between a bug in their system and the use of another web service), published an advisory, then the system was patched 1 or 2 days later by the Bloglines developers. Then all the users were patched and secured at the same time.
Technorati: Security | hack | hacking | patching | Bloglines | api | software | architecture | web | services | applications |
2 thoughts on “The software architecture to use for faster security hole patching: Web Applications”
I agree… but then you get into the situation where all you’re data goes across a wire, on the Internet. You have to trust the provider of the web application not to use this information in a malevolent way.
Also, many of the critical security problems concern the operating system, and you will always need an operating system to support a web browser.
My 0.02$ CDN.
Yup, this is a problem: centralization of the information. Trusting is, and always be, a security concern for the security community 🙂
It is sure that this is not the best way to do things for all applications, but it is a good way to do things for some.
And it is sure that operating systems, Windows, Linux, Unix, Max OS, FreeBSD, name it, is and will always be a security problem.
Thank for these precisions.