[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:

1. Introduction

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  

3. Recommendations

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.

4. References

As per current text.

What's missing in this document

The document is missing quite a lot of security sections:

Session management
Error Handling (there is one para near the beginning, but it should be  
called out explicitly)
Data Protection
Communications Security
HTTP Security
Security Configuration

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...
URL: https://lists.owasp.org/pipermail/owasp-leaders/attachments/20090416/3390346c/attachment.html 

More information about the OWASP-Leaders mailing list