Mar 30 2010
Last time, we talked about access control, which typically happens once a user is authenticated and a session is established. Today, we'll go into more details on the session management processes itself. I was originally going to include authentication in this discussion as well, but the blog entry started getting really long. I will write a separate post on authentication issues next time, and for now we'll talk about web application session management.
Mar 20 2010
Most people are familiar with authentication, the process of proving who you are (usually with a username and password). Access control sounds very similar, but there is a subtle difference: access control refers to the permissions assigned to an authenticated person or entity. In other words, access control first requires successful authentication, and then it can use the identity of the logged-in user to determine to which resources he has access.
Mar 09 2010
At first glance, error handling may seem more like a functionality issue than a security concern. However, when done improperly (or worse, not at all), error handling can lead to security holes in your application. The classic example of error handling working in favor of the bad guys are failed logins, where the system gives a different error message for an incorrect username vs. an incorrect password. This allows the attacker to first figure out a working username and then focus on brute-forcing the password for that user. This is much faster than than having to try an exponentially-higher number of all username-password combinations.
In general, good error handling is important because error messages can reveal implementation details and pinpoint flaws in your application if they are not used correctly. Here are some common examples of incorrect error handling:
Feb 26 2010
Last week, we talked about Cross-Site Scripting (XSS) and briefly touched on Cross-Site Request Forgery (CSRF). These two attacks are very common and dangerous, which explains why they consistently rank among the top five web application vulnerabilities in almost all recent studies. This week, we'll go into more detail on CSRF. First, a quick reminder about the difference between these two attacks: XSS involves injecting unauthorized code into web pages, while CSRF involves making unauthorized requests that appear to come from a legitimate, logged-in user. Another way to think about the difference is that XSS abuses the user's trust in the web application, while CSRF abuses the trust of the web application in the user.
Feb 19 2010
Originally, this week's post was supposed to cover both Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF), but I quickly realized that each of these topics alone are more than enough to fill a blog entry. These two are some of the most common and dangerous web application attacks, and at first glance, it may be hard to tell the difference. Here is an easy way to distinguish them: XSS involves injecting content into an existing page, while CSRF involves taking unauthorized actions on behalf of a logged-on user. XSS can be used (and often is) to launch CSRF attacks, but they are two separate attack modes.