Patchy app development security slammed

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 …

[Spearchucker Jones]

No surprise.

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.

[Ru]

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.

[Ken Hagan]

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.

[Anonymous Coward]

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.

[Arthur Dent]

@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>

No, don't use an ORM - work out what functionality the app needs from the database and provide that functionality as a set of stored procedures. Using an ORM generates a strong coupling between the database schema and the apps object model, throwing away any chance of true modularity. Using stored procedures for the interface decouples the schema from the application, the application doesn't even have to know what tables and views exist, just what procedures it can call (that's also why you don't use parametrised queries instead of stored procedures). This makes maintenance and future enhancement much less error prone, and is perfectly secure against injection unless you have a lunatic database developer who commits the crime of using a string parameter from outside to construct sql text to be executed. Verify all inputs in the app too of course - and even if you have client side input verification do it again server side, because it's easy for me to write a malicious browser that modifies your client-side Javascript or VBScript or whatever it is you use and sends you whaever inputs I want without their ever having been seen by your client-side validation. And normalise the database schema at least as far as EKNF, preferably to 5NF with possibly some tables left at EKNF to preserve the representation principle, since that too makes maintenance easier (by making the schemas keys and constraints enforce conformance of the data to all business rules that are expressible in the unnormalised schema as domain constraints, functional dependencies, multivalued dependencies, or projection-join dependencies, so that a large class of bugs can never occur. And finally, make sure that the apps connection to the database uses a user (preferably an OS user, but a database user will do at a push) whose only permitted actions in the database are executing the stored procedures provided for the app, has no access to tables or views at all (the stored procedures should have permissions inherited from their authors, instead of from the app, so they can access and update the data; but the app can't do that except by calling the stored procedure, even if some rogue developer tries to stick some ad hoc queries into the app). And encrypt your database backups, using keys that change when they need to rather than stay for ever the same, and encrypt your database too (only change that key if you think there's a risk it is compromised, as it's a pain in the but to do). Of course if your physical security is such that you can guarantee no-one can steal a hard disc, or intercept traffic between you server and your SAN, or get hold of a discarded hard disc with either the database or backups on it, or if the risk is low, the potential damage if the risk is realised is also low and the extra software licensing cost of having database encryption is too high (you won't get it with a MS SQLS Standard Edition license, for example, you need an Enterprise license) you can maybe skip the encryption.

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.

[Tom 38]

Keep smoking the crack, Arthur Dent, I'll keep using my ORM.

[taxman]

Quick, pray tell

Which Government is Veracode talking about? Come on. Tell all. No good giving us only 27.5% of a story!

[Anonymous Coward]

@Arthur Dent

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?