Tabor sent me a link to a blog entry illustrating quite a few very worrying SQL injection vulnerabilities in T-Mobile’s website and discussing the possibility that cracker Nicolas Jacobsen used a similar vulnerability to gain access to customer information.
There’s no excuse for failing to do input validation. I could understand if this were a bug, but it’s clear that whoever developed T-Mobile’s website didn’t pay nearly as much attention to input validation as they should have.
This is one of the reasons I spend so much of my free time writing my own blog engines, image galleries, log analyzers, and email clients even though there are plenty of freely available solutions I could just download and use. The more unsecure code I see, the less I trust other people to write the software I use.
It’s absolutely mind-boggling how much software there is—especially open-source software, which is generally perceived to be more secure than closed-source software—written by people who pay no attention to even the most obvious potential security issues.
Comments
No subject
How many input validation routines do you write that accounts for obscure bugs in the driver layer of the database engine you are feeding your sql to? Any idea of why sql vulnerabilities are prevalent? Must be bad programmers who have no idea what it is that they are doing. My software on the other hand is immune to code exploits, I do validation, see? Use the hammer brethren, it work good. You have a good idea to solve np complete problems of virus/exploit detetion code vs. valid input then please enlighten the rest of the scientific community with your genius.
Re: No subject
What "driver layer" of which database engine contains these obscure bugs you speak of? T-Mobile's problems weren't caused by a virus or a database engine bug, they were caused by a lack of high-level input validation. The same is true of the vast majority of websites vulnerable to SQL injection attacks.
Database engines themselves are rarely vulnerable to exploits because, in the first place, they tend to be well-written and not prone to security holes; and in the second because when a security hole is found in a database engine, secondary security measures (like firewalls and -- gasp! -- input validation) tend to make it impossible to exploit.
Re: No subject
Wow. You seem to be in the know. For your information, middle-layers are notorious for being sub-par and buggy. SQL injection is also a very common exploit, an not because microsoft sucks and doesn't check their input data...
you obviously have no idea what a firewall does. the reason virus checking is np-complete is that how do you distinguish what looks like good data from bad data (w/o false positives or false negatives). a firewall will not filter for exploits which it was not programmed to check for, and sql injection url strings is not something that a general stateful inspection algorithm for a stateful filewall is going to handle usually. You need fingerprinting that will identify a virus or expoit from normal packets (which is easier for virii usually since they munge exports, contain tags usually b/c the virus writers think they are cool, etc, but with a urlencoded url, tell me which commands you are going to reject outright...? It's a tough problem to get right). Thanks for the lesson on secuirity and firewalls, again, I find the site quite informative.
Re: No subject
You've got the reading comprehension of a near-sighted box of rocks. Who said anything about "middle layers"? I'm talking about database engines, pal, not these "middle layers" you're so fond of. Of course there are buggy abstraction layers. There are also good abstraction layers. Using a buggy abstraction layer prone to SQL injection exploits is just as irresponsible as writing bad code yourself.
No shit. Firewalls don't magically stop viruses? And they don't perform magical input validation either? I am amazed, amazed at your knowledge.
Listen up, Sparky: Viruses need an attack vector before they can infect a machine. One of the purposes of a firewall is to close off potential attack vectors. The only attack vector for a database server sitting behind a good firewall with no ports open to the outside world is the LAN on which the server resides. Unless, of course, some shitty programmer has written a web application that sends queries to the database willy-nilly without validating input.
I'm not saying firewalls are magical shields that will defend your database server from danger; I'm saying that if your database server is properly secured, its only weak point is a lazy programmer.
How long have you been writing database-driven web apps? Can I look at your code? You're either a pompous windbag who took a few classes and have never actually applied your knowledge in a real-world environment or you're a bad programmer with even worse communication skills.
This Blows
All of this is total horse shit. Why don’t you step away from the fucking computer and go take a walk or something or even fire up a bowl. Jesus what the fuck, SQL validation layer my ass.