[Owasp-leaders] Struts2 security gap analysis
Andrew van der Stock
vanderaj at owasp.org
Wed Apr 15 23:20:35 EDT 2009
@James - you've obviously not met Arshan then. He likes offense. :)
@Arshan - I've sent you some comments as a marked up document, but I
think it needs to be a lot more structured than it is, with the
appendices rolled into the chapters. You shouldn't have to go to two
places in the document to figure out what is the gap and what is needed.
The opinion on the state of the J2EE security landscape taints the
document overly much. There's no justification (i.e. references or
well argued reasoning) for the opinions, and none of the opinions help
Struts2 developers decide why they should implement or ignore a gap. I
strongly suggest the removal of opinion for the most part outside of
I suggest the following structure:
Basically the current text
2. Gap analysis
A simple table for each chapter, with three columns, one line per row
using ASVS Level 2B as the baseline.
Verification | ESAPI |
2.6 Verify that all authentication decisions are logged | Present |
This section should be entirely factual with zero opinion. If there's
a partial implementation, consider footnotes, end notes, or use the
recommendation text to describe what needs to happen to bring it up to
A simple bullet list of your existing recommendations, including why
each missing control should be included in Struts2 (or whatever
product). This is where opinion can creep in, as it's about what WE
think Struts2 should do. We should also use RFC2119 meanings for may,
should, could, must, etc. as currently, there's too many wooly
recommendations that have unclear outcomes.
There should be three choice of recommendation:
A) Struts2 to document preferred mechanism (i.e. in Logging, this is
to use Log4j) in the official documentation
B) May implement
C) Should implement
For the last two, we need to put up absolutely everything they need to
do to satisfy the gap. Adopting ESAPI is one choice for them, but that
choice belongs in the introduction of the entire document, but to
continuously state "Adopt ESAPI" is not going to cut it as it does not
describe HOW to close the gap.
For example, in the input validation chapter, we should describe what
is missing from Struts2 (e.g. canonicalization) and how that should be
implemented in the recommendation. That allows Struts2 to consider
implementing the control themselves, or to adopt ESAPI as they see fit.
As per current text.
What's missing in this document
The document is missing quite a lot of security sections:
Error Handling (there is one para near the beginning, but it should be
called out explicitly)
I'd probably leave off malicious code and internal security
verifications as they're more advanced than what is truly necessary
for a framework today, particularly when Struts2 (and most frameworks)
are missing so many key controls.
As it stands, I'd really, really, really recommend AGAINST release
without these sections as it feels less than a third finished right
now. Particularly the access control section that does not tell you
the gaps in Struts2 nor what gaps should be filled. For a gaps
document, that's too huge a gap for this document to be taken
seriously by the Struts2 developers.
On 15/04/2009, at 11:33 PM, McGovern, James F (HTSC, IT) wrote:
> Could you publish on the OWASP site and not use URLs that may be
> offensive to others...
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OWASP-Leaders