In the way we run our web applications these days, it is very hard to get it secure. Web authors may not have the skills or be aware of the risks their site is running, and web hosting provider are not in the loop of maintenance for your application. It’s a lose-lose situation. But that could be remedied.
This document is part of an article series on Web Architecture.
The original idea
If you run your own website, then either you may be a large corporation or a hacker, but the majority of web authors have a standard way of hosting their website — they get themselves a domain name and have a website hosted by a hosting provider.
This is a perfect setup. Maintaining a web server is technical work, and it is very useful to have a market offering of these services to less technically inclined people. The web, after all, should offer a place to everyone.
When the web grew into a dynamic place where applications were run and interaction with users became common, so did the complexity of the technical structures needed, but this only adds to the arguments of web hosting providers being useful market players.
How we wrecked it
Still, something is wrong; hosted web sites are very often the victims of attackers, the so-called crackers. Or, more likely, naive script kiddies who merely download and run tools that automate an attack so they need not even think for themselves.
Indeed, when looking at a web server’s log files, it is apparent that many such attacks are constantly being attempted on every web server out there. In many, many cases the patterns are specific to a particular web application.
Web applications are the work of humans, and humans make mistakes. Perhaps web developers make a few more than other developers, because they need to work within the confines of a stateless paradigm and at the same time deal with lots of end-user requests that are full of distracting user interface problems.
So what we see a lot is that such applications end up having a “magic location” or other form of web-based attack vector that makes them skip security checks and do something unintentional. Such things are usually fixed rather quickly, but then what?
Web hosting providers usually offer a web environment with a database, but little more. Users then pickup a web framework that can live in that environment, usually following the advise of a website developer who has fallen in love with the framework. After installing it and getting it to work everybody stops caring. Updates including security fixes will never come to the user's attention because they did not subscribe to the announcement mailing list that goes with the application, and neither do most website developers.
The problem is that now nobody takes responsibility for the security of the web framework. The domain hosting provider couldn’t possibly, because they would need to tend to far too many frameworks (and versions!) in existence, and they are usually selected for providing generic support that can carry any framework; furthermore, site owners would be rather upset if a hosting provider did upgrade web frameworks and cause an incompatibility with someone’s site design.
This situation leads to websites that are often lagging behind on updates, which then have widely known security flaws in them. Needless to say that there is a subculture on the Internet who love to get their hands on that, and do things they would think “cool” but that are in fact destructive.
How we can fix the web
The insecure situation of web applications is not easy to fix. The web framework selected is often the preference of a website designer, but they usually lack the technical skills to deal with security problems. Moreover, they are usually paid once for a web design job, and website owners may not appreciate them sending by-the-hour bills based on such maintenance tasks.
For the domain hosting party, it is undoable to manage each web framework separately; there are simply too many out there. Furthermore, websites might do something naughty that makes them incompatible with the intentions of a web framework. Or it could rely on deprecated functionality that, at some point, will be dropped out during an update. Any problems that this would cause would end up with the “guilty” party who performed the update; and that party is not paid enough to be able to handle that kind of helpdesk calls.
Education of site owners is also too much of an effort. Security is a highly specialistic skill, and couldn’t possibly be made suitable for such a large audience. Moreover, it would constrain the audience that could successfully run a website, which we have already stated is a good thing to keep as general as possible.
The only ones who can realistically update your website are the developers behind the code that website owners installed as part of their site content. These people know when they deprecate behaviour and what could possibly break when moving up one version. These are also the people who know when a security bug is discovered, and they could fix it before announcing the problem in wider circles (which include crackers and script kiddies).
The only way in which this would work, is when such developers run their software as a service that you can incorporate into your website as a plugin module, basically through forwarding or proxy’ing your website, or a part of it. And they would be providing a professional service, for which you could pay them. And given the size at which it is done, it is likely to be fixed instead of by-the-hour. You are very likely to get your money’s worth.
So next time you develop a website, consider actually paying someone for running your web framework, even if it is open source. Or otherwise make sure that you are aware of security updates, and install them immediately. After you’ve done so, you or your website developer may need to go over the site to see if everything is in working order, or needs a fix here and there.
Go Top