AppSec Notes

Latest OWASP Educational Video

noreply@blogger.com (Dave Ferguson) — Fri, 29 Jul 2011 03:29:00 +0000

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

noreply@blogger.com (Dave Ferguson) — Sat, 02 Jul 2011 02:17:00 +0000

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

noreply@blogger.com (Dave Ferguson) — Thu, 21 Apr 2011 05:38:00 +0000

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

noreply@blogger.com (Dave Ferguson) — Mon, 07 Mar 2011 04:25:00 +0000

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

noreply@blogger.com (Dave Ferguson) — Sat, 11 Sep 2010 17:23:00 +0000

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.

Password Complexity Rules

noreply@blogger.com (Dave Ferguson) — Thu, 09 Sep 2010 02:43:00 +0000

A Consumer Reports blogger has been taking Facebook to task for allowing dictionary words to be used as passwords. I can't confirm that Facebook actually forbids the use of these words like the blogger claims. The signup page did not reject the word "animal" when I tried it, and their password strength FAQ does not state that dictionary words are banned.

The flak got me to thinking about password complexity rules in general. It needs to be evaluated when assessing the security posture of a web application. I see huge variety in the password rules that are being used. That's not the problem. It makes sense that highly sensitive applications, such as financial or governmental, should enforce stricter requirements. The problem I see is that the password rules simply aren't strong enough, ever. Identifying this weakness calls for a manual test or a code review. It is not something a web app scanner like WebInspect or AppScan would flag. Maybe that's part of the problem.

Below are the password rules I normally recommend for Internet-facing web applications.

Minimum password length of 7
Maximum password length of 20 or more
Require at least one uppercase letter
Require at least one lowercase letter
Require at least one number
Allow special characters
Do not allow any part of username to appear in the password
Do not allow the user's first or last name to appear in the password
Do not allow any form of the word “password”
Do not allow the same character three or more times in succession

Notice there is nothing about banning dictionary words (other than a number being required). Applications can mitigate that particular risk by using an account lockout mechanism to prevent automated password guessing. Also, it probably goes without saying, but passwords should be case sensitive.

Please let me know if you have any other suggestions on this subject!

Bug Editing Cookies in Web Developer Extension

noreply@blogger.com (Dave Ferguson) — Fri, 28 May 2010 23:26:00 +0000

Just a quick note I've been meaning to post about a small bug in Chris Pederick's Firefox Web Developer extension. It is a fantastic extension and I use it all the time, especially for working with cookies. Kudos to Mr. Pederick!

Unfortunately, what I noticed is that if you have "accept third-party cookies" unchecked in Firefox's privacy options, you can't edit cookies or add cookies. In fact it ends up deleting the cookies that you try to edit. D'oh!

This bug bit me a few times when I was trying to demonstrate session hijacking while teaching an application security class. This bug is a known issue and I'm hoping Chris can find a way to make it work in the next version. In the meantime, I will keep using the extension and trying to remember to enable third-party cookies whenever I teach the class.

A Case for HttpOnly

noreply@blogger.com (Dave Ferguson) — Mon, 17 May 2010 13:26:00 +0000

Last month the Apache Infrastructure Team fell victim to a common web application attack. Rather than keep the information secret, they were kind enough to explain how the attack occurred. The initial attack leveraged cross-site scripting to steal users' session IDs. This is something that could have been prevented if the web app's session cookie had been marked with the HttpOnly attribute. When a web app sets a cookie, the presence of HttpOnly instructs browsers to disallow client-side script from accessing the cookie.

You will sometimes hear or read that HttpOnly helps prevent XSS attacks. That is not quite true. It helps prevent session hijacking. Specifically, it helps guard against one attack vector, namely where session cookies are stolen via XSS. HttpOnly can be used for any sensitive cookie that you don't want falling into the hands of fraudsters. (I should use "fraudster" more often - it is a fun word)

There is one caveat to using HttpOnly. It might break your application if it was written in such a way that the functionality depends on JavaScript having access to the cookie. That is fairly uncommon however.

Dynamically-Generated PDFs

noreply@blogger.com (Dave Ferguson) — Wed, 12 May 2010 14:19:00 +0000

Many web applications will generate PDF files for users so they can view nicely-formatted statements, reports, etc. These dynamically-generated PDFs are typically accessed by users in two different ways.

