Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
Programming Security

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

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.

This discussion has been archived. No new comments can be posted.

Why Do Web Developers Keep Making The Same Mistakes?

Comments Filter:
  • Wrong (Score:5, Insightful)

    by hcs_$reboot ( 1536101 ) on Sunday October 29, 2017 @02:34AM (#55451977)
    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 (Score:5, Insightful)

      by ovanklot ( 715633 ) on Sunday October 29, 2017 @02:49AM (#55451999)

      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 (Score:4, Insightful)

        by KiloByte ( 825081 ) on Sunday October 29, 2017 @03:15AM (#55452035)

        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.

        • 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".

          Obligatory reference [youtu.be]

    • Re:Wrong (Score:5, Insightful)

      by gweihir ( 88907 ) on Sunday October 29, 2017 @02:52AM (#55452005)

      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 (Score:5, Funny)

        by scsirob ( 246572 ) on Sunday October 29, 2017 @03:34AM (#55452053)

        We have a special name for those people who do not learn from their mistakes. We call them "Managers"..

      • Re: (Score:3, Insightful)

        by swilver ( 617741 )

        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 fr

      • Well yeah, because most are web developers; very few are web developers AND security experts at the same time, and they are usually way more expensive.
        Code written by web developers must go through a security audit and insecure parts need to be rewritten to close the security holes.

        • Code written by web developers must go through a security audit and insecure parts need to be rewritten to close the security holes.

          I think *all* code should go through at least peer review by a senior team member. It is the flamboyant prima donna who thinks they are above the rest of the team make the biggest blunders.

        • by gweihir ( 88907 )

          Tell me about it. I am a security expert and sometimes do coding for customers. For one large customer, I do cost about 2.5 times per hour than their regular coders. On the other hand, I think that their regular coders are directly more expensive and the time they need to do things (than then suck afterwards) is really impressive. I have seen quotes like $500k just for changing the path in a web-application and placing a proxy in front of it. Incredible.

      • 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.

        • by LesFerg ( 452838 )

          I must have been exceptionally lucky to work for an employer who also understood the importance of having a solid team of testers working closely with the developers.
          For a start we had to make sure that nothing a user could type into a text entry could break the web page or the database, either on the way in or when coming back out to be displayed, be it the most basic issues like apostrophes in user names or HTML tags and such.
          Then the testers had to learn all sorts of clever tricks to get around our best

    • by jrumney ( 197329 )

      That's not the same web devs making those same mistakes.

      True, the web developers from 2013 have all retired and taken up jobs in the fast food industry by now.

    • by tlhIngan ( 30335 )

      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.

      Well that pretty much applies to practically every job these days. The companies pursue money above all else, to the detriment of themselves - assuming everyone (and everything) is a swappable interchangeable part.

      Nothing can be further from the t

    • Re:Wrong (Score:5, Insightful)

      by cardpuncher ( 713057 ) on Sunday October 29, 2017 @05:38AM (#55452225)
      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.

      • This was my thought too - if you have a critical component in a system, you want to make it as difficult as possible to get wrong.

        Especially if there is clearly a "correct" and "incorrect" way to do something. There's a reason most sane cables either make it extremely difficult to connect in the wrong orientation or even better make it so all the likely orientations are serviceable.

        The tools and frameworks could pick up the ball and make it more difficult to get things wrong, this would be much less an iss

        • Agreed, BUT the correct way typically is a bit more difficult, takes a bit more time, and thus costs more. Fast and cheap is preferred by most managers, good not so much.
      • The mistakes are possible because they aren't always mistakes.

        How do you prevent SQL injection? Putting user input into other strings is a reasonable thing to do. Passing a string to the database is a reasonable thing to do. It would be a pain to use parameterized SQL for everything, and I don't know of a database that does.

        There's ways to sanitize a user-entered string so it can't be used for cross-site scripting. Make that mandatory for using user-entered strings and you'll break some other stuff

    • by zifn4b ( 1040588 )

      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.

      Yes, companies tend to search the bargain bin for unicorns even though it's completely irrational. Either they go with young inexperienced recent college grads or they go with H1B's. The headline ought to read "Why do companies keep making the same mistakes hiring recent college grads and H1B Visa's resulting in poor software quality instead of hiring talented, experienced developers who can write quality code?"

      The answer to this question is simple: Companies have champagne taste and a beer budget.

      Nothi

    • I beg to differ. Experience level has little to do with it. As QA I worked with about a hundred developers over the years and they typically want to use the newest hipster libraries and crank out new features that dazzle top management. Security, bug fixing, sound architecture, and reliable frameworks are tedious work that do not demo well, which is why devs tend no to bother with it. I run tools checking for injections and XSS on every page that has a form, I report the results in great detail....and for t
    • I wouldn't be too sure. A few dozen programmers that program that way, and possibly even teach how to program that way, could fill the web with thousands upon thousands of these common mistakes.

  • by Anonymous Coward on Sunday October 29, 2017 @02:35AM (#55451979)

    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 traditional life-cycle of a company has it being taken over by accountants just before it dies. Because accountants have real problems putting numbers to intangibles - like security. The developer hours required to implement security? *That* they can put a number to ... in the expense column. So, basically, as an expense with no immediate benefit, security gets the short end of the stick ... if it even gets that much. The situation gets worse when 'security' becomes another department. Then the g

    • That is because security is a subset of quality and software companies rather hire more support staff than have devs fix bugs. If you love self-punishment and quixote-ian endeavors then enter QA. Every day I see the taps on the back of devs, but never in my 20 years of QA did anyone come by my desk and tell me I did a good job testing and making the company tons of money by keeping customer retention high. And yes, I still report the same errors made years ago and often it is the same dev making the same m
  • by gweihir ( 88907 ) on Sunday October 29, 2017 @02:49AM (#55452001)

    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.

    • by gtall ( 79522 )

      Yes, there is plenty of blame to go around. Part of that blame is on CS depts. I was once associated with a CS dept. of a major midwest uni. They said they had an "honors" group of students. I got saddled with three of them for a project in Java. When I asked if they could whack together something that did X, they grumbled, moaned, whined, and produced nothing. They didn't know how to get started. Yet they all went on to "promising" careers in industry...and they were seniors.

  • by bradley13 ( 1118935 ) on Sunday October 29, 2017 @03:01AM (#55452017) Homepage

    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.

    • Re: (Score:3, Funny)

      by Hognoxious ( 631665 )

      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.

      Look on the bright side, it didn't need systemd or gnome.

    • by gweihir ( 88907 )

      I fully agree on all of these. I also teach a software security lecture, and last year one student summarized the purpose as "warn everybody to get an expert and not to do it themselves". Well, at least that one learned something.

      As to the last point: This is a real catastrophe in the making. Nobody still understand what they do and their dependencies seem to grow all the time. I now push "does not depend on frameworks" as a sign of quality to customers, wherever possible.

      • by swilver ( 617741 )

        Quality? That's not quality. *OUR* software comes with its own Kernel, or are you gonna deny that Kernels aren't full of security issues? Some kernels consists of over 15 million lines of code! Did you check all those?

        Sure, customers are surprised at first when none of their other software runs anymore on machines with ours installed, but it is guaranteed secure.

      • If you were teaching civil engineering, the first day you would be showing them a film about the bridge that blew down because of its design failing to accommodate for its stress inputs. And the fact that people's lives were on the line.

        I would very much like to know what the first day in your course is like.

        I think you have to honestly look at yourself and if you are not educating developers on how and why injection flaws work, and how they must be stopped at every handoff of data between interpretatio

        • by gweihir ( 88907 )

          Ah, yes. "Bouncing Betty" (or "Galloping Gertie"), the Tacoma Narrows Bridge. I saw a picture in my Software Engineering course. Do you have a source of the video that is not YouTube? I should indeed show that to my students as a reminder that they will be engineers and that engineering failure can kill.

          My first lecture starts stating that almost every piece of software these days is connected to the Internet in some way. Then it gives a broad overview over the things that can go wrong. I will treat them in

    • by swilver ( 617741 )

      Too many frameworks... that's a good one. You're worried about the vulnerabilities in some of the most stable, highly scrutinized, fully unit tested and secure frameworks Java has on offer and because of that... you roll your own.

      I guess I know what is really wrong with the industry: developers that think they can create their own framework, replacing several dozen man years of coding, debugging and testing in just a few days -- and then having the arrogance to think it will contain less vulnerabilities ri

      • by Bongo ( 13261 )

        I think there’s a side issue: only by trying to write one’s own, does one start to understand the problem. So as a learning excercise, trying to write one’s own is really useful. And then, use a proper framework. Otherwise there’s the opposite problem of people relying on frameworks which they don’t understand.

      • Depend on the amount of code from the framework you actually need. If you're bringing in half a million lines of code to do something that could be done in a couple of thousand, then you're probably better off rolling your own: it's going to have far more tightly coupled logic and be more amenable to static analysis, as well as being an easier target to fuzz test.

        If, on the other hand, you end up implementing most of the logic in a dependency, then you're probably better off using the one that's widely

      • You're worried about the vulnerabilities in some of the most stable, highly scrutinized, fully unit tested and secure frameworks Java has on offer and because of that... you roll your own.

        Because a random huge piece of code is likely to be bug-free?

        • by swilver ( 617741 )

          For a random piece of code, I don't know.

          However, we weren't talking about a random piece of code, but some of the most used frameworks (in any language) on the planet.

          What do you think is a more likely source of security bugs?

          a) Closed source code written by your team / company, used by only your team and maybe a few others in the company, with a small end-user base (a few hundred thousand) in a maybe half a dozen apps or websites?

          b) Open source framework code, with regular releases used by millions of dev

      • You can also have fully unit tested code, and as soon as you start integrating it into another system, things fall apart.

        Integration testing is much much harder than unit testing.

    • by Kjella ( 173770 )

      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.

      And some of them will be working for PHBs that don't understand, don't care and can't be bothered. Far too often the only metric people are measured by is whether the code does the right thing with the right input under normal execution. Error handling? Security? It's working, ship it. That's what you get measured on. That's what your boss gets measured on. If you say it "isn't any more complex" and they do it anyway it's clearly because they don't get corrected or rejected. Those errors conditions are for

    • Too many frameworks.

      The problem is more commonly one too few frameworks: specifically, people going above their pay grade and reinventing the CMS. Then they get the opportunity to make all those errors. If people just begin with a working CMS, they get to make a whole different class of mistake instead :)

  • 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.

    • Yes, yes, yes! This is EXACTLY how stuff goes down. It takes quite some self-control not to punch those guys who claim that we will fix all of this later. Fixing it later will be much more difficult and thus cost more time and money. Worst thing is to have a team only dedicated to bug fixes. Each developer needs to fix the own code and do so as soon as an issue is identified. Those devs who screw up a lot will then not deliver much in value and are very easy to identify. Give them extra training and monitor
  • I think that most frameworks and CMS's don't provide the right security that is needed to create a secure website. They offer protection against SQL injection, XSS and other common attacks, but don't provide a means for developers to make sure they used it correctly. Look at all the Wordpress plugins that keep on being vulnerable. How do you know a plugin is secure or not? In my opinion, there is a big difference between secure code and provable secure code. So, it's not only web developers making the same

  • There is room in budgets to pay attention to some good practices or enforcement thereof by peer review. But often - especially with custom-made sites - it is simply not enough. I've seen plenty of projects where the design company was granted bigger fees for more hours than implementation, stereotypically also making everyone overly complicated. Even during scrum sessions where developer input is more present, doing it quickly is a much larger focus than doing it right. In the end, that simply leads to slop

    • by gtall ( 79522 )

      "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.

    • So there is no budget for doing it right the first time, but there is budget for gluing together hot patches when stuff blows up in production? Any manager with that idea needs to be slapped with a wet noodle for days.
  • 27 people have already pointed out that web devs are fucktards, so I won't. Remember that they took something designed for displaying static pages and shoehorned interaction & dynamic shit onto it. The whole thing is built on sand.

    • Why are C developers still writing buffer overflows?
  • Learn how to properly parse an email address!!!

    It's upsetting how many web sites tell me a valid email address is invalid because the developers don't use a library that parses it correctly and don't bother looking up what is actually valid. Apostrophes and pluses are the main characters they get wrong, among others.

    • 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.

      • by DamonHD ( 794830 )

        Getting such a regex right is MUCH harder than it looks:

        https://stackoverflow.com/ques... [stackoverflow.com]

        Rgds

        Damon

        • Depends on whether you want to support pre-Internet addresses, as that's a good part of the spec. If you drop stuff like routed addresses or comments/whitespace inside a domain, the rest is quite simple. Your MTA likely won't accept "@node.test:mary@ (this is a comment) example (whitespace around .) .net" thus it should be dropped at validation time.

          • by DamonHD ( 794830 )

            I hear you. (I used to run a significant UUCP mail node, BTW!)

            But then we have to agree on a definition of 'right' for the application, which is nuanced.

            I still have a perfectly valid address rejected sometimes because it's 'too short'! (It's of the form X@YY.ZZZ)

            Rgds

            Damon

      • The problem is that there is not one RFC that defines an email address!! There is one that covers the top level domain (if present), one that covers the domain name (if present), and one that covers the account portion. There isn't even a mandate for the @ to be present as it is not needed when sending email within one domain. What makes matters worse is that there is no official standard. RFC means "request for comment", it is not a finalized standard. What makes it act like a standard is that everyone adh
    • by swilver ( 617741 )

      Email addresses either work or not (that's what the verification mail is for). Why software bothers to "parse" these at all I never quite understood -- there is nothing to parse, nothing to extract, it is a piece of text that when fed to an SMTP program may or may not result in a mail to whoever is filling in your form.

      If I want to give you a wrong email address there is nothing you can do about it anyway. If you want to be sure, you send a verification mail, no parsing needed. The mail either works or n

  • "Why Do Web Developers Keep Making The Same Mistakes?"

    StackOverflow.com

    (they read the same wrong answers as other people, because every "I found this useful" or "Lots of people read this" ranking system does not detect factual errors, only opinions)

    • by Megane ( 129182 )

      Came looking for this, was not disappointed. They keep finding the same broken half-answers on a web site that is skewed by people scamming for points.

      I never signed up for SO, and now it's not worth bothering, because between so much already having been answered, and people who know less than they think they do down-voting good answers, I could never get any kind of decent reputation score, short of creating my own programming language that got popular so I'd have fresh questions to answer.

  • It's because they themselves don't suffer the economic loss of fucking it up.

    -jcr

    • This deserves to be moderated up, perhaps with the corollary that often they will suffer economic loss as a result of taking the time to do it right.
  • Even the simplests of software consists of thousands of lines of code where a simple mistake can compromise the system. People make mistakes. Online documentation gives flawed examples. It will take an infinite amount of time to write software to perfection. The poor guy in India working 80 hours per week coding the system has no way to know every system he is writing code for. Nobody has ever told the entry level developer that the secure_rng() or mysql_escape_string() library function is in fact not secu

    • Exactly. It will take an infinite amount of time to write software to perfection. Everyone here is bitching about it, but what is your alternative? Get a grip people, suck it up or do without software and go back to pen and paper.
  • my students make the same mistakes. It is as if they learn nothing...

  • can it be that often times "Beware SQL injection! ..." is followed by "and I need it yesterday"?

  • Web developers are more interested in showing off the latest and greatest procedures, bouncing ads and every unnecessary script they can lay their hands on than they are producing a usable web page.

    Within the last week I am suddenly unable to access the comments section on a web page I have gone to for years. Most likely because the developers changed twenty scripts and since I never run the latest and greatest browser, comments are now inaccessible.

    There is absolutely no reason not to have a link work in

  • Ctrl-C Ctrl-V (Score:4, Interesting)

    by digitalhermit ( 113459 ) on Sunday October 29, 2017 @06:44AM (#55452373) Homepage

    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

  • People keep thinking they can do better by themselves than whole teams of coders hammering on code and getting patches from dozens or hundreds more users, and they keep getting proven wrong. Why would anyone reinvent the CMS at this point?

    • Because all of the ones out there suck in varying degrees. Same with browsers and operating systems, they are all a crap fest.
  • Lots of interesting comments but didn't see this one so though I'd throw it in: Not Invented Here Syndrome.

    I've seen this first hand a lot. Manny developers will get a project, review some options for components (e.g. CMS is the classic one) and decide that because that component only needs 99% of requirements, they should roll their own solution, because using that component and modifying it will take to long as they have to learn the extension system or whatever.

    As a result they end up writing lots of new

  • Agile (Score:4, Interesting)

    by geekymachoman ( 1261484 ) on Sunday October 29, 2017 @09:00AM (#55452745)
    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.
  • All too often it looks like websites are designed by the stupidest member of the team. For example, the password policies that many sites impose range from preposterous to downright ignorant.
  • Management doesn't care enough to fire them when they fuck up. If developers knew their job was on the line they might pay more attention to security. You can train them all you want, but if there are zero consequences when they ignore that training then they'll continue to be lazy.
  • "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.

  • by FrozenGeek ( 1219968 ) on Sunday October 29, 2017 @09:12PM (#55455539)
    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.

Houston, Tranquillity Base here. The Eagle has landed. -- Neil Armstrong

Working...