Developer

Assumption-based Hacking 101

High-level thinking leads to assumptions, and assumptions are the mother of all mistakes -- consequently the best place to find a security hole is in a place where the programmer has made an incorrect assumption.

High-level thinking leads to assumptions, and assumptions are the mother of all mistakes — consequently the best place to find a security hole is in a place where the programmer has made an incorrect assumption.

Such a case came across my desk yesterday, one bad assumption has led to a site that has more holes than a cheese grater.

The programmer obviously assumed that any authentication would occur through the nice log-in form at the front of the site — bad mistake. It's an oversight that most inexperienced programmers would make until they are bitten by it. The thought obviously never occurred to the programmer that data could find its way to his scripts without first coming in the front door. The golden rule in programming is that one should never trust user input, ever!

Such is the ease with which this hole can be exploited, that by simply manipulating a plaintext id number within the postdata, any users’ data can be changed.

The biggest problem with the site in question is that it contains a wealth of potentially personal information and this data can be retrieved and updated without any authentication on the server whatsoever.

A handful of lines in the scripts could make this problem go away. Worse still, the site is built on top of PHP, a language in which authentication is ridiculously easy.

No cookie checking, no credential checking, just blind assumption that users can only find their way to scripts after checking in at the front door.

If a site builds its own log-in mechanism that isn't based on http authentication then you must be aware that all of your scripts are world readable. Therefore, each of those scripts will then need to check a users' authentication as well.

Leaving a lack of authentication aside, seeing internal ids strewn throughout the html and postdata is simply asking for someone to go poking around in the system to see what can easily be exploited.

Users should not be naive enough to enter personal data into an unencrypted site, but even if they are, the site should pick up the slack and encrypt the data anyhow.

And the time it took to find all this data from the site in question? Barely 15 minutes.

If the original programmer had spent 15 minutes thinking about his site's security rather than just churning out yet another site, all the above problems could have been avoided.

About Chris Duckett

Some would say that it is a long way from software engineering to journalism, others would correctly argue that it is a mere 10 metres according to the floor plan.During his first five years with CBS Interactive, Chris started his journalistic advent...

Editor's Picks

Free Newsletters, In your Inbox