<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">@James - you've obviously not met Arshan then. He likes offense.&nbsp;:)&nbsp;<div><br></div><div>@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.&nbsp;</div><div><br></div><div>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.&nbsp;</div><div><br></div><div>I suggest the following structure:</div><div><br></div><div>1. Introduction&nbsp;</div><div><br></div><div>Basically the current text</div><div><br></div><div>2. Gap analysis</div><div><br></div><div>A simple table for each chapter, with three columns, one line per row using ASVS Level 2B as the baseline.&nbsp;</div><div><br></div><div><font class="Apple-style-span" face="Courier">Verification &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|&nbsp;ESAPI &nbsp; | Struts2</font></div><div><font class="Apple-style-span" face="Courier">---------------------------------------------------------------------------</font></div><div><font class="Apple-style-span" face="Courier">2.6 Verify that all authentication decisions are logged | Present | Missing</font></div><div><div><br></div><div>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.&nbsp;</div><div><br></div></div><div><b>3. Recommendations</b></div><div><br></div><div>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.&nbsp;</div><div><br></div><div>There should be three choice of recommendation:</div><div><br></div><div>A) Struts2 to&nbsp;document&nbsp;preferred mechanism (i.e. in Logging, this is to use Log4j) in the official documentation</div><div>B) May implement</div><div>C) Should&nbsp;implement</div><div><br></div><div>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.&nbsp;</div><div><br></div><div>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.&nbsp;</div><div><br></div><div><b>4. References</b></div><div><br></div><div>As per current text.</div><div><br></div><div><b>What's missing in this document</b></div><div><br></div><div><div>The document is missing quite a lot of security sections:</div><div><br></div><div>Session management</div><div>Cryptography</div><div>Error Handling (there is one para near the beginning, but it should be called out explicitly)</div><div>Data Protection</div><div>Communications Security</div><div>HTTP Security</div><div>Security Configuration</div><div><br></div><div>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.&nbsp;</div><div><br></div><div>As it stands,&nbsp;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.&nbsp;</div><div><br></div><div>thanks,</div><div>Andrew</div><div><br><div><div>On 15/04/2009, at 11:33 PM, McGovern, James F (HTSC, IT) wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div class="hmmessage" style="font-size: 10pt; font-family: Verdana; "><div dir="ltr" align="left"><span class="171143313-15042009"><font face="Arial" color="#0000ff">Could you publish on the OWASP site and not use URLs that may be offensive to others...</font></span></div></div></span></blockquote></div><br></div></div></body></html>