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.
Next question.
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.
The pressure to release early and often is extreme. "MVP" rules the day, and no one in most senior roles has the granular perspective necessary to be aware of "security" as a concept. Is it checked into the testing repo and does it run? PUSH IT OUT. We'll fix any bugs as we "iterate."
Oh wait, we won't actually iterate. Because existing features don't get us as much as releases of new ones. We'll just keep pushing out new ones as fast as we can.
Security? Hell, often even basic functionality doesn't work. Release it broken, then declare it that part code deprecated in favor of new versions with new features in six months. Even if security is flawed, that's okay, it was only out for a few months "that way." Anyone still using it should have upgraded. If they don't it's their fault.
There are flaws in the new version/new features as well? Well they've only been out for eight weeks. It was an MVP. We're agile. We'll fix any bugs as we "iterate..."
etc.
STOP . AMERICA . NOW
Actually, most libraries are wrong, too. If you look at nodejs, it's astonishing how 90% of packages that ship a single line of code (plus tons of boilerplate) get even that single line wrong.
It doesn't take a genius to look up the relevant RFC and write a regexp.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
Why are C developers still writing buffer overflows?
"scrum sessions" There's your problem right there. Agile does not encourage good overall design. It is a micromanagering dream and causes coders to only work for the next sprint goals. As long as their little piece of the pie works, they get rewarded. The entire dirty snowball that gets produced is merely a by-product.
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.
I've been thinking about this for a few years and have come to the conclusion that we will continue making the same mistakes until we can create a set of rules that everyone can follow. If you look at what civil engineers have done you will see that they have reduced much of what they do to equations and repeatable patterns (for lack of a better term). When someone sets out to build a bridge or a building, they start by designing it with an architect and then they pull out the equations and key tables to ensure that they have the load, weight, use, wind and all the other elements take into account. This is coupled with a very strong set of building codes that dictate minimum strengths, materials and designs to ensure safety. Setting aside the occasional corner cut in construction or neglect, when was the last time a building or bridge just collapsed? (Ok, we know the bridge in Minneapolis, but that wasn't design it was neglect)
It's this level of discipline and rigor that ensures what engineers and architects design and build will work as planned. Couple this rigor with government and professional group mandated licensing of practitioners (try getting a building built without a professional engineer stamp on the design certifying the design is sound) and you can ensure that those designing and building something has a minimum level of training and understanding of the basic physics and processes to ensure sound design.
Until software development can create those same sets of rules and patterns, we will be doomed to repeating the same errors over and over. What we're doing right now is the equivalent of showing someone geometry, basic physics and some sense of writing and then expecting them to design and build the Empire State Building, Burj Khalifa or an Airbus A380. If our physical counterparts did the same, then no one would even think of flying or sleeping in anything other than a tarp strung from trees.
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.
Unless you're targeting a system with 32KB of RAM or less, or you have very strict realtime guarantees (and so aren't even using malloc) there's rarely a good reason to use C these days.
I would dispute this 32 KiB figure.
Several years ago, I wrote a program for Game Boy Advance homebrew that used a single std::ostringstream once, and even after enabling -Wl,--gc-sections, the statically linked executable was 180,032 bytes. It turned out that the constructor for a std::ostringstream in GNU libstdc++ would call the constructors for date, time, and currency formatting aspects of the locale even if I never output a date, time, or currency object. For a scale reference, the GBA's RAM is 32 KiB of fast RAM, 256 KiB of slow RAM, and 96 KiB of video RAM. Although up to 32 MiB of execute-in-place ROM in the cartridge is available for a single-player game, no cartridge is inserted into the systems of players 2, 3, and 4. Thus the program has to fit completely into the 256 KiB of slow RAM, as the fast RAM is used for the stack and BSS.
My experience is the same, most (but not all) experienced people are people who have been doing the same stupid shit for a long time. Some people put in the effort to learn something new and improve every week. Most people don't.
For those who DO try to constantly learn and improve, the security community has made a mistake in how we try to help them. The OWASP top 10 list was mentioned. I'm a member of OWASP. The list, which we promote, is a basically list of how bad guys can exploit vulnerabilities. We say "SQL injection". What does that mean to a developer? What is the developer supposed to do or not do with that? Perhaps it would be more useful to publish a list of SOLUTIONS, best practices, things developers should do.
Instead of saying "SQL injection" it might be more useful to list "parameterize SQL statements". That's something developers can do.
Instead of "cross site scripting", how about putting "hrmlencode all output strings" on list. A developer can call htmlencode(). They know how to do that. They don't know how to "don't allow cross-site scripting". The proof of that is in 90% of code that TRIES to prevent cross-site scripting; it doesn't work. Most attempts at stopping cross site scripting are easily defeated. Even when they try it doesn't work, so why should they bother to try? If we tell them "use htmlencode()" that will work, and it's easy for them to do.
"Why do drivers keep making the same mistakes? It looks like eight of the top ten causes of death on the highway are the same as they were in 2013."
Um because this shit is difficult, and if you don't know anything about it, it's easy to ask vapid generalized questions that seem meaningful.
StoneCypher is Full of BS
My experience is along the following: Noobs develop a new website. Senior devs have little time to review what the noobs have done. Website goes live. Users are happy. A year or two down the line, the former noobs move to other employers so as to obtain a real raise. Some time thereafter, serious security flaw is noted on original website. Flaw is fixed by senior devs, who may, or may not, adequately explain the problem to the noobs currently maintaining the website. The original devs involved never learn of the flaw or the fix. Simply put, we are not adequately taught security in school and we are unlikely to learn it at work. Compounding the issue, there is always a rush to production and very often security is the low priority task that gets tossed in order to meet the (artificial) deadline.
linquendum tondere