"Sorry, that password is already in use"

Here is a good example of the kind of insecure practices application developers are doing out there.

http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/2012-October/008535.html

Thank you Jim Burton for being concerned and speaking out.  I have to admit laughing out loud when first reading this.  That may have been wrong of me.

Time to Update Your LinkedIn Password

Change your LinkedIn password!  Also change it on any site where you use that same password.  In case you missed it, about 6.5 million LinkedIn passwords were leaked today.  The passwords were in the form of unsalted SHA-1 hashes.  This leads you to believe that LinkedIn was not following secure best practices in terms of storage of user passwords.  A blog post from LinkedIn indicates that hashing and salting of user passwords was "recently put in place".  I wonder how recently?  Probably today.

If you are curious about whether your password was compromised, head over to LeakedIn.org, a site just launched by PHP security guru Chris Shiflett. (Side note: Chris authors a very informative blog and I've learned a lot about AppSec from his posts over the years.)  Once there, enter your LinkedIn password.  Client-side JavaScript code will produce the corresponding SHA-1 hash, then send the hash value to the server.  You will soon find out if your password was part of the 6.5 million that were leaked and whether or not the hash was cracked.  If you don't feel comfortable entering your password, just run HashCalc locally to calculate the SHA-1 hash of your password and enter the hash value instead.  I did this check today and my password was indeed among those that were leaked, but it hadn't been cracked yet.

Needless to say, I've changed my LinkedIn password.  It's a perfect example of why you should be using different passwords for every site you use.

AppSec Shouldn't Be Something Special You Do

To really improve the security posture of applications, development shops must get to a place where security is simply part of their normal development process.  In other words, designing secure software and writing hack-proof code shouldn't be a special side project or considered for the first time during the testing phase.

 
Making application security an inherent part of your SDLC can be done on a gradual basis.  You could start with instructor-led training of developers to teach them appsec concepts.  I did this type of training for several years.  A more scalable way to teach developers is computer based training (CBT), also known as eLearning.  This may be your only option with hundreds or thousands of developers on staff and limited budget.

Another key piece to building security into your SDLC is regular static and dynamic testing of applications. The goal is to find vulnerabilities and fix them before going live.  Static analysis looks at an application from the inside out.  You may also hear this referred to as white-box testing or static application security testing (SAST).  Static analysis can be done for any type of application (web, thick client, mobile, glue code, etc).  Dynamic testing involves looking at a web application from the outside in and is also known as black-box testing or dynamic application security testing (DAST).  Both static and dynamic testing should be done to have the best chance at finding all the vulnerabilities.  They are complementary approaches, although there is some overlap in the issues they can find.

Latest OWASP Educational Video

The latest episode in the educational video series from Jerry Hoff and OWASP is out. This one is all about stored XSS, aka persistent XSS. Another outstanding resource to introduce concepts of web application security to developers!

Account Lockout Fail

A while back I was hunting for vulnerabilities in a web app's Forgot Password feature. On the first page you had to enter your username and email address. The second page asked a personal security question. That is quite weak. I recommend asking for at least 3 pieces of data on the first step. Asking for only two inputs, especially when they are username and email address, is not very secure. Username and email address are often related. If you know one, you might be able to guess the other. For example, the email address for user "jthomas" could be "jthomas@yahoo.com". I also recommend asking two personal security questions on the second page, not just one.

Anyway, one of the things I like to check is whether or not the account is locked after a certain number of failed attempts to answer the security question(s). This is an important defense against attackers who are trying to break in via the Forgot Password functionality. Sure enough, the message "account has been locked" appeared after I purposefully entered 3 wrong answers.

I was just about to make a note about this commendable practice, but something caught my eye. The input field was still there on the page. That's not something you normally see. Usually the application takes it away after a lockout occurs. So being a curious fellow, I proceeded to enter the correct answer to the question. Lo and behold the application sent me to the next page where I was allowed to reset the password on the account. Now that's an account lockout fail! I'm not sure why or how the developers created a lockout message without actually coding the lockout. Just another example of how difficult app security can be.

Blackhole Exploit Kit

Something I found surprising at first when learning about real-world SQL injection attacks on web applications is that hackers will strive to insert data into the database, not necessarily try to extract data from it. Why would they do this? They want to inject JavaScript code. Basically, the goal is to leverage SQL injection to create a stored XSS attack on application users. It really shows you how supremely dangerous stored XSS vulnerabilities are, huh?

If successful, the malicious JavaScript code will execute in users' browsers. This is bad. Think of it as executable code, chosen by an attacker, running on a victim's computer. One example of the nastiness that can result is the Blackhole Exploit Kit. This malware originated in Russia and is openly for sale. Blackhole is designed to compromise victim computers by exploiting known vulnerabilities in certain software products like Adobe Reader or Java. Symantec researchers have provided a nice writeup of how Blackhole works. Typically, the badness begins with an iframe (created by JavaScript of course) that points to a Blackhole server.

A U.S. Postal Service website was recently found to have been compromised with Blackhole. There is some question how it happened. Regardless, the thing to keep in mind is that a web application that allows for SQL injection might very well lead to stored XSS attacks.

Educational Videos about Web Application Security

A terrific and free resource for introducing developers to web application security concepts is a video tutorial series from OWASP. Jerry Hoff is the leader on this tutorial project. The first two episodes are complete - AppSec Basics and Injection Attacks. The videos are very well done, with nice graphics, sound, and animation.

Latest Forgot Password Best Practices Doc

A new version of my white paper entitled "Best Practices for a Secure Forgot Password Feature" is available. You can download the white paper here. No significant changes were made in terms of content, but it does have fewer pages and a more pleasing look now. The link I had given out previously is no longer valid.

The white paper was used as the basis for the OWASP Forgot Password Cheat Sheet.