Why Do Web Developers Keep Making The Same Mistakes? (hpe.com)

An anonymous reader quotes HPE Insights: Software developers and testers must be sick of hearing security nuts rant, "Beware SQL injection! Monitor for cross-site scripting! Watch for hijacked session credentials!" I suspect the developers tune us out... The industry has generated newer tools, better testing suites, Agile methodologies, and other advances in writing and testing software. Despite all that, coders keep making the same dumb mistakes, peer reviews keep missing those mistakes, test tools fail to catch those mistakes, and hackers keep finding ways to exploit those mistakes. One way to see the repeat offenders is to look at the Open Web Application Security Project Top 10, a sometimes controversial ranking of the 10 primary vulnerabilities, published every three or four years by the Open Web Application Security Project... It boggles the mind that a majority of top 10 issues appear across the 2007, 2010, 2013, and draft 2017 OWASP lists...

It's sad that eight out of 10 of the issues from 2013 are still top security issues in 2017. In fact, if you consider that the draft 2017 list combined two of the 2013 items, it's actually nine out of 10. Ouch... What can you do? Train everyone better, for starters. Look at coding and test tools that can help detect or prevent security vulnerabilities, but don't consider them silver bullets. Do dynamic application security testing, including penetration testing and fuzz testing. Ensure admins do their part to protect applications. And finally, make sure you establish a culture of security-aware programming and deployment.

Comments

Wrong

[hcs_$reboot]

That's not the same web devs making those same mistakes. Developers with some experience do not write code that fails against easy sql-injection. But companies prefer to hire younger inexperienced devs for the reasons that have been discussed here on /. many times.

Re:Wrong

[ovanklot]

That's not the same web devs making those same mistakes. Developers with some experience do not write code that fails against easy sql-injection. But companies prefer to hire younger inexperienced devs for the reasons that have been discussed here on /. many times.

I'll add to that that this isn't limited to web developers.

Re:Wrong

[gweihir]

Does not match my experience. Some (few, say 10%) of these people do indeed acquire insight and experience with more time in the field, but most do not seem to. They make the same basic mistakes and have the same defective and incomplete understanding of how thing work, 5 years in, 10 years in and then they move to another field because they have become unemployable in their "specialty".

Re:Wrong

[KiloByte]

I'll add to that that this isn't limited to web developers.

Hell yeah this. In most fields, there's decades of prior wisdom that one should at least try to get a grasp of before making "brilliant" inventions. Like, you shouldn't write an init system before reading "Unix for Dummies".

Things like SIGHUP/nohup are basic knowledge, if you don't know this you shouldn't write your snowflake way of killing processes on logout. If you don't know ways to authenticate users and what user names are explicitly allowed by POSIX (the 0day issue), you shouldn't create a gaping security hole, and even worse, you don't WONTFIX it just because one of your distribution's clicky-clicky tools doesn't allow such names, while "$EDITOR /etc/passwd" or LDAP are "user errors".

I'm for one a kernel newbie -- yet I know better than when faced with a problem like "shit network driver does high-order allocations while atomic, with disastrous reasons when under memory pressure" to rush into making an ad-hoc pool instead of reading how it should be done, or asking those with a clue. The former was my first reaction, yet I at least bothered to think before wasting developers' time with a bogus patch.

Re:Wrong

[swilver]

Those few are the ones you want to keep. However, you won't be able to keep them if you don't pay them well, or make their lives difficult/annoying with stupid management decisions. They'll be the first to leave as they have many options and don't have to deal with stupidity -- leaving your company with those that seem unable to learn from their mistakes, or just don't give a shit.

I'm considered a decent developer, and if you want to keep me you better be prepared to pay me significantly more than that fresh CS graduate that just joined the team, don't give me any shit, trust what I'm doing and let me do my work unsupervised -- like how you would treat another person that you've come to respect and trust.

Do that, and I'll pro-actively come up with ideas and solutions for problems you didn't even know existed yet and will treat your software as my own making sure that no harm comes to it, not from inside or outside the team.

Failing that, I'll just rake in some money until something better comes along, while you only get maybe 50% of my best as the constant distractions/annoyances/stupidity just don't foster a good environment for creative work.

Re:Wrong

[cardpuncher]

More to the point, why should these serious "mistakes" be possible at all.

If these errors keep occurring, you have to stop blaming the web developers and start blaming the technology. There is no good reason that cross-site scripting or session hacking should even be possible. It's a mad idea to turn user input into a human-readable SQL command string when no human needs to read it.

The problem is that we stared off with insecure shoddy hacks and there has been a whole slew of incremental mitigations, none of which happens by default in order not to break further the already-broken crap that's out there. That's not the fault of the application developers, that's the fault of the browser and server developers.

Security is always last

[Anonymous Coward]

Security is always last when implementing a new piece of software. Until management gets that security is vital to their well being, this will continue to happen. But since they have cybersecurity insurance and since everyone has the memory of a goldfish, the company will be fine, and therefore they don't need to spend the money on it. After all it would just be an added expense and possibly delay the introduction of the software in the first place which could ultimately be worse than having a buggy program.

The real problems are...

[bradley13]

IMHO, these problems stem from the following source problems:

- Incompetent developers. Look at the number one problem, number one for years now: injection. I teach students how to avoid this the first time they touch a database, which is typically in year two of their degree program. It doesn't matter: half of them still write injectable queries, even though using "prepared statements" isn't any more complex. The thing is: there is so much code to be written, that even these students - who evidently don't understand, don't care, and can't be bothered - even these students will find jobs, and some of them will be working on your web projects.

- Internet speed. TFA talks about "agile methodologies" as if they were a good thing. While "iterative development" absolutely does make sense, in too many companies "agile", and "Scrum" and their brethren are an excuse for pushing half-tested code out the door, because everything has to be fast, fast, fast . I have news for the marketing department: No, your latest brainstorm does not have to be live next week. In fact, given that the brainstorm-after-next will basically reverse this one, it would really be better for everyone if you just fell off a bridge and drowned.

- Too many frameworks. Real example: I used to use Guice, a small dependency-injection framework from Google, for a small demo-project. A few months ago I decided to update Guice to the latest version. But the latest version depends on another framework, Guava. Guava requires JavaX. JavaX requires Spring. Spring requires...good god, at this point I deleted Guice. I mean, seriously, binding in that much foreign code? First, you are now dependent on all that code, and whatever changes are made to it. Second, you are bringing in all of the vulnerabilties present in that code. And you have absolutely no idea what those may be, because you certainly aren't going to validate all of that code yourself. Thank you very much, I'll just implement that small bit of functionality I need, all by myself.