
Ask HN: Why do you think vulnerable code is still being released today? - jpd750
Fellow hackers,
I&#x27;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&#x2F;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 &quot;priorities&quot; like new features, etc.<p>Curious on your thoughts or experiences?
======
zamalek
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._

~~~
mathattack
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.

~~~
twstdroot
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.

~~~
mathattack
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.

------
wglb
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/](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
    

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?

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

~~~
bowlich
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.

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

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

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

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

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

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

~~~
twstdroot
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.

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

------
mattwritescode
Time constraints. As soon as management say this needs to be done by `X` then
things go south.

------
Piskvorrr
Well, that's approximately my experience too. "Meh, just ship it."

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

