Hands-on SQL Injection - Show me!

Security training for application developers is an under-funded activity in most of the organizations that build software. Fixing security defects in custom applications remains an underfunded activity, even after defects are identified. Why does this continue to be the case? It can be easier to find defects for a customer in a security penetration test than it is to convince the customer that the problem is serious enough to fix. Sometimes this is because the incentives are messed up. I'm not the only person who has observed that the Federal Information Security Management Act (FISMA) seem to have given Federal agencies a much higher incentive to find problems and write lengthy, complicated reports on those problems, than to fix them. Other times, managers may not understand the technical details of various vulnerabilities, or may be interested in a certain category of defects, while wearing blinders to other types of defects, particularly outside their comfort zone. If the manager is familiar with viruses and worms from their experiences running their PC at home, then they might understand and be more interested in network configuration defects. This might come at the expense of less attention to application design or coding defects, like those that expose an application to SQL Injection attacks. Occasionally the problem, unfortunately, is a more active dismissal of some threats. People sometimes say things along the lines of, "if I don't understand it, it must be too difficult to exploit in practice, so it can't be much of a real risk." I've even heard managers lambast their security advisers while trying to look cool, tossing in the MTV phrase, "Keep It Real". Well, folks, I hate to be the one to break it to you, but even allegedly unscripted reality television is sometimes scripted. Just like exploits to complicated security defects. It only takes one person with the right combination of skills and maliciousness to write an exploit, and give it away. Suddenly the exploit is "zero cost" for the next attacker, and the flood of attackers after that. Exploits are "scalable" in this sense, or, as an economist or MBA might say, the marginal cost of each additional use of an exploit, after it is developed, approaches zero arbitrarily close. We see this pattern clearly in remotely exploitable buffer overflows, which might not be noticeably exploited for years after a product ships, and for months after the defect is discovered and publicized. Then, "suddenly" an exploit pops up. Within days there are dozens of worm or botnet variants exploiting the same defect. (We'll ignore for now the issue that some defects actually were exploited before the defect was publicized.) The same pattern applies to other types of defects that may not be exploited with quite the same high visibility. This type of scalability is inherent in software. If you're having trouble convincing your manager do devote resources to sanitizing your web facing application, or having trouble getting a budget to train your developers in secure coding techniques, consider sharing some of these links with your manager. This first one is a very clever web article by Gustavo Duarte, which demonstrates the attack using a simple online application built into the essay. Here you can see both the ease with which such defects can be exploited, and the relative complexity of the issues facing the defender. Hands-on SQL Injection Here is some additional information on SQL Injections. SQL Injection Attacks by Example Finally, here's an amusing cartoon that you can use to bring up the subject again, if you were given the smack down last time. Exploits of a Mom (Little Bobby Drop Tables)