1) The application creates an actual PDF file on the server and redirects the user's browser to the file (via 302 response code).

2) The application streams the bytes for the PDF directly to the user's browser as part of the HTTP response.

This second method is much more secure. The reason is that a PDF file sitting on a server can probably be accessed by anyone. The only information needed is the directory and the file name. That said, I have seen the first method implemented securely, but two important mitigating factors were employed. First, the application used randomized file names. A globally-unique identifier (GUID) is great for this. Second, the files were deleted within about 10 seconds of them being created. These two factors, when combined, made it almost impossible to gain access to another user's PDF file.

Testing for this vulnerability is simple. If you run across an application that allows you to download a dynamic PDF, make note of the URL when viewing the PDF. Is it a direct link to the PDF file? If so, copy the link, open a different browser (not another window of the same browser), and paste the URL. Is the PDF loaded? If so, then you have a problem, especially if the file name is guessable or follows a pattern. You might also check to see if the PDF is deleted from the server after a time.

This topic applies to other static files that your application might generate dynamically too, such as Excel files. PDFs just seem to be the most common.

Authentication Flaw

noreply@blogger.com (Dave Ferguson) — Tue, 20 Apr 2010 03:45:00 +0000

During an assessment of a financial web application, I found a serious flaw in authentication. The web security scanners at my disposal gave a "seal of approval" on the unauthenticated surface area of the application. Yet, in a matter of a few hours after getting the go-ahead to test the application, I had fully compromised a user's account. How? Basically, by using my brain as a hacker might. Screen shots proving my authenticated access were probably eye-opening to the customer as they had given me only the URL for the site, not any user credentials.

This was a case of flawed forgot password functionality. For users who had forgotten their password, the application worked as follows:

Step 1 - Enter username
Step 2 - Answer question to personal security question and enter email address
Step 3 - Receive email with a new, system-generated password

Can you find the flaws? First, the application asked for only one piece of data initially: the username. It is not hard to guess a valid username. I found that "jsmith" was a valid username. Second, the application asked the user to enter his email address on the second step. Um, shouldn't this be part of the user's profile and already known to the application? Why trust a value entered by the user? Third, which I didn't actually tell you, is that the application allowed an unlimited number of attempts to answer the personal security question.

