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.
Companies (especially startups) are too focused on getting the next feature released before the next deadline. Security is one of their lowest priorities. Once they are acquired, it's then the acquiring company's problem to deal with.
is it not clear yet that this is a cultural issue in the way buisnesses are run and setup and not a technological impossibility?
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
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 mistake. It's also frameworks and CMS's not providing a true secure base.
In the framework I make, I always keep in mind that some other developer will use my code to build an actual website. How will that developer use it? How to make sure that developer uses it correctly? Whenever possible, I make sure that things are secure and restricted. If you want to do things that are potentially insecure, you have to disable certain security checks. For example, all output is escaped to prevent XSS. If you really want to output HTML, you have to disable the escaping. My framework comes with a script that performs a security audit for common errors. I really think that my framework is the most secure available and it's very hard to build something insecure with it that is hard to detect.
It doesn't have to be like this. All we need to do is make sure we keep talking.
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 sloppy code. This is of course not true for every situation, but I've seen it happen far too often.
You're sitting at the computer. The project deadline has just been published. Those fifty feature requests that you've been telling management will take a week each to implement properly? You have two months, total, for all of them. Management is screaming at you to get it done. You don't have time to do more than basic testing. It seems to work? Great! Move on to the next thing.
Meanwhile, figuring out all the ways in which the code will break - you haven't got time for that. Just pray that the security holes aren't too serious. Firewall? Which ports do we need? Oh, the hell with it - open everything up, go nuts, because figuring out exactly which ports are needed for what is just Too Damn Hard.
Until there are direct, measurable, verifiable, financial costs for getting it wrong, management is going to push back on all those fancy security measures, because it doesn't add anything obvious. It's not like building a house, where if you get the foundations wrong, the whole thing will collapse - so the walls get built out of wet sand; the roof gets put on without any supporting joists; and it's a bloody miracle the whole thing doesn't fall over in the slightest breeze.
Then, too, you have people who just don't care enough about the craft to learn what they're doing and why they're doing it. Cargo cult programming is a major thing, taking code snippets from Stack Overflow or wherever, pasting them together in something that looks like it came straight out of the Exorcist until it seems to work properly. Side effects? What are they?
Or maybe it's just shipped off to the cheapest code monkeys they can find, not realising that they're paying peanuts, so the end result is going to be fortunate if it even vaguely resembles, in the dark, if you squint, the original requirements...
All hardware sucks. All software sucks. But damn me if it doesn't seem like it's getting worse these 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.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
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.
Any business goes through an initial development phase of creating a minimum viable product. During this time, the company needs to decide if it is going to survive or not, and it must make this decision absolutely as soon as possible.
The SOONER the business idea can FAIL, the faster the resources can be put into the next possibly viable idea. And most ideas do fail. So during the minimum viable product phase, it actually does not make economic sense to write good comments, have coding guidelines, or yes, eliminate security vulnerabilities.
The sensible time for businesses to invest in security is: "as soon as you can afford it," which is when you have ramped up some customers and have some recurring revenue, maybe a B funding. By this time, there is a lot of code written and the business processes need a kick-start to introduce security. If the CTO or chief inventor is resistant, the security enhancements will unfortunately not be taken up correctly. If you wait until too late (3rd parties and customers customizing your APIs, or acquisitions) it costs 100x more to get the security work done.
the second reason is: Lack of good security education in university. A few professors have posted here already about how their students are idiots and don't get it. The thing is you cannot bolt on basic security knowledge at the end of a course and expect it to stick. Every coding course should be a secure coding course as much as it is a (nobody would say this) CORRECT coding course. The end result is most students emit from university having heard the phrases cross-site-scripting, sql injection, buffer overflow -- but do not know what they are or how to prevent them.
"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)
"For a successful technology, reality must take precedence over public relations, for Nature cannot be fooled"
It's because they themselves don't suffer the economic loss of fucking it up.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
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 secure for his particular case. Code auditing or testing can never check everything. You only notice the places where things go wrong. Things that were secure once are no longer secure, but the code is still there. It's just a prototype, we'll never use it in production. It's 1985 and you haven't considered that someone will still use this code in 2017 or hook up your code to a network. Got to make the deadline that was set deliberately tight by an 'efficiency' seeking project manager. The experienced programmer was too expensive. Someone else was supposed to filter that variable.
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"?
Absolutely not caused by newbies.
It seems quite sensible to assume that more experienced developers are way more likely to deliver better code than less experienced ones, so your general statement is certainly wrong. If you want to make generalisations (I don't like that too much though), note that most of the problems in programming and virtually everywhere else are likely to be caused by ignorance, short-sightedness and lack of experience. In programming, all these "features" are very common among newbies, non-technical staff making decisions without having a proper understanding of what they are doing and similar. I think that all this is extremely evident and is not the main reason why I am replying to you, but what is written below.
it was littered with string concatenations to build SQL queries,
I will never defend a-priori non-ideal approaches or code (and programmers) about which I know nothing. But I will always criticise blind trust in anything, including what seem better proceedings. SQL injection isn't more than an output of a behaviour which might be described as not having the situation controlled. It belongs to the same category that type-mismatches, boundary overflows and other errors appearing in algorithms where certain scenarios aren't properly accounted. The person writing SQL-injection-vulnerable code is extremely likely to have written many other wrong parts. These codes are created by people not understanding the underlying functionalities (how SQL databases work), not putting too much effort/care on that code or wishing things to be in certain way without confirming/dismissing that issue. Writing connect_to_db("string variable not sanitised") is pretty much the same than NumericType var = "non-numeric-type".
A developer not understanding, applying, accepting the aforementioned ideas everywhere and just focusing on blindly repeating whatever approach might sound better for that situation is extremely likely to provoke other problems. I am fully aware about how to use parameterised SQL queries in any language (= knowing it right away or spending 5-10 seconds researching it) and the (dis)advantages of relying on many other approaches (e.g., specific vs. generic types); and I might choose one approach or the other depending upon the scenario. In fact, I tend to rely on string concatenation for SQL-query building. Nothing of that has absolutely any influence on the resulting applications (safe, reliable and efficient) or the generated code (well-structured, commented and usually scalable); because I know what I am doing, because I am experienced and sensible enough to not blindly apply and trust in generic anything, because I do have a full control over the code which I write, all its inputs/outputs and because creating a proper piece of software can be accomplished in an infinite number of different ways, many of them identically good.
When you forget about all that (having the proper result you are looking for) and start focusing on irrelevant issues (worrying about making sure that you apply certain proceeding for no good reason), you might have to start rethinking a bit some of your ideas. There are lots of people systematically looking for impossible shortcuts; seriously thinking that there are generic, easy, always-working answers for complex problems; that top-quality knowledge, reliability, dependability might be easily and quickly achieved, even in something as wide and complex as programming. The reality is that all these people are extremely wrong and will only be provoking problems to themselves and others. The only way to have good skills in something as programming is time, dedication and certain basic background/personality. There is no alternative, no shortcut, no magical solution, no combination of words proving otherwise, no genius intuitively-understanding everything, no set of written-in-stone rules which will always work. On the other hand, there are lots of short-sighted people (some of them quite aggressive), lots of lies, people in denial, incompetence, unfair blaming, stupid decisions and some ignorance-prone trends which hopefully will gradually get extincted.
Custom Solvers 2.0 = Alvaro Carballo Garcia = varocarbas.
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 this day and age EXCEPT if it's generated by a script. The simplest of actions on a web page and developers can't get it right. If they can't get that right, why should we expect them to get anything else right?
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.
Here you have some ideas for those talking about SQL injection without knowing too well what all this is about. There are two basic requisites for this situation to ever occur:
1. Non-sanitised string SQL query (= sending a random string to the database without checking what is in there).
2. The potentiality of a malicious action to happen (e.g., building the SQL queries from random user inputs).
If any of the aforementioned points is missing, the probability of a SQL injection to ever occur is exactly zero. What means that you can ignore the first point and blindly send queries to a SQL database (not precisely recommendable) if, for example, all the strings are hardcoded or no external actions will ever affect any of them. Similarly, you might rely on random inputs, as far as you make sure that the resulting SQL query is fine; focusing on this second aspect is the most usual proceeding. Again, I am not recommending or promoting to rely on non-ideal proceedings, just sharing some basic, objective, fanatic-free information which some people (some of them with lots to say in programming-related aspects! Incredible, but true!) might find helpful. Long live to the little bobby tables! LOL.
Custom Solvers 2.0 = Alvaro Carballo Garcia = varocarbas.
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.
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?
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
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 untested code. Even with best intentions and good practices, bugs and thus exploits are inevitable. Especially when the focus is on making sure you're avoiding one specific class of problems like SQLi, meaning people tend to focus on check listing that instead of taking a broad, security in depth approach.
Inevitably after a few months it turns out they underestimated the complexity of writing a whole new system from scratch and sacrifices are made, leading to focus on speed and getting it done over security.
(Not really sure if this problem is about "Web developers"; it really seems to be a symptom of software development in general.)
In the market, useful websites beat secure websites.
So by natural selection, developers that ignore security multiply, while those that focus on security die out.
For the record and in case anyone is interested, I am not a web developer in the sense of mostly having web-based experience. I specialise in (custom & from-scratch) algorithm development, numerical/engineering/data analysis and efficiency improvement, where the exact language or framework (desktop, web or whatever) is quite irrelevant. Anecdotally, most of my experience is focused on desktop environments (Windows and Linux).
Custom Solvers 2.0 = Alvaro Carballo Garcia = varocarbas.
The main answer, at least in my own career, is this: Lack of formal architecture training. I'm self taught, as many web devs are. Now, I was considered a pretty good Web Dev, by Web Dev standards, but I noticed that the projects my team was working on ran into common problems. No matter what fancy programming methodologies and delivery tools we were using, we always reached a point where the solution ossified and became difficult to develop for. This meant that in projects with complex requirements we always overran. Also, while we could make the client happy on delivery, we struggled to *keep* them happy. We tried 'Agile', we tried 'Extreme', we tried a thousand different buzzwords, but nothing worked. As a Web Dev, when you see this happening, there are two ways you can go. You can: A: Accept this as a reality of the field, and carry on as before. You can then have a breakdown at thirty and never work again. B: Refuse to accept crappy software and look for a better way. If you're thoughtful, and not too vain to learn the lessons of the sages, you discover the Gang of Four, Design Patterns, etc, and achieve enlightenment. I went for B and finally, after ten-odd years as a professional, am finally writing good software that *stays* good.
I use this one course hosting platform called Thinkific and pay them $100/month.
I reported a bug 4 months ago that allowed people to purchase the wrong course when they had 2 check out windows open. It's still not fixed because it's not considered a priority. So a critical billing bug which results in customers buying the wrong course isn't considered important by their decision makers.
So while developers are making these mistakes I have a feeling a lot of times they don't get fixed because someone at the management level has an even worse understanding of what needs to be addressed.
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.
Yep...and there is hardly anything that details how to test for such vulnerabilities!
I think *all* code should go through at least peer review by a senior team member.
If there are more than one programmer at a company, yes. But when (say) a small toy retailer in the Midwest has the budget to hire only one programmer to build its order fulfillment back end, who would review his code? Fortunately, this company's programmer at least takes care to escape HTML, parameterize or whitelist anything going into an SQL query, and require all POSTs to include the session's CSRF token.
I do systems integration work, so I work with the output of developers rather than doing coding -- our group gets their creations working in the real world outside the dev's laptop. What I see driving this is a mix of super-complex frameworks and other abstractions layered on top of what was designed to be a very simple system. Because the development they do is so abstract, there's very little understanding of what's going on 4 levels below their code...a database query (probably not even a SQL query these days) gets passed with user input from client-side JavaScript code to whatever MVC framework is popular this month, and a data set is returned for the client code to parse and display. You don't have to know anything about how SQL or whatever NoSQL data source works, how HTTP works, how the TLS session that is hopefully securing your session is set up, or how the message gets from one system to another. I'm sure lots of people are going to say "dude, that's old school graybeard stuff...the frameworks do it all for us!" But, I'm of the opinion that at least some first-principles instruction is needed and most new developers are coming in at a level way higher than this.
A personal example from my world is that I've started working a lot with cloud computing, automating deployments and such. The cloud providers have done a very good job abstracting the insane amount of details that go into deploying a cloud resource, but the documentation is aimed squarely at web developers...it's all "insert properly formatted JSON file into our magic box and out pops what you asked for." This is good, but it gives zero insight into how things work, and new developers coming into the cloud-first mobile-first world won't get this education at all. Form my perspective, the only way I've been able to get my head around REST and all that stuff is to start from first principles and work up...not starting from the top of a framework call.
I think that this will be even more interesting to watch as more and more apps are written by non-Netflix, non-Facebook, non-Google developers as microservices. Suddenly one app is hundreds of tiny ones, each with potential vulnerabilities. The skill level has to go way up when you start working this way, because speed of release isn't going to help solve security problems developers don't know they have.
As a whole, software engineers are arrogant little snowflakes who think they're better than everyone around them or those who came before them.
So they just keep repeating mistakes over and over and over, rejecting advice straight up. So you can explain to someone doing something how you've seen it a million times before and it doesn't work...they'll still insist they know better. And when it blows up in their face, they'll say it was inevitable. (Obviously not always their fault: a lot of advices they get IS bullshit and they can't filter the good from the bad).
Why do companies keep making the same mistakes hiring recent college grads
Might they have been bribed to do so by universities seeking to improve their post-graduation employment percentages?
Companies have champagne taste and a beer budget.
For which they think the rational solution is to seek out equally tasty, equally intoxicating sparkling wines produced outside Champagne.
That's interesting. My impression was that since medical school slots were so tightly controlled and that the selection process ensures that entrants basically have a voracious memory, the quality of graduates was pretty uniform. Are there differences in quality?
I figured that was the reason doctors always seem to have all the answers...because the basic stuff is in a textbook they memorized during medical school and had it reinforced by seeing the same thing on the job. (I also figured the selection process selecting for super-academic types was why most doctors I've met have planet-sized egos.)
It doesn't matter: half of them still write injectable queries, even though using "prepared statements" isn't any more complex.
In the majority of cases, I agree that "using 'prepared statements' isn't any more complex." The biggest exception is operator IN, as none of the popular free database engines that I tested support an array as a parameter. Instead, they require each value in the list on the right side of operator IN to be its own parameter, and the application is responsible for building both the (variable-length) list of question mark placeholders and the array of values to be substituted into the equation. It also has to ensure that the order of the question mark placeholders, particularly those that occur before or after the use of operator IN, doesn't fall out of sync with the order of the elements in the array of values, or else the inadvertent use of values intended for operator IN for other parts of the statement or vice versa will end up itself causing a security hole. At some point, if the engine you're using doesn't support named placeholders, a well-tested routine to escape a single array of values for the right side of operator IN becomes safer than using question mark placeholders because of less risk of accidentally mismatching the order of placeholders with the order of values.
I think you have to honestly look at yourself and if you are not educating or failing these incompetents, you are a bad professor and a part of the problem.
If the administration gives a professor only one semester to cover what ought to be two semesters' worth of information security material, as gweihir described, is a professor who doesn't quit in protest "a bad professor and a part of the problem"?
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.
when you hire only the inexperienced, you get the same newbie mistakes over and over again. And with each new Web-years generation of greenhorns, their solution to every problem is moar scripting. That's why Slashdot now has virtually the only online commenting system that still works on mobile devices.
Putting an access filter into a school is the last thing you'd witness around here. Especially when it comes to universities.
Non-profit universities don't have unlimited bandwidth. Nor do they want to contribute to Internet access patterns that are more likely than not to disrupt instruction in the classroom. Toward this, many universities tend to block access to certain Internet resources from classrooms while allowing it from dormitories.
After all, playing the video locally requires downloading the data anyway
Both U.S. copyright law and the YouTube terms of use distinguish an ephemeral copy of a few seconds of a work at a time from a permanent copy of its entirety. And even in the case where the caching mechanism ends up keeping an ephemeral copy of (say) the entirety of a short film in order to reduce the latency of seeking, U.S. copyright law (17 USC 512(b)(2)(B)) distinguishes a copy under control of a user agent that respects Cache-Control from a copy under control of a program that does not.
Most devs are afflicated. It can be overcome.
OMG facts!
There are entire categories of problems that are only possible because of tooling that we just should not use. Just like buffer overflows can only happen because your library allows them, the same thing happens with SQL injection, and even cross site scripting.
if one of the stairs in your house has a missing step, we do not tra
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
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
It's to reduce the fraction of verification emails that bounce. Some email smarthosts penalize senders for excessive bounces.
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.
It's also to ensure that the user didn't inject command-line options or other security-compromising garbage into the address that the form's action code is about to feed to the MSA.
It's about as stupid as asking to "retype" your email address
You'd be surprised at how many non-technical users fat-finger their email addresses, causing the chosen username to be unavailable because the verification mail was never received.
Even if a defense to copyright infringement is successful, downloading a permanent copy of the video from YouTube's server without permission from YouTube is still a violation of YouTube's terms of use and therefore of the Computer Fraud and Abuse Act and foreign counterparts.
That is actually the biggest mistake I see in modern development. (referring to the linked xkcd cartoon)
Instead of having different DB users with rights to change the schema and rights to only query data, they have a single super user that nearly can do everything.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
The issue is "time to market". Management don't want a solution to a problem that takes weeks to get to market, in the agile world of software development, developers are given a day or two do determine what the problem really is (based off bad requirements), design a solution that meets the requirements, implement the solution, get it through testing, and then move onto the next feature.
Code review is left up to another developer (who is also dealing with the above) to review the diff, and approve or decline the update - usually if it builds, the reviewer will approve for they don't have time to sit down and properly determine what the problem is, and go through the solution in a sufficient level to discover all the issues this introduces.
Perhaps if developers were given the time to develop the solutions in a manner that is secure, and if developers "estimated" the work in a manner that would give them the time to develop secure solutions the software would be better, albeit late to market and over budget.
And yes, juniors who are fresh out of uni are thrown into established projects and are expected to be able to do the first paragraph above with little guidance (for all the other developers are over worked with the above two paragraphs)
it is only after a long journey that you know the strength of the horse.
Slashdot's failure to have correct defense against XSS mangled my post. The point is, if the script echoes the input, and the input contains JavaScript, it'll each the JavaScript - which will then run in the context of the victim site. That allows attackers to steal session cookies or whatever.
The general solution is to html encode the output, so if someone enters a character such as the less than sign (which starts a new tag), the script outputs & gt ; which causes the browser to DISPLAY the specified character, rather than treating it as the beginning of a script.
The #1 problem is lack of education. A large number of software developers have had no formal training in software development. Almost all who HAVE had formal education don't receive any education or training in how to develop SECURE software.
I teach a graduate course at George Mason University (GMU) on how to design and implement secure software. So there are people who are learning, but there are many more to go.
For the most part, countering the OWASP top 10 doesn't cost more, so cost has nothing to do with it. At the high end of security requirements it definitely costs more, but stuff like parameterized statements (countering SQL injection) and using web frameworks that automatically counter XSS injection don't cost any more.
- David A. Wheeler (see my Secure Programming HOWTO)
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
That is not a browser bug. Scripts can add elements, including images and other scripts, to a page, and those elements may be sourced from another origin. See jsonp, for example.
The bug is that the server-side script allows the attacker to add elements to the page by echoing the request variable directly, rather than HTML encoding it.
Instead of having different DB users with rights to change the schema and rights to only query data, they have a single super user that nearly can do everything.
Good point.
Custom Solvers 2.0 = Alvaro Carballo Garcia = varocarbas.
As far as you had some problems in the past to understand what a mechanical (industrial) engineer is, here you have what seems a clear enough example: Tony Stark/Ironman, in case of being real, making real things and having real knowledge would be a mechanical engineer; or, at least, would have an important mechanical engineering expertise.
I want also to clarify that my opinion about you hasn't changed much; I still don't quite understand why you are so interested in talking to me, mainly after some past incidents. On the other hand, I am a resentment-free guy always ready to update my impressions if required; I do expect everyone to take full responsibility for past actions though, more out of fairness than resentment. In case of thinking that your comments are reasonable, I might reply you and keep changing my opinion; otherwise, I will continue ignoring you as so far, something which I only do under extreme circumstances.
Custom Solvers 2.0 = Alvaro Carballo Garcia = varocarbas.
My devs persist in designing pages I have to scroll down to show the 'Submit' button. Pages that, in a browser with an address and bookmarks bar, force that key element below the bottom of the maximized window. Why? The white space is available, the other elements could be spaced differently, this is unnecessary.
When 8514/A and XGA came out, web developers jumped at the extra screen space. Most users still stuck at SVGA.
If you want to see usability, corporate devs, look at Amazon. There is a Submit or Order button handy always. Yes, you scroll to show 50 results, but you don't have to look hard for the action button. On my app, you always, always have to scroll.
And the pleas of the users fall on deaf ears. Moar Features. Moar whitespace. Moar corporate theming.
Feh. Web app design is a wasteland. Injection hardening is how they deny that people have apostrophes in their names, or speak any language other than English in your globalized app world. Injection hardening and input sanitizing was the big push in 2007. What happened since then? Laziness.
deleting the extra space after periods so i can stay relevant, yeah.
1) New developers coming up employ the latest whiz-bang buzzword frameworks etc. and blindly repeat the mistakes of the past.
2) Security takes a back seat to "getting it working" as always in IT.
Because they're the same people.
"Why Do Web Developers Keep Making The Same Mistakes?" is the wrong question entirely.
The ACTUAL question is, why do new developers insist on completely ignoring the lessons of the past? This is what happens when you mindlessly encourage a culture of "young people are better than old people" and "new stuff is better than old stuff".
It results in exactly what you see today: the same idiotic mistakes being made over and over again. Reinventing the wheel over and over again. None of the issues happening today are new. They've been solved for decades. But because the "solved" technology is "old", it's ignored.
It's depressing how software development is the ONLY professional industry where learning lessons from the past are actually frowned upon, and people who rediscover the same thing all over again are considered visionary.
FWIW, this is not my experience with Agile, although this is admittedly only at one company. The company taking this seriously and trying to do it right might have something to do with that.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
The problem is that the tools we use make it easier to do the wrong thing than to do the right thing. Take SQL injection, for example:
When I started using SQL (late 80s / early 90s), parameterized SQL was pretty much the only way to go. I did actually figure out how to execute an arbitrary string of SQL and capture the resulting columns, whose names and data types couldn't be known until runtime. But it was a royal pain, and I doubt most people would have been that persistent - if at all possible, they'd have stuck with the easy way, which involved using SQL parameters.
Fast-forward through a few decades of "advancement" in tools, and now it's trivial to execute a string of arbitrary SQL (just begging for SQL injection), and SQL parameters are this strange thing that people may have heard of, but they're hard to use and they seem like more trouble than they're worth. So far too many people just do it the easy (i.e. INSECURE) way!
and those elements may be sourced from another origin.
Hm, I always assumed that would be against the "same source policy" browsers are supposed to enforce.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
I read text ... and answer to text.
Not to the name of the sender.
No idea who Tony Stark/Ironman is ... and no idea why you switch to mechanical engineers.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
It does not violate the same-origin policy.
The same-origin policy is mostly about frames/iframes and cookies. It says that scripts from one origin my not read the contents from a different origin except:
Scripts from another origin (predates the policy)
Websockets
A script from a.com may not read a cookie or a reponse body from b.com
Scripts MAY create tags which will then load resources from another origin. So a script from a.com may create an img element that loads an image from b.com. As a special case, it may NOT load an image from b.com into an HTML canvas object, because that would allow it to read the contents.
Use Code Analyzers
Casteism
I read text ... and answer to text.
Excellent approach! I also tend to do same, but there are exceptions. Perhaps I made a mistake and your various interactions with me obeyed to pure randomness. Kind of weird, but possible why not? I cannot avoid remember most of nicks/signatures with which I have chatted here, but perhaps this isn't the case with everyone. Anyway, sorry if there was any misunderstanding.
No idea who Tony Stark/Ironman is ... and no idea why you switch to mechanical engineers.
This comes from a previous chat with you (with that account; perhaps I am wrong to assume that only one person uses it) where you didn't know what a mechanical engineer was. I thought that Ironman was part of the popular culture which most of people know, mainly in a site for nerds. Again, accept my apologies for any misunderstanding.
Custom Solvers 2.0 = Alvaro Carballo Garcia = varocarbas.
Erm, you are most certainly mixing me up.
I am a software engineer, so obviously I know what a mechanical engineer is. I'm german, we are most famous for our mechanical engineering studies in our universities.
But when you said Ironman, I dod not think about that movie. As I did not read the those Marvel comics when I was a kid, the movies don't really interest me. Unless I stumble over one by accident on youtube, I never watch stuff like that.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Erm, you are most certainly mixing me up.
I think that I am not, but It isn't too important. It was a quite aggressive argument about physics (which I am not particularly interested in searching) where misinterpreting other's position was quite easy. Anyway, sorry for going so much off-topic and again good point about databases.
Custom Solvers 2.0 = Alvaro Carballo Garcia = varocarbas.
For decades I have been aware that companies keep hiring new developers fresh out of college that work hard, are productive in the lines of code they write, maybe meet deadlines, and keep making mistakes experienced workers gave up on decades ago. This year's budget doesn't care about expenses several years from now.
It's partly because that's good design and partly because of historical reasons. Specifically, the script tag existed prior to the same-origin policy, and it was common to load scripts for other sources. This probably wouldn't be allowed if same-origin were designed in from the beginning. It allows jsonp, which contravenes the spirit of same-origin.