Disclaimer

The words and opinions expressed here are those of each article's respective author, and do not necessarily represent the views of CapTech Ventures.

Management Consulting

Secure Development - Error Handling

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:

Secure Development - Cross-Site Request Forgery (CSRF)

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.

Secure Development - Cross-Site Scripting (XSS)

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.

Secure Development - ShmooCon Edition

This week I'm taking a break from my current series of top 10 web application vulnerabilities. Instead, I'll be talking about my experiences at ShmooCon (http://www.shmoocon.org/), an annual IT security conference in DC that has a very similiar feel to the (in)famous DefCon. As usual, ShmooCon was a whole-weekend experience, with lots of things going on besides the official talks: many different contests, vendor booths, lock-picking tutorials, you name it... Throw in about two feet of snow that fell in DC the Saturday of the con, and things start becoming even more interesting! In fact, I was very lucky to get out of town on Monday thanks to a fellow CapTecher who was headed back to Richmond by car.