Martin G. Nystrom gave a solid talk on web security named Nine ways to Hack a web application (PowerPoint); so solid he actually held the talk twice at JavaOne. He listed out the Top 10 security vulnerabilities from OWASP, how they are carried out, and how to resolve them. I have seen many developers assume that security is merely the domain of IT setting up the environment and our concerns end with simple authentication mechanisms. That is so wrong. Like maintainability and efficiency security should be an “y” we maintain at the top of our heads at all time.

In the last year, I am proud of the clean up my crew done to our web app. There still be dragons in the code-base, but with the new architecture we are giving it a good going over. But there are some design decisions my team has to consider.

First, there is our authentication/authorization mechanism (logging in/logging out). A point Martin made on this issue is how dangerous roll-your-own implementations can be, instead of using the security system built in to most containers. I agree, but there is some issues my company’s requirements raise that a simple pass/fail to accessing a resource with a user-name and password won’t satisfy. One is the user-name/password is not the only method of accessing a system. We have requirements for one-time passes or connections by other systems to read data (which currently is not secure at all, and I hope to get to it sooner rather than later). Another requirement; once someone logs in, we need to have his data easily accessible in a session bean. Yeah, yeah, I know the container can supply that information, but in easy to read JAVA Bean I can expose to the web page integrators? I talked it over with Martin (really approachable guy) and he seem to think what I was thinking; try writing our own security realm provider. If I get around to it, I will be sure to notify him and everyone.

A vulnerability highlighted by Martin is the exposure of user and session ids in communication. We have been pretty good about this, encrypting (using the crypto libraries that ship with JAVA) any user id stored in cookies. But I believe some of our actions take in user ids as parameters, and it is data our web page designers will have access to, so they may place it in a hidden field or cookie themselves without thinking. Sigh.

I believe we prevent code injection, but we should review all that and keep it in mind. The big thing I want to look into is how some of our backend systems get database connections. An old library (not coded by me and I have no love for it) is how we access our data entities. It uses a connection pool, but even then it is constantly pulling connections on and off the pool to handle a single request. For my own libraries I only get one connection that is used for the entire request life cycle. In the former case, DOS attacks would be dragging down our database with having to maintain a larger set of connections, while in the latter we at most have only one connection per each hit.

Anyway, I highly recommend Martin’s lecture. More experienced web developers may find some of it old hat, but its always good to be refreshed on good coding principles, and newer developers will learn so much.