Struts, I never knew thee
LinkIt's certainly not a complete transformation, yet, but in small projects, I think I'm going to give up on Struts Action, and am going to take Stripes for a spin. Once I finally got my head around all the configuration (or at least enough configuration to get an application operational), I really began to love Struts, but there was always something very inelegant about it.
Now, all my Ruby on Rails fanboy co-workers make fun of Stripes because in Java, it's probably too little, too late. But to me, it's a close-to perfect balance between Struts (where you must understand everything that's going on) and Rails (where you don't know squat about what's going on). I have a problem with not knowing what's going on, as in Rails. And I know that if you spend enough time, you can figure out what Rails is doing. But it's ridiculously simple to do the ridiculously simple in Rails, but if you need to customize that in the least (say, remove key exposure), then you're going to spend as much time re-implementing things, in which case you save yourself no development time, and at a substantial cost (it's basically CGI, so long-running processes have to be fork()'ed and detached). And with Struts, knowing what's going on comes at a huge cost - you have a bazillion configuration files, and as soon as you use the Struts tag libraries, you have to make all the components (an action, a form bean, and the JSP) all at once.
So my task for this week is to get a nice-looking base ActionBean class for Stripes that I can use with utilities necessary to generate and check action tokens to deal with XSRF and Javascript Hijacking. Then on to adding Prototype to some mock-up apps around the house.
And if you can't tell from this post, I'm really slow about adopting new frameworks.
Sylvan, glad you mentioned Struts. Have you seen this article, "HDIV Struts Security Extension Addresses OWASP's Top Security Vulnerabilities"?
ReplyDeleteIn the presentation, the author shows how to use HDIV Struts to deal with the OWASP Top Ten 2007. HDIV does not deal with A7 - Authentication, although the Cookie-Revolver framework is a JEE solution that does.
@dre - thanks for the reminder. HDIV is very good work, and should probably be included in Struts core, assuming Action doesn't die. But I also have a problem with it - when we start programming specifically for security, we start doing "blacklist programming" where we don't allow certain characters - not because of their need or non-need in a business context, but because they're "bad characters". MySpace is a great example of how this blacklisting flat doesn't work. I think almost all of those semantic flaws are better addressed by proper business rule validation (what this data should look like), and always doing presentation-layer output filtering (if sending to an SQL database, parameterized queries, if to xml, xml entity rendering, if to html, html entity rendering, if to the command line, command metacharacter filtering by proper commands).
ReplyDeleteBut on the other hand, HDIV does include work for dealing with XSRF (and by virtue, javascript hijacking). I think that HDIV is the first of what will hopefully be many great security mechanisms that will be "baked in" to the API's and frameworks we use.