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.