[Owasp-leaders] Struts2 security gap analysis

Jeff Williams jeff.williams at owasp.org
Thu Apr 16 10:24:21 EDT 2009

This is GREAT work and I'd like to see this type of analysis for every
popular web technology out there.  I tend to agree with Andrew that it's
better to lay out a comprehensive scheme.  I think this can be softened by
saying that missing areas need to be augmented with other libraries or are
simply left up to the developer.  I think using the ASVS as a rough
guideline for the organization is a good idea.





From: owasp-leaders-bounces at lists.owasp.org
[mailto:owasp-leaders-bounces at lists.owasp.org] On Behalf Of Arshan
Sent: Wednesday, April 15, 2009 11:55 PM
To: Andrew van der Stock
Cc: Owasp leaders
Subject: Re: [Owasp-leaders] Struts2 security gap analysis


Thx Andrew - yes, it is missing quite a bit from your perspective which I
suspect may be a common one. Some general thoughts: 


I am afraid I may not be able to completely seperate opinion from fact
because proving one methodology provides more assurance is a non-trivial
task. I will have to think about it. It's not like we have a lot of hard
data in this field.  

There is a bit of a method to the madness as far as the security areas I
covered. I wanted to choose security areas they could easily understand and
wouldn't out of hand reject as part of their charter. However I will revisit
this because I don't want it to seem incomplete. You think short stubs would
be ok? 


As far as moving the appendix entries up, there is simply too much code and
it's very redundant, which is why I put in the "Centralized.." section and
appendices to let readers interested in seeing the code know where they
could find it.


I will take a look at your specific edits and get back to you soon.



On Apr 15, 2009, at 10:21 PM, "Andrew van der Stock" <vanderaj at owasp.org>

@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 recommendations.


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   | Struts2


2.6 Verify that all authentication decisions are logged | Present | Missing


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


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


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/32a637e6/attachment.html 

More information about the OWASP-Leaders mailing list