Skip to main content

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)

Comments

Mike said…
What is it in the FISMA legislation that leads you to believe that it provides an incentive for agencies to create "lengthy, complicated reports" when they identify a software defect? The NIST Risk Management Framework created in support of the FISMA legislation requires testing for software defects, requires that they be managed and, through the POA&M process, ultimately resolved. If agencies are choosing to write lengthy and complicated reports in lieu of fixing problems, blame agency management and staff, not FISMA.

The problems lie not in our security requirements and standards, but in our execution.

Popular posts from this blog

Verified by Visa (Veriphied Phishing?)

If you have used a Visa card to make a purchase online lately you may have encountered a relatively new program, Verified by Visa . I've encountered it twice. The system is an interesting attempt by Visa to reduce online fraud and identity theft. It's a noble effort, but the user experience is unsettling, and the security implications are not exactly crystal clear. Here's what happened to me, both times the system was activated. I was redirected away from the domain at which I was shopping, to a URL which was: not the domain where I was shopping, not the domain of the bank that issued my card not visa.com I've been telling people for years that if anything like that happens to you, close your web browser immediately and do not under any circumstances enter any personal information into the form, because this is a sure sign of a man in the middle or phishing scam. (Never mind that all the best phishing scams now-a-days look like the actual domai…

Hacker 0x80 0wn3d by FBI (Arrested after Accidental Outing by Washington Post) [1]

What can the botmaster 0x80's impending misfortune [1] teach us about information security? Quite a bit. What the botmaster and the reporter didn't count on is a security risk known as "the aggregation problem" or "point and click aggregation". It's not surprising, as even practicing security professionals are often unaware of this problem, or vaguely aware of the concept but not the name. Information Security dictionaries online generally lack the terms, and don't mention them in their discussion of "disclosure" either. The aggregation problem happens when a series of small facts, any one of which if disclosed present a minimal security risk, combine to present a greater security risk when disclosed together. When aggregated, information from publicly available sources may accidentally disclose information that was intended to remain confidential. As it happens, an IETF glossary contains a definition of the basic term. RFC 282…

Splunk acquires Phantom Cyber

I hope it doesn't come across as too cynical, the observation that most acquisitions in the tech domain fail to produce anything useful and often as not wind up killing a promising upstart technology, even if only by accident.

I have hope for this one, though. Splunk strikes me as a likely exception. This acquisition of fresh ideas and talent might breathe new life into a solid, if somewhat staid, security company.

Splunk’s data analytics gets a security boost with $350 million acquisition of Phantom Cyber