Year of the High-Profile Hack taught web developers nothing about security
Obvious, heavily exploited flaws likie SQL, XSS still present in majority of new web apps
No one pays the right amount of attention to security. After more time covering IT than most people have worked in it, the only rule I've ever found to be accurate about corporate security is that no one has a good handle on either digital or physical security.
Most companies are so clueless about holes in their airtight defenses that they'll brag about their anti-spam or intrusion protection while strangers wander in from the sidewalk to use the CISO's private rest room while the CFO drags an oversized bank bag filled with "laundry" toward the nearest exit on the way to a "vacation" in the Cayman Islands.
Companies that do pay some attention to security, on the other hand, end up so obsessive about the smallest risk the whole company behaves as if they manufactured guilty consciences and just heard Jason Bourne was spotted outside.
There are some things that are really hard to miss, though.
Build an email network with no spam filters and your employees will spend all their time deleting spam and trying not to drown in malware.
Decide encryption would be too high a barrier for employees trying to use the WLAN to work wherever they are in the building, and you'll spend yourself broke buying bandwidth or decide you can live with a WLAN saturated by leeches who'd rather use your IP address than their own to download pirate files.
If you build applications rather than just support them the specific issues are different, but it is at least as important for them to build systems without gaping, obvious flaws that can be exploited by the most common type of attack.
Attacks like SQL injections, which were used to take down at least 18 Sony sites and networks earlier this year by, apparently, every hacker in the world, waiting in single file to attack another site as soon as the previous hacker was finished.
XSS (cross-site scripting) is so well-known and widely-exploited a vulnerability that elementary school kids use XSS exploits to log in to their accounts at school because it's simpler than trying to remember a good password.
Nevertheless…SQL injections and flaws that allow XSS exploits are just two of 10 incredibly common security flaws that continue to appear in eight out of 10 new commercial and corporate applications, according to security software vendor Veracode, which publishes an application-security benchmark report twice per year.
According to the latest report (PDF of the executive summary here, full report PDF here), despite the unbelievably heavy media coverage all this year describing hack attacks from Russian mobsters, Chinese spies, Anonymous hacktivists, LulzSec anarchist saboteurs and every copycat, wannabe and script kid in the world, eight out of 10 new applications examined by Veracode failed to meet security standards.
Most failed because of stupidly obvious flaws including poor implementation of protections that would prevent XSS or SQL injection attacks as well as a few that have not yet become household names.
It's not a small number, either.
According to Veracode, 68 percent of all web applications were vulnerable to XSS exploits and 32 percent were vulnerable to SQL injections.
Twenty percent of all the publicly acknowledged successful hacks this year – one out of five – involved SQL injection attacks, according to Veracode.
Neither are buffer management errors, buffer overflows, integer overflows and other weaknesses that would allow hackers to install backdoors or execute code remotely to help crack a local server.
Nevertheless, those obvious opportunities for application hijacking were more prevalent in commercial apps than in non-commercial according to Veracode, even though commercial developers should know better.
Android apps are just as bad. More than 40 percent of all Android apps hard-code a cryptographic key into the application. That makes the key available quickly, but also lets hackers who decompile the Android app to publicize not only the app and the flaw, but the number of the key as well.
There are three or four other major findings – issues about the amount of security training available for software developers, their awareness of security issues and their tendency to use the need to deliver software quickly as an excuse for building apps insecurely.
All those would be worth some discussion at some point.
They're all relatively high-level security issues compared to the lock-the-basement-window level of Duh-awareness necessary to realize that if you're going to put an app out on the web for the public to use, you have to reinforce it so at least the most common forms of attack won't work the first time or two.
Leaving those gaps unfilled isn't just asking for trouble. It's a demand that someone pwn your application quick, before you have to do something even more obvious to draw trouble – like allowing your 256-bit WLAN key make you feel secure as you leave the server closet and external building doors standing open as you log off the network and head for home.