Ask HN: Why do you think vulnerable code is still being released today?
13 comments
If you want reasons other than negligence.
The biggest reason is likely universities: I was there not too long ago (6-7 years), I wrote code that was secure against SQL injection - which lost me marks. They teach you to write insecure code and so help you God if you don't stick to what they have taught you.
Secondly is human error - that's to do with buffer overflows etc. You might say that we have static analysis, but...
Thirdly is that our static analysis tools simply are not "there" yet. They will catch the vast majority of vulnerabilities (especially when coupled together with contracts) but there are those corner cases that only a very creative security analyst will find.
Honestly though, if I was ever in a fire/hire position bringing SQL-injectable-code to a code review would be grounds for being fired on the spot.
The biggest reason is likely universities: I was there not too long ago (6-7 years), I wrote code that was secure against SQL injection - which lost me marks. They teach you to write insecure code and so help you God if you don't stick to what they have taught you.
Secondly is human error - that's to do with buffer overflows etc. You might say that we have static analysis, but...
Thirdly is that our static analysis tools simply are not "there" yet. They will catch the vast majority of vulnerabilities (especially when coupled together with contracts) but there are those corner cases that only a very creative security analyst will find.
Honestly though, if I was ever in a fire/hire position bringing SQL-injectable-code to a code review would be grounds for being fired on the spot.
I think you over-estimate the impact of universities. Many (perhaps most?) CS professors think of themselves as Applied Mathematicians. It's unrealistic to expect your linear algebra teacher to worry about style.
Negligence is the first. Sometimes it's even willful. "Get this out in 3 weeks under budget, I don't care how." That leads to human error, which is more likely when you have underqualified people working on unrealistic deadlines.
Negligence is the first. Sometimes it's even willful. "Get this out in 3 weeks under budget, I don't care how." That leads to human error, which is more likely when you have underqualified people working on unrealistic deadlines.
I don't think that is an over estimation of the impact of universities. First, are the majority of university educated programmers really learning from CS professors? I'd venture that more programming is taught outside of the CS programs these days. Second, as someone finishing a degree in information security and having worked in IT for 14 years and IT security for 4 years, universities are not doing a great job in teaching applicable security. It is a rapidly evolving space and course materials just aren't keeping up.
I think we're saying the same thing. Universities aren't teaching security, so folks learn it elsewhere. Most people hiring new grads know this.
> I think you over-estimate the impact of universities.
I may, I have a bit of a vendetta for them.
> Negligence is the first.
Arguably, yes. Most of the comments when I posted mine indicated that negligence was the cause -- I was aiming to find the other ones. Still I somehow fail to understand how even pressure results in SQL injections -- nearly all languages I have worked with have a productivity reward/time saving for using parameterized SQL.
I may, I have a bit of a vendetta for them.
> Negligence is the first.
Arguably, yes. Most of the comments when I posted mine indicated that negligence was the cause -- I was aiming to find the other ones. Still I somehow fail to understand how even pressure results in SQL injections -- nearly all languages I have worked with have a productivity reward/time saving for using parameterized SQL.
On point one - perhaps my expectations are lower. I think a CS degree signals a level of rigor that is absent in other degrees, but I don't pretend that the practicality is so high that people can be instantly useful. I assume that it takes 3 months of general training, and several more of "Here's how we do it here" before you can expect much. (As opposed to a Math major who would require programming training on top of it, or a History major who might be lost outright)
>>>Honestly though, if I was ever in a fire/hire position bringing SQL-injectable-code to a code review would be grounds for being fired on the spot.
Code reviews should be about ensuring the integrity of the code base AND helping your developers write better code. If you fire someone on any teachable moment, your employees will never get any better. Mistakes should not equal firings for a first offence, that's a dead giveaway of a terrible manager. Making the same mistake twice is the inexcusable part.
There's an old story that's relevant here (I may get the specifics wrong): In the early days of Intel, before they were a behemoth, an engineer made a mistake that cost the company $50,000 (a huge sum at the time). The engineer was sure he was a goner, and many people were calling for this head. Gordon Moore (founder) was asked when he would be fired.
Moore replied "Why would I fire him? I just spent $50,000 training the man!"
Code reviews should be about ensuring the integrity of the code base AND helping your developers write better code. If you fire someone on any teachable moment, your employees will never get any better. Mistakes should not equal firings for a first offence, that's a dead giveaway of a terrible manager. Making the same mistake twice is the inexcusable part.
There's an old story that's relevant here (I may get the specifics wrong): In the early days of Intel, before they were a behemoth, an engineer made a mistake that cost the company $50,000 (a huge sum at the time). The engineer was sure he was a goner, and many people were calling for this head. Gordon Moore (founder) was asked when he would be fired.
Moore replied "Why would I fire him? I just spent $50,000 training the man!"
First off, there is a never-ending tension between security and convenience. gnupg has been around forever, but any effort to get your non-computer-programming friends to use it will come up against a pretty terminal useability wall. Setting autocomplete to off on a forms login will get complaints from almost everybody. (And then MS in IE11 now ignores that setting in the password field. Bah.)
Similarly, when building applications, the goal is to make an operation more convenient or possible than it was before. And speed of deployment is an imperative as well.
The main challenge in most of today's applications is that they are highly complex and they involve browsers. Browsers are extraordinarily complex programs working to a set of conflicting, evolving standards. For illustration, I suggest reading The Tangled Web by Zalewski. (But read it early in the day--reading late at night might lead to nervous or disturbed sleep.) Or his blog post "Postcards from the post-XSS world": http://lcamtuf.coredump.cx/postxss/. Did you notice that both Chrome and IE had recently-identified remote-code execution vulnerabilities that affected all known versions?
Beyond that, applications and frameworks these days are very complex and are under that feature/security tension. There are some nice-to-have features that themselves increase the attack surface. Complex programs are hard to get right. Remember the quote from Tony Hoare: "There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult."
And what you say is true about developers not having enough knowledge to write secure code. Without consulting Tangled Web, how many of us knew that the format of a fully-qualified absolute URL is of the following form:
And the advice about always using prepared statements in SQL queries breaks down if user input is needed to influence column names or table names or even database names. One of the factors pushing SQLi to #1 is that it has massive risk. One tiny error off in one tiny corner of a little-used feature of the application can lead to exfiltration of the entire database.
When Structured Programming was first talked about, a few of us real-time programmers began to think that it would be a nice idea to prove programs correct. This proved to be way to expensive. So we resigned ourselves to writing programs that we thought might be proveable.
The care/knowledge factor you mention is important at all levels of an organization. So if the founder or CEO or CTO or marketing is not buying into a security mindset, it can be tough.
(Disclaimer: I help software companies with this sort of technical/cultural problem.)
Similarly, when building applications, the goal is to make an operation more convenient or possible than it was before. And speed of deployment is an imperative as well.
The main challenge in most of today's applications is that they are highly complex and they involve browsers. Browsers are extraordinarily complex programs working to a set of conflicting, evolving standards. For illustration, I suggest reading The Tangled Web by Zalewski. (But read it early in the day--reading late at night might lead to nervous or disturbed sleep.) Or his blog post "Postcards from the post-XSS world": http://lcamtuf.coredump.cx/postxss/. Did you notice that both Chrome and IE had recently-identified remote-code execution vulnerabilities that affected all known versions?
Beyond that, applications and frameworks these days are very complex and are under that feature/security tension. There are some nice-to-have features that themselves increase the attack surface. Complex programs are hard to get right. Remember the quote from Tony Hoare: "There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult."
And what you say is true about developers not having enough knowledge to write secure code. Without consulting Tangled Web, how many of us knew that the format of a fully-qualified absolute URL is of the following form:
scheme://login.password@address:port/path/to/resource?query_string#fragment
And the advice about always using prepared statements in SQL queries breaks down if user input is needed to influence column names or table names or even database names. One of the factors pushing SQLi to #1 is that it has massive risk. One tiny error off in one tiny corner of a little-used feature of the application can lead to exfiltration of the entire database.
When Structured Programming was first talked about, a few of us real-time programmers began to think that it would be a nice idea to prove programs correct. This proved to be way to expensive. So we resigned ourselves to writing programs that we thought might be proveable.
The care/knowledge factor you mention is important at all levels of an organization. So if the founder or CEO or CTO or marketing is not buying into a security mindset, it can be tough.
(Disclaimer: I help software companies with this sort of technical/cultural problem.)
As a PHP developer, I've definitely seen a massive decrease in the number of people who are just passing queried values directly into the construction of their SQL string as people have started emphasizing using prepared statements.
But this has done nothing towards stopping people from passing column/table selections directly into those strings. It seems as though everyone is using prepared statements now because they were told to not because of any kind of understanding of why.
But this has done nothing towards stopping people from passing column/table selections directly into those strings. It seems as though everyone is using prepared statements now because they were told to not because of any kind of understanding of why.
As a consultant, I've seen a fair share of people building their own "ultra-secure" authentication, authorization, and encryption algorithms. One project simply took plain-text passwords, Base64-encoded them, reversed the result, and called the passwords "encrypted". Plenty of others would execute raw SQL without validating user input. This is an education problem.
Last winter we saw Ruby on Rails vulnerabilities that likely came about because the focus of the Rails framework has not traditionally been security. Rails is "optimized for programmer happiness". I'm cool with that, just know what you're getting in to when you choose to adopt a new framework (stay up to date with security patches and otherwise secure and monitor your web servers as best as you can). Any new framework that becomes widely adopted will likely go through the same type of problems.
With all of that said, I learned nothing about code security until I had to. University did not really touch on it, so most of my education on security came later in a workplace setting when I desperately needed it.
Last winter we saw Ruby on Rails vulnerabilities that likely came about because the focus of the Rails framework has not traditionally been security. Rails is "optimized for programmer happiness". I'm cool with that, just know what you're getting in to when you choose to adopt a new framework (stay up to date with security patches and otherwise secure and monitor your web servers as best as you can). Any new framework that becomes widely adopted will likely go through the same type of problems.
With all of that said, I learned nothing about code security until I had to. University did not really touch on it, so most of my education on security came later in a workplace setting when I desperately needed it.
The first and obvious reason would be that developers and companies alike simply don't have the skills/mindset or don't care, must rush to release code, etc. It becomes an afterthought (usually after something bad happens).
I would say the second reason is very similar but applies to frameworks. Developers usually choose a framework and think they are done. This is something quite difficult to fight. So if frameworks would be more careful with security by default, the net result throughout the industry would be greater than the uphill battle of educating developers on security.
Microsoft has an internal term for something like this that they apply to Visual Studio (I forget the specific term) but it's something like ensuring the common path to do something automatically ensure best practices will be followed. That by using VS, you would have to go out of your way to do something outside those best practices. I think this works for the general population of developers.
I would say the second reason is very similar but applies to frameworks. Developers usually choose a framework and think they are done. This is something quite difficult to fight. So if frameworks would be more careful with security by default, the net result throughout the industry would be greater than the uphill battle of educating developers on security.
Microsoft has an internal term for something like this that they apply to Visual Studio (I forget the specific term) but it's something like ensuring the common path to do something automatically ensure best practices will be followed. That by using VS, you would have to go out of your way to do something outside those best practices. I think this works for the general population of developers.
Because it's easier to write vulnerable code than nonvulnerable code.
If you call the function that should be used on all input that you glue to SQL mysql_escape_string() then you shouldn't wonder why people are not using it.
If I were to design web language then there would be sql string type and literal and all the db functions would take only parametrs of this type. You wouldn't be able to glue strings or anything else to that type without autoconvertion that does the escaping and the only way that you could convert plain string to this type witout escaping would be via function called i_am_stupid_and_i_want_my_server_hacked and it would be buried deep in my package hierarchy if I had one.
Same goes for HTML, JavaScript and maybe even CSS. Separate string type and string literal and same interface between these types and all others.
If you call the function that should be used on all input that you glue to SQL mysql_escape_string() then you shouldn't wonder why people are not using it.
If I were to design web language then there would be sql string type and literal and all the db functions would take only parametrs of this type. You wouldn't be able to glue strings or anything else to that type without autoconvertion that does the escaping and the only way that you could convert plain string to this type witout escaping would be via function called i_am_stupid_and_i_want_my_server_hacked and it would be buried deep in my package hierarchy if I had one.
Same goes for HTML, JavaScript and maybe even CSS. Separate string type and string literal and same interface between these types and all others.
Some thoughts. In my experience, the lack of vulnerable code in a secure application is not the product of savvy developers who never make mistakes. A hardened web app usually gets that way because someone took the time to find and fix some of the exploitable vulnerabilities that could be found. Unfortunately, that usually doesn't happen until they get hacked pretty hard and come to see the business value of investing in the people, process, and tools required to create a robust security program which is augmented by quarterly $10,000 PenTests.
It's like asking "Why doesn't everyone know calculus in this day and age? It was discovered hundreds of years ago." Sometimes people are ignorant, lazy, under a time crunch, etc. When information became widely available(That SQL injection is bad and easy to fix) has little to do with how 5 random dudes working on a team write their code.
Security is really hard, you need everything perfect all the time. It's easy over look something, or just say "eh, no one will ever find it". It's hard to make sure a million or even 1,000 lines of code are 100% safe. Writing totally secure code takes much longer, much more skill.
No one can (or should) write totally secure code. But there are a lot of simple mistakes leading to XSS and SQLi that can easily be avoided by having some standards.
I think especially beginners who learn from snippets and various sites often use code that is simply outdated and/or bad. They don't know any better so they use what works.
Time constraints. As soon as management say this needs to be done by `X` then things go south.
Well, that's approximately my experience too. "Meh, just ship it."
A good thing though is the programming methodology is shifting its stance. As framework-based programming becomes mainstream, which it almost has, for any half-decent setup- the programmer will create loop-holes because of his _stupidity_ and not because of his inexperience in the programming environment.
As fixes come to the base of the infrastructure, the benefits would evaporate throughout the stack on top of it. Ideally, a developer should focus on features, priorities and deadlines. It sure as hell may be geeky, but it is not cool to force-everyone to-know-everything.
As fixes come to the base of the infrastructure, the benefits would evaporate throughout the stack on top of it. Ideally, a developer should focus on features, priorities and deadlines. It sure as hell may be geeky, but it is not cool to force-everyone to-know-everything.
Why is SQL Injection still #1 (in Owasp T10) ?
As a developer myself working for a top-10 us e-retailer I saw: - Developers not having any(or enough) care/knowledge to write secure code. - Tight deadlines where security of an application was swept under the rug. - Security being swept under the rug due to time, other "priorities" like new features, etc.
Curious on your thoughts or experiences?