Today I’ll be giving a talk on SQL injection at SecureWorld Expo (Philadelphia). My presentation is attached for attendees (and other interested parties) to reference.
Category Archives: Security
SQL Injection Talk at (ISC)2 Security Congress
In September, I was a featured speaker at the (ISC)2 Security Congress, where I gave a talk on SQL Injection. A few attendees and others have asked me to make the video and slides available for download – consider it done.
The Mistake Zappos Made After the Hack
After being hacked and apparently exposing customer password data in some form, Zappos has made it impossible for you to tell what password you had used on their site.
Zappos just made a big mistake – their site was hacked, and information about 24 million customer accounts was stolen, including password hashes (http://www.eweek.com/c/a/Security/Zappos-Latest-Company-Hit-by-Data-Breach-581979/). In response, Zappo has asked that its customers create new passwords for the site (http://www.zappos.com/passwordchange).
Part of the above-linked request reads as follows: “We also recommend that you change your password on any other web site where you use the same or a similar password.”
This implies that you should be able to tell somehow what your password with Zappos was. However, it looks as though any attempt to log in with a recognized account (email address) generates the same message, regardless of what password you use:
Try it yourself – if you pick a likely-to-be-taken firstname.lastname@gmail.com address (I used the surname “Miller” in the attempt above), you’ll get the message, regardless of what password you use. This shows that you can’t figure out what your Zappos password used to be, and so unless you remember it, you won’t be able to change it on other sites that use the same one.
What would have been better? It would have been better to force users through the password reset process using their registered email, but after allowing some way for them to verify that they had authenticated correctly with the formerly valid credentials.
How Systems Get Exploited – Content Becomes Structure
Don’t let content become structure.
There are many different ways in which an information system can be exploited, to include buffer overflows, SQL injection, cross-site scripting, etc. However, the vast majority of common exploits can be avoided by adherence to a single principle:
Don’t let content become structure.
In the categories of exploits listed above, maliciously crafted content breaks out of its proper role and becomes structure (instructions) that the system follows . If you can ensure that the values your system manipulates never become instructions for the system to execute, then you’ll probably be okay in terms of exploits in the products you build yourself. (Password management and platform hardening are different stories.) The ways in which you keep content from becoming structure are technology-specific (sanitizing form inputs, using JDBC parameters, etc), but the underlying principle applies to most of the security holes you’re likely to create / avoid.