Fellow hackers,
I'm curious as to why you think vulnerable code in applications is still being released today?<p>Why is SQL Injection still #1 (in Owasp T10) ?<p>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.<p>Curious on your thoughts or experiences?
If you want reasons other than negligence.<p>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.<p>Secondly is human error - that's to do with buffer overflows etc. You might say that we have static analysis, but...<p>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.<p><i>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>
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.)<p>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.<p>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 <i>The Tangled Web</i> 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": <a href="http://lcamtuf.coredump.cx/postxss/" rel="nofollow">http://lcamtuf.coredump.cx/postxss/</a>. Did you notice that both Chrome and IE had recently-identified remote-code execution vulnerabilities that affected all known versions?<p>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."<p>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:<p><pre><code> scheme://login.password@address:port/path/to/resource?query_string#fragment
</code></pre>
Did you know that the login.password@address:port section ended with a semicolon is accepted by some browsers? And that the query_string format is not specified at all?<p>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.<p>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.<p>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.<p>(Disclaimer: I help software companies with this sort of technical/cultural problem.)
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.<p>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.<p>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).<p>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.<p>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.<p>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.<p>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.<p>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.
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.
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.<p>As fixes come to the base of the infrastructure, the benefits would evaporate throughout the stack on top of it. Ideally, a developer <i>should</i> focus on features, priorities and deadlines. It sure as hell may be geeky, but it is not cool to force-everyone to-know-everything.