There are so many popular web applications around nowadays. Blogs, CMSs, Forums, Webmail, Site Administration, Project Management, Wikis, and many more. Yet I’m shocked at the lack of understanding of web security even among the authors of some of the most widely deployed applications.
That’s not to say that the web is a particularly good platform for building secure systems. It isn’t. But there are best practices and established wisdom on defending against security risks.
Let’s take an example – session tracking and authentication.
Everyone does it differently. Some applications rely on a session cookie for tracking, and assume that anybody returning a session cookie from an authenticated session is OK. Others embed the session ID into the URL, while a few provide either method as an option.
Some systems add a nonce (that’s a number which is used only once, not a paedophile) to prevent replay attacks. Others check the referer.
Some systems simply send the username and password with every HTTP request.
It doesn’t take a genius to figure out that some systems are going to be supremely vulnerable to all sorts of security issues, and I’m shocked that some of the most widely used applications have been written without an understanding of even such basic stuff as session tracking.
Another example of this callous disregard for security is that a significant majority of applications which I have seen advise their users to set configuration files to 666. The main problem here is that most people just go ahead and install web applications on shared web servers. While many hosts provide extra isolation between users on the same system, not all do, and setting up permissions to allow other users of the same web server to read and write your sensitive configuration files is just asking for trouble.
Many people ascribe terrible security properties to popular web scripting languages such as PHP. While it is true that many applications written in PHP are horribly insecure, it’s more down to a correlation between people who know how to write PHP and people who don’t understand security. While PHP itself has had a few security flaws, it’s not impossible to write secure applications in PHP. A decade ago it was perl which had that reputation. In another decade, who knows.
I am frequently horrified to see forums about programming where people (newbies) ask for advice about how to write code for web applications, and other people simply feed them half-baked solutions which at best are insecure, and at worst are downright dangerous. And this is the kind of resource that people use when writing web applications. Is it any wonder that the web is so insecure?
Improving this would be a matter of improving the resources available to aspiring web programmers. There’s nothing that can be done to prevent cut&paste-style “programming”, but at least if the source materials and resources are of a higher standard then they stand a chance of coming up with something less frighteningly insecure. That means a set of coherent rules, principles, strategies and code examples. It means a widely published best practice.
Of course, how can you tell? Very few people are qualified to look at the source code of a web application and perform a security audit. Your average administrator installing some software on a web server certainly isn’t. And you don’t get to see the security of an application until it all goes wrong. So there’s not really all that much pressure on software authors to care about security right from the start, because their users won’t know whether they’ve done it properly or whether they’ve just evolved a codebase by cut&pasting from Joe Moron in their favourite newbie programming forum.
Yes, this is a bit of a rant. But I’d really like to encourage software authors to care a little bit more about security, and do their research before committing to a security model.