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.
So what we have here is that there's always another webmonkey to make the same old mistakes.
And still no Shakespeare.
On another note, I have some dead hpe kit here that they've made pretty much impossible to get RMAed. Can't even simply email them, have to use a spam-causing "webform", or maybe call a number and get some incredibly rude idiot like I got last time, instead of fixing the problem calling me back to have a good little shoutfest. And where I am, it's now a 0900. If they'd like to start with themselves, they could be less head-up-arse about honoring that old time procurve promise, instead of rescinding it. Or, like here, musing about webmonkeys when their business is networking kit, not webmonkeying.
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.
OR mappers help against Sql-Injection. But set-up cost of such a mapper is too high, for no apparent reason.
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.
âoeDonâ(TM)t reinvent the wheelâ i was told once. Not many people check whether the wheel is in good condition, because... you know, productivity and that.
The problem is non-interactive authentication (or anonymous, if you like) of the web portal where privilege is required.
Why is it anonymous?
When you register a login on slashdot, you need (somehow) to get write access to a database.
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."
The problem is that there are new suckers born every minute.
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.
I just inherited an application written by a group of senior developers (not young people claiming to be senior either) it was littered with string concatenations to build SQL queries, a heap of roll your own validation and zero unit tests. It was supposedly security reviewed and penitration tested but I doubt either of these were performed to a competent level as I cursory review finds all the usual issues and lazy work (catching top level exceptions 95% of the time).
The sad thing had been to fix these issues had greatly reduced the amount of code. And simplified it dramatically. While many of the issues can be blamed on developers, management needs to shoulder some, budgets must be set to include the appropriate testing (and re testing) and not just to cover features.
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.
They are stupid. People who work with computers are stupid, in general. There are very few exceptions. They lack social skills, real-world problem-solving skills, they are lacking in each and every field that makes a human being whole. Their jobs can be outsourced and now even automated with no loss whatsoever, but they cannot see it because of an unjustified perception of self-importance that, when nullified by reality, causes them to go into embarassing and ineffective fits of rage. And that pretty much sums it up.
"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"?
In my experience, Agile methodologies have a lot to do with this issue, and not necessarilay because of the methodology per se.
Everywhere I have been, rightly or wrongly, Agile has fostered a mentality of 'when the code works. the job is finished'. That then fosters a dev attitude of 'get it working, tidy the code up after it's working'. This almost always never happens! The reason? Because if the business abuses Agile to change their minds too often, the dev gets bored of changing their code god only knows how much, and bingo...... give up trying....
I am not that familiar with developing software. But it does appear to be a pattern of attack for hackers. This is popular software that is very complex, has potential for exploitation, and by its very design has access to areas of the OS and PC that can be accessed through that software. Sort of like a robber finding a open window, the robber wouldn't enter through a locked door. People who develop software generally don't spend a lot of time trying to find compromises or exploits. This is why even Google and Microsoft offer up rewards for others to do their dirty work so to speak.
I wonder if the problem is that it's the wrong message.
So much of the training and literature focuses on how an attack is performed rather than how to defend against an attack.
Perhaps security people could consider preaching about the Monster Mitigations http://cwe.mitre.org/top25/mitigations.html instead of the OWASP top ten.
You want to impress the boss? Get "working" code out the door. You want to get marked as a time-waster? Test everything properly and implement all appropriate security measures.
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 listened, and audit their code use tools available etc. Clients don't they want you to reuse vulnerable code, to cut costs etc. I stopped working on anything, where I don't have full control. It's my name on the line. I won't be rushed.
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 can you do?
The same thing that Linux has needed for a long time: Stop focusing on the Next Big Thing.
Many Linux services are half-done; with inconsistent menus or interface controls, missing documentation, out-of-date sample files, then after 5 years, the leaders decide to use a different tool. It's why Linux has a mediocre UI and exhausting UX: Their philosophy is, usable is good enough. Linux is designed for servers, so it has more stability and security is a lot tighter than a certain sales-driven OS but, as several developers have complained, there's no effort to make it desirable or consistent.
Businesses also suffer from the problem that they can't copy code: Part of it is copyright and IP, and part is needing custom software to fit their custom work processes. That custom bit is why software programmers exist today: Precise mathematical models aren't enough and piling black-box (framework) upon black-box destroys security, stability and consistency. It's re-inventing the wheel, every decade.
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.'"
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.
But, but, but, that costs money!
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.
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.
Regression suite & secured frameworks?
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.
Almost everyone, including developers:
-Uses online banking
-Files taxes onlne
-Pays bills online
-Receives paychecks online (To be fair, this is sometimes demanded by employers.)
-Uses online medical records
-Links multiple accounts to their bank account
-Divulges personal information on social media
-Keeps their photos in the cloud
Then they are surprised when their identity is stolen.
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).
It isn't just limited to web developers. Primary Care Physicians make the equivalent of "sql injection" mistakes all the time. That is, they screw up things that they would have been taught year 1 day 1 of medical school. We have to ask the question, how is it these people are still able to get degrees that say they know what they are doing, when clearly they do not?
Also, since you just get a degree after a few years and are shoved out the door, people who make these mistakes after leaving school, go on to have 40-year long careers where they keep screwing up and making the same mistakes over and over again.
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.
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.
Tepples, It was a pleasure shooting you down 5:1 https://meta.slashdot.org/comments.pl?sid=11284751&cid=55453197/
* LOL!
(Don't EVER "try me" again or it'll be MORE of the same...)
APK
P.S.=> Not even a "nice try" - especially considering you ask people to SPEND "$" on Pi + DGA domain registrations & HOSTS = FREE & NATIVE - not "illogic logic" of "Bolting on 'MoAr'" but working w/ what you have already that costs nothing!
All that empty 'talk' only to lose (see link above) on YOUR end, lol!
Plus, YOU HAVE NEVER BUILT ANYTHING LIKE I HAVE YOURSELF either, lmao - pretty pitiful - all talk/no substance of your own... apk
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.
You are off-topic. Your post appears as a non-sequitur. When another user engages you in discussion, please confine your replies to the posts to which you are replying, not the same user's posts to other unrelated discussions. What next, are you going to dig up his usernames on SoylentNews, Reddit, and elsewhere and reply to him there?
See subject: Tepples I simply SHOOT YOU DOWN & BLOW YOU AWAY, easily 7:1 -> https://meta.slashdot.org/comments.pl?sid=11284751&cid=55453197
* I truly do NOT recommend you ever try it again, or you'll what happened in the link above, PUBLICLY TO YOUR DISMAY (obviously, look @ your unidentifiable ac reply to attempt to "defend yourself" & failing) is a SWEDISH MASSAGE...
APK
P.S.=> You posting UNIDENTIFIABLY anonymously isn't fooling anyone but yourself either... apk
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.
Of course there are good reasons why these mistakes should be possible. Seriously, do you even know what you are talking about?
We need systems that can do things. And that can interoperate. That's where *all* the power is, and where *all* the end-user needs are.
For example, we need to be able to search a database for data that matches criteria selected by the user. DUH! It is *impossible* to provide a set of tools with which a developer can build a system that can do that, and eliminate any possible risk of sql injection. Injection is what you are doing.
Don't misunderstand me here: The developers absolutely CAN block SQL injection. If they build it right, there is no risk. But the moment you give them tools that don't let them build it wrong you give them worthless tools that they cannot use to meet novel business needs.
That's my point. You can't fix it at the toolset level without breaking the toolset. It is impossible, because that which makes the toolset versatile enough to be useful is precisely that which makes it essentially vulnerable.
Anyone with actual experience, and no-bullshit know-how, in the domain of software security, can tell you this.
"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
For the same reason that you get your grammer and punctuation incorrect. Education. Or as a director of the U.S. Postal service once told wrote on the whiteboard, "Edutation".
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.
The web is a hack, and so it takes a serious effort to write code securely. It's much much more difficult than writing code in that famously insecure language, C. I used to write web apps, they were awesome. But that was last century for the most part, because after the bubble popped web dev was devalued and outsourced. So devs like me went back to C++ and C, doing things like embedded Linux, because it seemed like everyone wanted to hire fools to do Java (nothing wrong with Java, but they hired fools to code it all the time!). So not the same devs, and the good ones have moved on, leaving all the millenials to reinvent all the mistakes, because, well, the Web is a giant hack. (XSS is the best example of this, a security flaw by design that the designers didn't even realize they were creating, and now it's just there, to be dealt with constantly. Woo Hoo. The web is a hack.)
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.
What's a good book on coding secure websites?
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)
Get over yourself dickhead. And stop posting all this shit about your ego here.
It's inconsistent technologies, with inconsistent APIs thrown together like Jackson Pollack took a shit on a wall with chicken wire and bubblegum using half-assed industry standards waiting around for W3C standards to commit for 10-20 year windows.
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
The reality is simple, but painful. The IT field is full of mindless copy&pasters and people who over rely on frameworks which they do no really understand.
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.
Neither the time to do testing or the money to buy tools exists in management's mind.
Same as always.
See here, APK: https://en.wikipedia.org/wiki/Grandiosity
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.
Shouldn't take shots at apk Tepples. It got you knocked out.
Speak for yourself Tepples. You don't run slashdot and I don't think apk's taking your orders. He laughs at you instead.
Use a 'proper' web development environment... then these things would be less of an issue:
https://www.webtoolkit.eu/wt
... use MongoDB. It's web scale.
https://www.youtube.com/watch?v=b2F-DItXtZs
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.
I want to say that often this is true.
Some developers actually learn and become better at their job, including the security aspects.
However I've met plenty of devs who simply never got better. At anything. There are far too many deadweight devs who were never qualified, never had the skills, never even had the inherent attitudes and reflexes required to become any good. They don't read, they rarely watch videos, they hardly ever go on courses, not unless they are required and paid for by their employer. These people are a curse to any organization that hires them.
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 don't know that I agree with the argument here... IMHO OWASP largely exists to drive sales to security products and consultancies. It's also 2017... plenty of high-profile libraries and frameworks actively militate *against* vulns OWASP lists.
But that aside, the insecure code I've written as an Enterprise Shitware Developer usually follows this pattern:
"We need these features"
"That'll take 6 to 8 months to do given current resources."
"We need them in 4 weeks."
"What happens if they're not done then?"
"The project gets cut. Oh, and it needs to do Z."
"Are you sure it needs to do Z? That's not only deprecated and bad practice, it's tremendously vulnerable."
"Yes. And that part needs to be done next week. Also, we have 3 hours of meetings booked daily for the next month."
Under circumstances like that, green developers just write terrible code, though honestly they probably don't know any better. Senior developers take massive shortcuts, i.e., write terrible code, and lie to themselves about how they'll fix it later. In a lot of environments, you can't push back against a timeline or constraints without it being either a career-limiting move.
Additionally... in a lot of companies, the software might be vulnerable but the entire business process is questionable. For every SQL injection there's a dozen unencrypted files in emails full of PII and credit card information.
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
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.