It happened to be that jsmith's security question was "What was the name of your first pet?". I fired up Burp Intruder with the 100 most common dog and cat names. Very soon I received an email with jsmith's newly reset password. It turned out that his first pet was named "Rocky" (I'm assuming jsmith is a man here - would a girl naming her pet "Rocky"?).

This is an example where a scanner (and a web app firewall most likely) would not alert you to this security hole. All requests, data, and URLs were perfectly legitimate in my attack. The flaws were caused by poor design decisions.

Don't Need No Stinkin' Coupon Print Activator

noreply@blogger.com (Dave Ferguson) — Wed, 03 Mar 2010 07:38:00 +0000

This is a real-life example of exploiting a web application security flaw. I received an email from Discover Card offering some Lowe's coupons.
I was needing to buy some stuff there anyway, so I decided to grab them.
I was soon shocked and amazed. Turns out they expect you to download an executable (something called a"Coupon Print Activator") and run it just to print the coupons.
I am not in the habit of running strange .exe's.
But, I really wanted those coupons (and perhaps sensed my hacking skillz were being challenged). I looked at the requests being made to the server, and noticed that dsppreprint.cfm had some JavaScript pointing to interesting URLs, one to "print.cfm" and one to "print_noplugin_redirect.cfm". The query strings were radically different between the two, so I decided to append the query string from print.cfm onto the other .cfm file.
This hybrid URL ended up in a round-about way returning some HTML with an "embed" tag with a bunch of attributes. One of the attributes was very interesting to me.
A request to this URL returned some raw data that appeared to be meant for consumption by the Coupon Print Activator. It also led me to discover yet another URL.
A request to this URL returned the following jpeg image (numbers masked to protect something or other):
So I got a bar code. Wonder if I could print this bar code and use it at the self-checkout at Lowe's? This would not be unethical as I was entitled to the coupon anyway. I just didn't want ro run that Activator thingy! As a simple test, I jumped over to Lowes.com and added a ceiling fan to my shopping cart. There was an input field for "Promotional Code".
Proceeding to enter the number that appeared below my bar code, I was pleased to see my $10.00 discount applied.
To sum up, coupon obtained, Activator thingy bypassed. Sorry I do not have time get into how this site could have been written more securely. Suffice it to say that exposing data, URLs, and client side logic is not good.

Counting Lines of Code

noreply@blogger.com (Dave Ferguson) — Fri, 22 Jan 2010 05:36:00 +0000

Want some interesting metrics about your code? A nice little Windows utility called LOCmetrics could be just what you are looking for. When preparing for an application source code review, I usually need an estimate for the number of lines of code involved. I've found the numbers provided by development teams can vary significantly from what we actually see when we get the code. That is why I am going to start recommending they run LocMetrics.

LocMetrics has a simple GUI and works with C#, C++, Java, and SQL code. Run LocMetrics and it will dump out physical LOC, executable-physical LOC, and executable-logical LOC. Plus, you get bonus information like number of comment lines, blank lines, cyclomatic complexity (aka McCabe VG complexity) and LOC counts broken down by directory. The most important results are shown in the GUI itself and you get a HTML file containing more detail.

Here's a screen shot of the GUI:

I ran LocMetrics on a few Java libraries for comparison sake. Here are the results.

OWASP AntiSamy 1.3
Lines of Code = 4,576
Executable physical LOC = 1,972
Executable logical LOC = 1,444
Cyclomatic complexity = 259

OWASP ESAPI 1.4.2
Lines of Code = 21,263
Executable physical LOC = 8,926
Executable logical LOC = 6,172
Cyclomatic complexity = 1,547

JSE 1.6.0_17 (java.* package only)
Lines of Code = 556,018
Executable physical LOC = 200,567
Executable logical LOC = 136,076
Cyclomatic complexity = 38,106

Tomcat and HttpOnly Session Cookies

noreply@blogger.com (Dave Ferguson) — Thu, 26 Nov 2009 00:24:00 +0000

Just wanted to let you know that Apache Tomcat can now be configured to use HttpOnly session cookies. I had forgotten about Jim Manico's crusade to get HttpOnly support in Tomcat. It is a shame that it took so long to happen. Microsoft had introduced the concept of HttpOnly cookies primarily as a defense against session hijacking where a cross-site scripting attack is used to steal a session cookie. If a web application sets a cookie with the HttpOnly attribute, web browsers do not allow client-side script to access the cookie. The first browser to support HttpOnly was Internet Explorer 6 SP1 and for a long while IE was the only browser that supported it. That has changed as Firefox and Opera, for example, now support HttpOnly as well.

In Tomcat, enabling HttpOnly for the JSESSIONID is done at the context level, which means it can be controlled for each individual web application. You simply need need to add the following attribute to the <context> element:

useHttpOnly="true"

The default is "false", so you must explicitly add the line above to implement an HttpOnly session cookie. This capability first appeared in Tomcat 6.0.19 (current version = 6.0.20) as well as Tomcat 5.5.28, which is currently the latest version in the 5.5 branch.

OWASP Top Ten Changing for 2010

noreply@blogger.com (Dave Ferguson) — Thu, 19 Nov 2009 02:03:00 +0000

A new version of the OWASP Top Ten will be arriving in early 2010. At the AppSec DC conference, I attended a session by OWASP board member Dave Wichers that described the proposed changes. First, the emphasis will be on risk, whereas the 2007 version focused on the most prevalent vulnerabilities. The updated list considers not just prevalence, but also the damage level that could result from successful exploitation.

The biggest changes are that Malicious File Execution and Information Leakage/Improper Error Handling are dropping off the list for 2010. In their place, Security Misconfiguration and Unvalidated Redirects/Forwards are being added. Some other items are shifting around. The chart below sums up the changes very nicely.
The release candidate of the new Top Ten is now available for download as a PDF document. OWASP is requesting feedback on anything and everything until December 31, 2009. I've not yet read the document in detail. At first glance, I wonder about the naming conventions. For example, is "Injection" descriptive enough? Is "misconfiguration" a real word? Why is "Insecure Communications" changing to the more cryptic "Insufficient Transport Layer Security"? I guess now is the time to ask!

XSS via Cookie - How Severe?

noreply@blogger.com (Dave Ferguson) — Thu, 05 Nov 2009 21:16:00 +0000

Take a web application that sets a cookie. Now let's say the application takes the cookie value included in subsequent requests and outputs it into the HTML of the responses. Also assume this occurs with no authentication required and with no output encoding being done. Yes, this application is susceptible to reflected cross-site scripting.

I recently tested such an application. Interestingly, both HP WebInspect and Burp's active scanner reported the XSS vulnerability, but they were at opposite ends of the spectrum in terms of rating its severity. WebInspect rated it "critical" (the most severe rating), while Burp rated it as "information", which implies you don't even need to concern yourself about it.

So why the big disparity in these tools? Is it critically severe, or is it really no big deal? In my view, the answer is somewhere in between. This type of vulnerability is clearly very difficult to exploit. An attacker would somehow have to cause a victim's browser to send a script-injected cookie as part of a request to the vulnerable site. But regardless of the difficulty level, the application should properly encode the cookie value when it is written into the HTML page. Please let me know your opinion on how serious you think this type of vulnerability is.

Internet Safety for Parents

noreply@blogger.com (Dave Ferguson) — Sat, 17 Oct 2009 04:36:00 +0000

A friend asked me about Internet safety including how parents can protect children from the nasty stuff that's out there. I replied by describing what I do at home. It's probably not the perfect system, but it seems to work for me.

If you know nothing about Internet safety, start by visiting the resources listed here. Educate yourself about Internet dangers and the kinds of protection available.

In terms of filtering, I recommend using the Windows Vista built-in parental controls. You can select age-appropriate access level, define time restrictions, view logs of sites visited, etc. Each user must have their own login on Vista (no sharing accounts!). If you're not using Vista, please think seriously about upgrading. The parental controls feature alone is worth the money. However, at this point in time you should probably upgrade to Windows 7 since its release date is near. I assume it has the same or even better parental controls.

Defense in depth applies in protecting children too. So for better protection, I also recommend using BlueCoat's K9 Web Protection (available for free). It is not as flexible (all users have the same filter level), but it catches some stuff that Vista doesn't. If you are currently stuck on Windows XP, use K9 at least. Just remember it is not perfect.

Finally, if you don't want a hacker opening a reverse shell and taking over your computer, make sure you check for software updates at least weekly! Or, have it done automatically if possible. These updates should include not just Windows and Anti-Virus software, but also Internet Explorer, Adobe Reader, Flash Player, Firefox, Thunderbird, Java, iTunes, etc.

ColdFusion Session Fixation

noreply@blogger.com (Dave Ferguson) — Sat, 10 Oct 2009 01:27:00 +0000

I usually see session fixation vulnerabilities with Java web applications. Just recently I found a ColdFusion application vulnerable to session fixation. This nasty security hole greatly increases the risk that legitimate sessions will be hijacked. Both HP WebInspect and Burp Pro's active scanner failed to find this vulnerability. Testing for session fixation is quite easy to do, so I ran a quick test for it manually, and I'm very glad I did.

When testing for session fixation, I like to use two different browsers: IE and Firefox. If the login page for an application is https://someapp.com/login, my test for session fixation consists of the following steps:

https://someapp.com/login.jsp;jsessionid=[sessid]

https://someapp.com/login.cfm?cfid=[cfid]&cftoken=[cftoken]

The ColdFusion site I tested was handling the situation even more poorly than usual. It was not necessary to visit the site initially to obtain legitimate session IDs from the server, so steps 1-3 above weren't required. An attacker could make up *any* 6 digit value for "cfid" and *any* 8 digit value for "cftoken", embed the made-up values in the malicious URL, and the application happily accepted them. The server responded by assigning CFID and CFTOKEN cookies based on the made-up values as illustrated below.

The URL of the request was:
https://someapp.com/login.cfm?cfid=999555&cftoken=29292929

The HTTP response contained the following headers:
Set-Cookie: CFID=999555; path=/; Secure
Set-Cookie: CFTOKEN=29292929; path=/; Secure

Who Has the Answers to Your Security Questions?

noreply@blogger.com (Dave Ferguson) — Sat, 03 Oct 2009 06:31:00 +0000

I'm back after a summer that was crazy busy for me. Recently, I had two eye-opening occurrences where other people viewed the answers to my personal security questions - you know, those questions that web sites ask in case you forget your password. These incidents weren't security breaches, just normal business processes that appear to be more prevalent than I thought.

In the first incident, I got a new cell phone for my daughter at a retail store of one of the major providers. I gave the clerk my cell number so he could look up my account and he then asked for my "PIN". I didn't know it. I knew my password for their site, but that's not what he wanted (I wouldn't have told him anyway). Since I didn't know my PIN, the clerk followed up by asking me "What's the model of your first car?". Whoa. I proceeded to answer the question. He looked at his monitor and said "okay, good".

The other incident involved Vanguard again. I got locked out of their site (not just unrecognized like last time). The darn thing wouldn't even allow me to answer my security questions. Forced to call Vanguard customer service, I explained to the CSR that I was completely locked out. Wouldn't you know the CSR simply asked me to answer two of my security questions? I provided the correct answers, and he immediately unlocked my account allowing me to log in again.

Moral to the story: These answers are not simply being used programmatically or being treated as confidential data. Realize that the answers to your personal security questions could be viewed by other people in many cases.

Vanguard.com Doesn't "Recognize" Me

noreply@blogger.com (Dave Ferguson) — Wed, 24 Jun 2009 23:44:00 +0000

I upgraded the hard drive on my home computer. The first time I tried to log into my Vanguard account online, it asked me to answer a security question. No problem I thought to myself. The site just doesn't recognize me since I have a new drive. It wants extra information to be sure I'm me. This is part of PassMark "sitekey" functionality. I typed in the answer to the question and was promptly told "sorry, invalid answer". Weird. I tried again. same result. I was 95% sure I was entering the correct answer, but each time I tried, it didn't work. Eventually I got an email telling me I disabled my ability to log in from an unrecognized computer due to repeated wrong answers. Nice. The web site didn't inform me of this - only the email. The email also stated I could now only log in if I used a recognized computer. To log in from an unrecognized computer, I would have to reset my security questions or call Vanguard customer service. Great.

Luckily, I had logged into Vanguard from my work computer, meaning it was "recognized" and I wasn't asked a security question. Using my work computer, I logged in and reset my security questions and answers as required. Now back to my home computer. I was quite confident facing a security question this time. But again, failure! Why does it not accept my answer? I was 100% sure it was correct this time. I just reset them for cryin' out loud.

At this point I concluded that it was a bug in Vanguard's site. Do I call their customer support? Ugh. Instead I took the approach of trying to get the site to "recognize" my home computer. Long story short, I copied a single file from my work computer to my home computer and solved the problem. I knew the PassMark/sitekey solution uses a Flash local shared object to determine whether a computer is recognized. It does not use a persistent cookie as you might first guess. Anyway, I found the shared object file "PassMark.sol" in the following directory on my work computer:

C:\Documents and Settings\[user]\Application Data\Macromedia\Flash Player\#SharedObjects\xxxxxxxx\vanguard.com\passmark\flash\pmfso.swf

where "xxxxxxxx" changes for different users. I copied PassMark.sol over to the corresponding directory on my home computer and it worked like a charm! Vanguard's site suddenly recognized my home computer and I got logged in.

This episode was very frustrating and got me wondering how normal users feel. After all, I was only able to solve the problem with:

Luck - I had another computer that was recognized
Esoteric knowledge - Vanguard's site uses Flash shared objects to recognize a computer

The vast majority of users are not web application security experts. They must be going crazy, and on the phone with support a lot.

Patent Abuse?

noreply@blogger.com (Dave Ferguson) — Tue, 09 Jun 2009 02:42:00 +0000

This is not strictly an application security post, but I just read an amazing article about a security/tech company here in Dallas. I had never heard of DeepNines, Inc. even though I live in DFW and work in the information security field. Based on the article, my first impression of DeepNines is not good. Apparently they won an $18 million settlement against McAfee because McAfee violated their patent. Their patent is "for detecting attacks on a site in a communications network and for taking actions to reduce and/or redirect such attacks". Not satisfied with their windfall, they are suing again, this time Secure Computing, which was just acquired by... McAfee. Now McAfee has to deal with them all over again!

This looks like an egregious case of patent trolling to me. How could a patent be granted for such a thing? Patents are supposed to be "nonobvious to a person having ordinary skill in the area of technology related to the invention" (ref). It's highly questionable that's true here. It's like patenting a steering wheel as "the process of taking an action to cause the rotation about a vertical axis the front-most wheels of a vehicle causing said vehicle to turn in a rightward or leftward direction."

One of my previous employers is dealing with something very similar. It's too bad there are companies that don't like to compete on the merits of their technology or customer service. They find it easier to acquire questionable patents and then sue the pants off anyone they see as a threat. For some companies, patent trolling actually seems to be the true business model.

Simultaneous Sessions for a Single User

noreply@blogger.com (Dave Ferguson) — Thu, 28 May 2009 01:47:00 +0000

It's a common request or recommendation that a web application not allow a user to have more than one session active at a time. In other words, after a user logs into an application, he should not be permitted to open a different type of browser (or use another computer) to log in again until his first session has ended. I've recommended this myself, but it's always been kind of muddy as to why this should be done. It is not trivial to implement this feature in the code. Recently, one of our clients wanted to better understand the reasons behind this recommendation. I was given the task of explaining.

The bottom line is that I could not find one strong, clear-cut reason for disallowing simultaneous sessions for a single user. There are a number of scenarios where it might help. Listed below are the reasons I came up with for implementing this feature. Please let me know if you have other ideas on this subject.

An application has a licensing scheme that allows only a limited number of concurrent users or requires users to pay for access or premium content. A technical control to prevent simultaneous sessions for a single user ID would limit the financial harm caused by users sharing login credentials.
It is out of the ordinary for a user to be logged in from more than one location (or more than one type of browser) for a given point in time. Anything out of the ordinary should be assumed to be a potential security risk.
An attacker somehow steals a user's credentials (perhaps by sniffing unencrypted HTTP traffic) while the user was authenticating to the application. The attacker immediately tries to log in with the stolen credentials. The application sees that the user is already logged in and returns an error to the attacker, thus temporarily protecting the account.
An attacker shoulder surfs to obtain a valid username (but not the password). He then immediately proceeds to run a password guessing or dictionary attack hoping to determine the password. If his attack happens to be successful during the time the legitimate user is logged in, it would prevent the attacker from gaining access.
An attacker and a victim log in such that their sessions overlap. The application displays an error message that alerts the victim that someone else is using his account. The victim may contact the site owner, spurring an investigation, which might uncover a compromised account.
It could help ensure data integrity and non-repudiation. A user may have multiple authenticated sessions at the same time, and one of the sessions might be used to make a critical change. If a user claims he never made such a change, it could be a problem for the logs to show that two authenticated sessions existed and the user claims he was logged in only once.
It could help defend against a malicious user who wishes to overload the server memory by creating an excessive number of authenticated sessions. Authenticated sessions typically use much more memory on the server than unauthenticated sessions. With valid credentials and no limit to simultaneous sessions, a user could potentially create a denial-of-service condition.

After my research, I came to the conclusion that disallowing simultaneous sessions often does not increase an application's security posture enough to justify the required development and implementation cost. Obviously there are some special situations, like the licensing issue, where it could make sense.

This feature may actually introduce new problems. Let's say a user logs into an application and his machine crashes or the power goes out. A few minutes later, when trying to log in again, the user is denied access and told he's already logged in. Of course, it's true from the server's perspective (his session is still active), but now there's an angry user shouting profanities at his computer. Unless the user knows his previous session ID (fat chance), there's nothing for him to do but wait until the session expires due to inactivity or call your customer service department and complain.

The Importance of Case-Sensitive Passwords

noreply@blogger.com (Dave Ferguson) — Mon, 18 May 2009 22:54:00 +0000

It is rare that I encounter a web application that doesn't support case-sensitive user passwords. But it still happens. In my experience this often occurs not because the application developers weren't cognizant of security, but because the authentication is actually processed by an old, backend system that doesn't support case-sensitive passwords. Let's review why implementation of case sensitive passwords is so important.

At first you might think that having case-sensitive passwords would double the number of possible passwords. Of course, that is not how it works. Let's say a user decides he wants a password of "orange7". Without case sensitivity, the number of possible passwords for this user is exactly one. But with a case-sensitive password, the user can choose from sixty-four possible passwords:

orange7 Orange7 oRange7 orAnge7 oraNge7 oranGe7
orangE7 ORange7 OrAnge7 OraNge7 OranGe7 OrangE7
oRAnge7 oRaNge7 oRanGe7 oRangE7 orANge7 orAnGe7
orAngE7 oraNGe7 oraNgE7 oranGE7 ORAnge7 OrANge7
OraNGe7 OranGE7 OrAnGe7 OrAngE7 OraNgE7 ORaNge7
ORanGe7 ORangE7 oRANge7 oRaNGe7 oRanGE7 oRAnGe7
oRAngE7 orANGe7 orAnGE7 orANgE7 oraNGE7 oRaNgE7
orANGE7 oRaNGE7 oRAnGE7 oRANgE7 oRANGe7 OraNGE7
OrAnGE7 OrANgE7 OrANGe7 ORanGE7 ORaNgE7 ORaNGe7
ORAngE7 ORAnGe7 ORANge7 oRANGE7 OrANGE7 ORaNGE7
ORAnGE7 ORANgE7 ORANGe7 ORANGE7

So, having case-sensitive passwords vastly increases the universe of possible passwords and sets the bar significantly higher for hackers running brute force or dictionary attacks on a web application. For example, 64 passwords must be checked versus only one in the scenario presented here.

As an end-user, be sure to take advantage of case sensitivity to strengthen the security of your account. Use a mixture of upper and lower case letters. It may prevent a lazy or time-crunched attacker -- who checks lower case passwords only -- from compromising your account.

IE Developer Toolbar Follow-Up

noreply@blogger.com (Dave Ferguson) — Thu, 14 May 2009 01:05:00 +0000

In an earlier post, I had commented on the fact that the IE Developer Toolbar has a problem in that it doesn't report cookies that are marked with the "HttpOnly" attribute. Well, as they said in the movie Independence Day, that's not entirely accurate (clip). There is an exception. The exception is when the cookie is a persistent cookie. The tool apparently doesn't utilize JavaScript in that case, and correctly reports the existence of the cookie. It's not actually a situation that would occur very often. Applications normally only need to mark *sensitive* cookies with HttpOnly, and sensitive cookies should not be persistent in the first place.

More on Blacklisting and XSS

noreply@blogger.com (Dave Ferguson) — Sat, 25 Apr 2009 18:05:00 +0000

Following up on my last post, another scenario where blacklisting of angle brackets doesn't work to stop XSS is where untrusted data is output into an existing section of script. Consider a JSP application that takes a URL parameter and outputs it within opening and closing <script> tags. If encoding is not being done, which it often isn't, then an XSS attack would be possible. An attacker would simply close the previous executable line of script with a semicolon and immediately follow that with his malicious script.

An example of how this might occur is shown below. A JSP defines a JavaScript function called "gotoPreferences()", which causes the browser to re-navigate to a URL ("prefURL"). Note that prefURL is constructed dynamically by incorporating untrusted data -- the "category" parameter.

To exploit XSS, an attacker might set the value of "category" to:

"";location.href="http://www.evilsite.com"

The resulting line in the HTML would then be:

var prefURL="https://www.server.com/prefs.jsp?category=" + "";location.href="http://www.evilsite.com";

When the function was called, the victim would be navigated to the attacker's site instead of the expected URL.

Blacklisting and XSS Failures

noreply@blogger.com (Dave Ferguson) — Fri, 24 Apr 2009 04:26:00 +0000

Looking at a financial application, I was somewhat surprised to see blacklisting of angle brackets used as the main countermeasure against cross-site scripting. Stripping angle brackets or throwing an error every time you see one in a request is not sufficient protection against XSS. There were a couple of ways to exploit XSS in this application despite the rigorous rejection of angle brackets.

One attack vector was due to a page that accepted a parameter containing a relative URL to another page in the application. It ended up being a tailor-made way for someone to avoid the blacklisting altogether. When a request was received, this special page caused a forward (not a redirect) to the specified URL. The code that rejected angle brackets was hit on the request from the client only, and not when the forwarding was done. Therefore, "<" and ">" could be slipped in by double URL-encoding them in the initial request as follows: %253C and %253E (%25 is a URL-encoded percent sign).

The other XSS attack vector was via JavaScript event handlers. This technique is available when user-supplied data is output to the attribute list of a page element. This often happens for an <input> tag, where the HTML form has multiple text inputs. The user enters the data, but one or two values may be invalid, so the application returns the same page and prepopulates the values that were entered. An attacker can employ XSS by closing off the previous attribute with a double-quote (assuming double-quotes were used) and injecting an event handler such as onMouseOver, onFocus, or onClick.

An example injection is: x%22%20onFocus%3d%22alert('xss')%22%20%22. The resulting HTML might look like this:

Notice there were no angle brackets used in this attack, so blacklisting those characters did not provide any protection.