

SQL Injection [video] - secnews
http://informationsecurity.451research.com/?p=4986

======
thinkbohemian
I teach at University of Texas and introduced students to SQL injection
(<http://www.youtube.com/watch?v=s4QxOxGL1tI>) but the production value on
this video is way better. Thanks for posting this, I've bookmarked for my
course.

------
david_shaw
Nice introduction to SQL injection :)

I like to explain to clients that software security flaws form out of what I
call "developer tunnel vision." Developer tunnel vision occurs when a
programmer fails to predict the types of input that an attacker could enter
into a running application that would cause problems.

It's these untested edge cases, not _necessarily_ an unknowledgable developer,
that allow so many security problems to occur.

This seems especially true when developers are rushed to ship products, rather
than taking the time to properly test them. I'm not saying that the philosophy
of "build often, ship often" is _wrong_ , per se, but it is absolutely a major
cause of security issues.

This issue is compounded when developers are, in fact, not knowledgable about
security issues. Up until very recently, university-level courses and
textbooks taught students to write code with security problems in the examples
themselves. Many courses and textbooks still do. This is true for SQL
injection, buffer overflows, and many more classes of vulnerabilities.

The problem is compounded when developers and sysadmins rely on over-hyped
security tools instead of secure code. Don't get me wrong--a well maintained
WAF or updated and monitored IPS can absolutely add incredible protection to
an organization's defense--but it doesn't solve the problem of insecure code.

I know that most developers in the startup scene are eager to deploy their
MVPs and ship immediately. I'm okay with that, and not only do I encourage it,
but I've been there myself. Let me throw out a word of caution, though: if
you're going to create a product and get some early adoptors, _don't_ lose
their data. Do some preliminary security testing. It doesn't need to mean "go
out and hire a security firm to test your application," since that can often
be expensive. Take an hour or so before launching, though, and test for common
problems like SQL injection, cross-site scripting and cross-site request
forgery. Check out the OWASP wiki. Throw a single-quote into your login fields
and see if things start to break. Trust me, it's better to delay launch for an
hour than to have easily-fixed security problems that expose your application
to the TechCrunch crowd because your database got stolen and put on Pastebin.
Even better, try to adopt security best practices into your software
development lifecycle, even if that "lifecycle" currently consists of "post up
at Startup Weekend and work until it's ready."

You don't need to spend all your time and money on security, but when your
reputation is everything, it is generally a worthy investment.

