In the four years since I first began to run for Minnesota state representative, my web site technology had become dated. I chose to clear away all the old cruft and start fresh. For now, this new site will function as my personal blog for technology and social issues while I'm developing hoodbid.com. Today, I want to blog about the reasons WHY upgrading is so important.
Any good web administrator knows that badly outdated content management systems tend to have serious vulnerabilities. Popular security sites labeled remote buffer overflows the "attack of the 90s." We hardly ever see these attacks succeed today. Ever since AMD introduced the NX (No eXecute) bit to its AMD64 processors and Intel followed suit, these attacks have become quite rare.
Today, SQL injection attacks have replaced remote buffer overflows as the most exploited vulnerability of this decade. It seems like security patches come fast and furious against these attacks, but they do not arrive fast enough. While the most popular open source CMS programs quickly patch, many third party modules and proprietary CMS products stay vulnerable a long time. In the famous Anonymous attacks against HBGary, SQL injection was used against their custom CMS to gain access to their password database.
As hackers, we must never grow so enamored of our favorite products that we fail to provide constructive criticism. This applies to hardware as well as software. While there are valid complaints about web scripting languages, CMS systems, web servers, and database servers, I want to focus on something more fundamental--
Structured Query Language is becoming the Achilles heel of the Internet.
Don't get me wrong. Most sites function fine the majority of the time. If you code just right, you may never even notice the problem. Most sites functioned fine throughout the 90s while buffer overflows resulted in thousands of sites being broken into sometimes within the span of a single day. It's easy to blame the administrators, but we shouldn't absolve the tools. There would be no need to patch on a daily basis if the tools worked the way they were intended.
There tends to be a mistaken belief in the technical world that if a Fortune 500 corporation can run its mission-critical services using a piece of software that the software must be safe. It's like the oft-repeated fallacy that "no one ever got fired for buying from IBM." We know numerous Fortune 500 companies get broken into, but they benefit financially by not telling shareholders and sweeping the evidence under the rug. Also, these companies hire expensive security resources who are tasked day-and-night with patching and building additional layers of defense behind defective products.
The problem with SQL is that it requires that all queries exist as natural language. User input from form fields is attached directly to query text. In order to protect your database from attacks, this setup requires that your scripting language is aware of many characters and character combinations that have special meaning to SQL, so that it can strip these characters from user input or treat them as invalid. Even when the developer is especially careful, a site having numerous forms or CMS modules can forget to "detaint" input somewhere.
My problem with this setup is the fact that Perl, PHP, Python, Ruby, C, and all other languages used on web servers should not be forced to work around deficiencies in the implementation of SQL. As developers, we must not apologize for our tools. It's not Larry Wall's fault that your database server cannot distinguish between suspect user input and hardcoded query language. It shouldn't be the responsibility of the scripting language to filter both native special characters as well as SQL special characters.
I know there are many SQL substitutes out there, but what would you consider to be the best theoretical solution?