Last week, we had the author of TDD for a Shopping Website LiveProject. Friday at 11am Ranch time, Steven Solomon will be hosting a live TDD session just for us. See for the agenda and registration link
The most important way to secure systems in J2EE is not to get "clever" and design your own security system. Build on an established platform. J2EE itself has a coarse-grained security system that far too many people ignore, yet it can block an awful lot of attacks before they can even reach application code to exploit it. You can then augment this with finer-grained systems such as the Spring Security framework (formerly known as acegi).
The problem with inventing your own security is that security is subtle and it only takes one weakness to invalidate it. Most of us are primarily expected to produce business functionality, but security is a full-time job in and of itself. So it only makes sense to "outsource" the job to the security professionals and use a pre-designed, pre-debugged framework.
One of my biggest peeves about Java webapp development books is that almost invariably they want to use a "login screen" as an example, and that's the beginning of trouble. Like I said, security isn't something that you can just slap in as an afterthought. I have worked in banking, insurance, and finance for a LONG time - and even seen a military app or 2, and every last one of them that tried to invent their own security was a house of cards. Most of them couldn't stand even 5 minutes in the hands of an "honest" hacker like myself, to say nothing of some truly evil people I know.
Good security should be automatic as much as possible. One of the primary benefits of the J2EE container-managed security system is that you don't have to remember to secure each and every item code, since the URL itself is guarded from the outside. A security audit should be one of the final steps of EVERY system modification, since you only have to forget once to get eaten. Another reason why DIY security should be avoided is that it usually requires embedding security code in the business logic, and since the guy who designed the system probably got laid off 3 years ago, you have no real authority on how or when to secure code changes - unlike the industrial-grade systems whose documentation is as close as the local bookstore or product website.
There's lot's more that can be said, but one final note: security isn't just for the application. Ultimately, the entire shop has to be engaged. If you have so much as one router with a weak password, someone can worm their way in. And that's not counting the human fators. Many of the most infamous exploits were pure social engineering. Plus, the supply of gruntled employees is at an all-time low.
Sometimes the only way things ever got fixed is because people became uncomfortable.
Thanks everybody! I got the point that security is a huge topic and I believe that there can not be a single article which can teach me about that. But still I am looking for a book which discuss various points on web security for websites like banking etc.