I got the Kool-Aid. Here’s the low down for all you l33t code reviewers: it makes doing code reviews extremely hard … and extremely easy.
About a year and a bit ago, when I was (re-)writing the OWASP Guide, I realized that checklists don’t work. So how do you review code if you’re not looking for say Runtime.exec()? In my day job, technical issues such as cross-site scripting and SQL injections, although embarrasing, are hardly worthwhile compared to the sort of losses that can happen if business logic is wrong.
Sure the checklist approach, particularly OWASP Guide 2.x, produces huge reports, but does it mean anything? In short, no. The value is where the business is. That means understanding what the code does. And along the way, you can have a look at the dangerous stuff, like XSS and SQL injections.
So I started looking at flows more throughly. In normal J2EE programs, this can be a little tricky. In SOA, where apps are strung together dynamically, it seems like it’s impossible.
Start here and then find the sub-flows (often in flows/*.xml). If you know what you’re doing, you can produce a directed graph to understand the flows. This is key to understanding the important flows, and review them early and often.
Once you have decided upon a particular flow, follow it from what I will call the home flow, through to completion.
SWF uses continuations. This is different to many frameworks, but is closer to the way HTTP works in the real world. Tomorrow, we’ll look at what continuations are, and how to exploit them.