Insecurity by design
Microsoft's software development practices continue to put business systems at risk
So, Microsoft has been hacked again, and a portion of its web site has been defaced. On the one hand, I have to comment that any such hacking is obviously illegal and wrong; but on the other, that the hacking "crown of crowns" - the ultimate "totem hack" - has been performed.
Very many hackers do what they do primarily for peer respect. In this sense, web-site defacement has much in common with the gangs of youths who find ingenious ways to get into railway sidings or to train carriages to "decorate" them with their slogans. For those who regularly travel into King's Cross, the individual who daubed most of the graffiti in the final tunnel did so by making a long and difficult chimney descent. The ingenuity and skill - even the artistry - demonstrated by this graffitist can be admired, even while deploring the vandalism implicit in his actions.
This admiration, however, does not extend to hackers who deface web pages. No real skill is required to run any one of the thousands of hacking scripts available over the internet; and no real skill is actually required to carry out the SQL-injection trick that was responsible for the Microsoft defacement.
But this begs the question: if the hack itself was so simple as to be unimpressive, how come such a security-conscious organisation as Microsoft suffered such an attack? And make no mistake, after having been the target of abuse and sniggers for so long, Microsoft is now highly security-conscious.
The answer lies in the way in which Microsoft developers handle the process of software engineering - in particular, the handling of exceptions. An exception is where a program has to detect and process input that is outside of the normal parameters. In the SQL-injection attack, the input is expected to be something like normal alphabetic characters (say, a name), but it is instead SQL command characters that are presented to the unwitting SQL back- end database for processing.
There are two forms of exception handling: in the first, there is a list of characters to be excluded from input; in the second, a list of characters that may be included. Most software development communities - such as large companies - adopt one or other method. It seems that Microsoft has traditionally managed exceptions by exclusion: if a character is seen as invalid, the error-handling routines are invoked. Other methodologies work by requiring the input to have been formed from a limited alphabet: if the input falls outside of this - whatever the character value actually means - then the error is flagged.
The problem with the exclusion approach is, as Microsoft found with the SQL case and with similar Unicode examples, that the developer might miss some potentially hostile input. And the result, as the internet community has found to its cost over the years, is that security is then breached.
Microsoft needs to urgently rethink its whole software development philosophy. Input should be stringently policed, with characters admitted only if they are known to be welcome. Then we will all be able to sleep more soundly.