Eight in 10 applications failed to pass stricter security testing standards in test by application security assessment firm Veracode. Veracode tightened up its testing procedures so that apps prone to cross-site scripting and SQL injection errors automatically failed. This zero tolerance policy reflects that fact that these two …
It's a reflection of the IT world more than developers.
When, out of boredom, the n00b script-kiddie hacks out a random solution to an obvious business problem, we say "Awesome dude!" and put the thing into production.
If you told that n00b scripter to make the app secure it'd add another 11 man-months to the 1 man-month spent on dev - because the n00b scripter would have to learn security. You'd hear that over-used phrase "security is hard".
Security isn't hard. Even when you go past SQL injection and cross-site script attacks, it's no harder than coding up a breadth-first tree traversal. If you bothered to learn, you'd know how to build it in from the start.
We (IT pros) are, in general, pretty crap at assessing risk. We're really good at maintaining the status quo.
You're not paid to assess risk
You're paid to churn out code. Get churning. Don't you dare waste company time on anything extraneous to the project requirements... if they don't mention any sort of security tasks then you are absolutely not allowed to 'secure' the software.
Re: You're not paid to assess risk
What you say is both true and quite reasonable for the huge numbers of apps that won't ever be used in a hostile environment.
Against that, the article talks of "cross-site scripting and SQL injection errors" which presumably means that the apps in question are either intranet or internet-facing. The customer *will* have security requirements for such products, unstated or not. The project managers therefore need to *discover* those requirements and need to *include* them in the spec they give to the code monkeys. It therefore *saves* company time for the monkeys to raise the alarm early if they are missing.
But yeah, Dilbert-style "management" might not buy that line of argument.
You're not paid to churn
You're paid to add IT value to the company. If you can't churn out SQL injection free code, then seriously, fuck off, stop calling yourself a developer, it's time to join the ranks of Project Manager.
It's not exactly tricky is it? Sanitize your inputs, use an ORM to build your queries rather than generating SQL queries by hand, or at the very least use a DB abstraction layer to perform parametrized queries.
AC because of this bit:
At $JOB, there are several 'Project Managers', people who 1 year ago were 'Senior Developers'. These people now don't look at the code - seemingly, ever. They don't write code, they don't check commits, they simply check deadlines and status reports.
The actual code writing for these projects is done by the most junior developers we can hire, or 'insourced' to our dev team in China. The PMs would have never written code that is vulnerable to an SQL injection, but they won't notice when one slips into their project. They rely instead on code reviews, run by the same juniors with a PM moderating, to catch this kind of shit.
I'm the other kind of PM, no code goes into my repos without me reading, grokking and accepting it. Most commits from a new member of my team will get a follow up email explaining what needs changing, and eventually they get it, or they get another team.
@AC 8th December 2011 23:01
<quote>It's not exactly tricky is it? Sanitize your inputs, use an ORM to build your queries rather than generating SQL queries by hand, or at the very least use a DB abstraction layer to perform parametrized queries.</quote>
So, maybe not quite a simple as you suggested; but every competent DB developer knows that those are the things that should be done, and none of those things is the least bit complex or difficult, so almost that easy.
Keep smoking the crack, Arthur Dent, I'll keep using my ORM.
Quick, pray tell
Which Government is Veracode talking about? Come on. Tell all. No good giving us only 27.5% of a story!
Your suggestions seem reasonable, at least from a DBA-centric perspective, but I would hazard a guess that a small proportion of web apps use the model you propose. If "none of those things is the least bit complex or difficult" then why is this the case?
ORM is powerful, convenient, portable, adequately secure and performant for a given level of effort/expertise. I probably wouldn't propose it for an online banking or health records app, but then what proportion of the app space does that cover?