[Owasp-leaders] Struts2 security gap analysis

Arshan Dabirsiaghi arshan.dabirsiaghi at aspectsecurity.com
Wed Apr 15 23:54:41 EDT 2009


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.

Arshan

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

> @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 scratch.
>
> 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
> Cryptography
> 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.
>
> thanks,
> Andrew
>
> 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/20090415/dad8d940/attachment-0001.html 


More information about the OWASP-Leaders mailing list