Slashdot Mirror
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.
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.
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.
Slashdot, fix the reply notifications... You won't get away with it...
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.
Web application developers are the lowest-skilled, least educated and least talented people in the IT space. I recently had to explain to some people with supposedly 5 years experience in that space what an HTTP header looks like, because they had no clue. Same for basically every other aspect, like cookie naming, how to make you application able to work behind a proxy (in an enterprise-environment, no less), etc. It is staggering how clueless these people are. All they seem to see is a framework, which they barely understand and then put an application on top that makes all the basic mistakes you can think of. Of course, they eventually remove the mistakes that break the application in the specific target environment for a specific browser, but that is it. Forget about any understanding of the mechanisms they are using or of IT security. Some do not even know what an IP address is or how an URL is composed from components.
So in essence: Developers that are grossly incompetent and management that is grossly incompetent for hiring these people. As we have a lot of "bean-copunter" types in management these days (MBAs and even less competent ones), things will not change anytime soon.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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.
Enjoy life! This is not a dress rehearsal.
Many APIs have demo code in curl or Java with the express warning that it's demo code and not to be used in production. But it shows up anyway.
I worked on a project last year where some offshore developers were tasked with writing an integration to a RESTful API for Nexpose. As far as "web programming" goes, talking to a REST API is pretty much a sine qua non for being called a "web developer". They didn't know how to do so. I understand that members of this same team have worked on other corporate sites.
Combine CTRL-C/CTRL-V with inexperience and you have the source of your mistakes.
What does agile have to do with it, except make company spend money on "scrum masters" and other nonsense instead of hiring a proper security team ? While it has some good ideas, i wouldn't attribute improvements in security to standup meetings, runs and scrum masters.