David - <div class="gmail_quote">On Sat, Oct 3, 2009 at 2:27 PM, Noel Welsh <<a href="mailto:noelwelsh@gmail.com">noelwelsh@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Addressing the later first, the main vector of attack is by guessing a continuation key. The continuation key is encrypted IIRC, but to make the system more secure you could also check, e.g. IP address or a cookie or some other signing mechanism before serving the request. A stateful servlet doesn't leak any more information than you let it, as everything is in memory unless you choose to encode information in e.g. form parameters. </blockquote><div> Another thing to be thinking about for stateful servlet is that the url is the key to the continuation. As long as the continuation is live, people can email urls to another person, and the other person will get to the exact same page. Depending on the link in question - it can be a security issue. If you want to add additional check such as verifying IP address (which doesn't work for customers behind an anonymous proxy) you'll have to build your own abstractions on top of send/suspend and co. Given that everything is kept in memory, it's conceivable that web-server is more suspectible than others to D/DOS attacks. Obviously unless you have thousands and thousands of servers you probably can't for sure handle such attack with any framework. But making sure you have good continuation expiration policy is only sensible. The nice thing about PLT (assuming you are using xexpr) is that it is less suspectible to html injections than systems that concatenate pages such as PHP. SQL injection still is a primary area of intrusion for web apps - elimination of dynamic SQL is the key. My DBI package eliminates its usage. As you are aware, security is best designed in from the beginning. You start with the why, the assets, and then figure out what is the right approach to eliminate possible security holes without compromising features. Sometimes that means do not store the sensitive data - best security is not to have to guard secrets. And the best long term approach is to train developers on security awareness and secure coding practices. I used to perform application security audit and train developers on security awareness for a fortune 500 company. If you are interested in consultations, please contact me offline. Cheers, yc </div> </div>