SQL Injection Attacks Against Banks on the Rise
SecureWorks announced that it has seen a dramatic increase in the number of hacker attacks attempted against its banking, credit union and utility clients in the past three months using SQL Injection. "From January through March, we blocked anywhere from 100 to 200 SQL Injection attacks per day," said SecureWorks CTO Jon Ramsey. "As of April, we have seen that number jump from 1,000 to 4,000 to 8,000 per day," said Ramsey.
/*
The fact that SQL injections are on the rise is not surprising. The fact that money now drives a large percent of malicious activity would only further this argument. Banks and on-line commerce sites are always targets, especially since they are almost always database-driven, and there's money to be made from the data involved. What is surprising is the number. Staggering, in fact.
*/
"Depending on the sophistication of the attacker, the online criminal can potentially gain access to a bank or utility company's key customer databases containing social security numbers, account numbers, credit card numbers, email addresses, etc," continued Ramsey
/*
All of which are very valuable to identity thieves, hostile foreign governments, and spammers.
*/
"SQL Injection is successful only when the web application is not sufficiently secured," said Ramsey. "Unfortunately, the majority of websites and web applications are not secure. Thus, we are advising all organizations to use 'input validation' for any form to ensure that only the type of input that is expected is accepted."
/*
Of course. When will people learn to start scrubbing their user-supplied data? I'm not talking about client-side JavaScript form validation, either. This has to be done both at the client side and at the server side. How many applications are out there that
include($form['function'].".php")?
Securing these applications is not difficult. You must take the same approach to application security that you do with firewalls. Allow only what is specifically wanted, and deny everything else.
mod_security makes this a piece of cake.
InfoWorld is carrying a more detailed version of this story as well.
*/