Website security – it’s all in the development

As tech-savvy people know:

My belief – and one of the key reasons I so frequently write publicly about security – is that the best way to combat risks in software is to educate developers. All the security scans and penetration tests in the world won’t help when it can take just a single line of bad code or a solitary configuration setting made by the developer to bring everything undone. Of course it’s frequently much more than just one mistake too, ultimately, dear developer friends, it’s “us” that build mechanisms such as the one behind Tesco’s password recovery system.

Case in point:

Another one I was involved in some time back and didn’t share publicly demonstrates the cascading nature of security risks. A particular publicly facing website was accessible only by IP address (no DNS entry) and users deep-linked to a folder within it. When I browsed back to the root, I found directory browsing enabled so you could traverse through the site from the convenience of the browser. That’s bad enough, the directory in the root called “backup” was even worse.

The backup folder contained a backup of the entire website including the web.config (this was an ASP.NET site). There was no encryption of sensitive data in the file so the connection string was visible. The SQL Server it was connecting to was publicly accessible and not firewalled off from the world so getting into that was easy. Oh – did I mention the username of the account in the connection string? It was “sa” – Server Admin AKA I now have access to every little thing on this entire SQL instance.

Worth a read.

1 comment for “Website security – it’s all in the development

  1. ivan
    January 17, 2013 at 21:04

    Don’t know anything about the first example but the second one is the fault of the sysadmin not the site developer. After all, who in their right mind leaves backups on the webserver?

Leave a Reply

Your email address will not be published. Required fields are marked *