Due to vacation schedules and lots of other things going on this summer, "next week" has turned into "next month" for this final post in my top 10 series. Today's subject may be a little surprising to many developers: Aren't buffer overflows so 2003? Hasn't this been fixed in virtually all modern programming languages by preventing direct memory access? While the second statement is certainly true, it doesn't mean that today's developers don't need to be aware of buffer overflows, especially when interacting with closed-source and/or legacy software written in languages that allow arbitrary memory access (C and C++ being the most common examples).

No matter how well-written or secure your application is, Denial of Service (DoS) attacks always pose a risk. Most web applications are publicly accessible by design, so the server/application really has no way to tell 10,000 legitimate user requests from 10,000 malicious requests designed to bring it down. If a DoS attack originates from a single source or from a few sources, it can be blocked fairly easily once the source(s) are identified. Unfortunately, most DoS attacks today are actually DDoS attacks (distributed DoS), which means that they originate from hundreds or thousands of different places across the Internet, most commonly from botnets. This makes it nearly impossible to shut down the malicious traffic without also cutting off the legitimate users...which is exactly the point of a DoS attack.

Some common types of DoS attacks are the following:

Writing secure code is the most important aspect of secure development, since this is where the proverbial rubber meets the road. However, there are many other environmental factors that contribute to your application's overall security posture. This includes the application/web server, backend systems such as databases, and of course the underlying operating systems and network infrastructure. Consider the following common vulnerabilities:

So you've locked down your user input validation, your authentication/access control, and even your error handling. What else could possibly go wrong? If you're not careful about what data you store and how you protect it, you can cause serious damage to your users or even be held legally responsible for data breaches.

Protecting the back-end storage of your application is just as important as locking down the front-end user interface and web server. Some of the most common mistakes include:

Last Wednesday, I spoke at the Richmond Java Users' Group (RJUG) about many of the same topics I've been covering in this blog, focusing mainly on the OWASP Top 10 vulnerabilities. I used some of the sandbox tools I introduced in my last post to do short demonstrations throughout the talk. I am attaching my slides to this post, which also include links to the tools I used for the demos (see the second-to-last slide).

Next time, I will continue the Top 10 series by talking about insecure storage issues.

It's been a while since I've had the chance to put up a blog entry, mainly due to travel during the last few weeks. This post will take a quick break from the Top 10 series and introduce some useful tools you can use to get hands-on experience with web application vulnerabilities in a sandbox environment.

Traditionally, you would first have to spend a decent amount of time setting up a server, installing/configuring the applications (or worse, writing your own), generating fake data, and generally performing lots of sysadmin work that is really not related to IT security. These tools (along with many others), make this process much easier by providing ready-made environments where you can explore secure coding concepts and "get your hands dirty" on other people's programming mistakes (both intentional and unintentional).

In the last two posts, we've talked about access control (authorization) and session management. Today we'll look at the final component that ties these two together into a coherent web application security approach: authentication. After all, it's nearly pointless to have strong access control and session management when there is insufficient authentication taking place to ensure users are who they claim to be.

Authentication is required for all non-public parts of an organization's website. In some cases it may only be used to make a simple yes/no decision: for example, many subscription services really only care that you're on the list of subscribers. In other cases, there may be complex application and/or business logic associated with the access rules and user roles within the application. Authentication is not only important for access control purposes, but also for logging and non-repudiation in the future.

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.

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.

A few years ago Bruce Tate and Justin Gehtland wrote a book entitled Better, Faster, Lighter Java.  In this book they argue that sometimes a simpler solution is the right answer.   As developers we often become attached to our "Golden Hammer" and try to use it for every purpose.  Large Java EE containers such as Weblogic, JBoss and WebSphere have a place in our toolbox, but sometimes what you need is a simple container which starts quickly and has a small footprint.