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.