<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns="http://www.w3.org/TR/REC-html40" xmlns:v = 
"urn:schemas-microsoft-com:vml" xmlns:o = 
"urn:schemas-microsoft-com:office:office" xmlns:w = 
"urn:schemas-microsoft-com:office:word" xmlns:x = 
"urn:schemas-microsoft-com:office:excel" xmlns:p = 
"urn:schemas-microsoft-com:office:powerpoint" xmlns:a = 
"urn:schemas-microsoft-com:office:access" xmlns:dt = 
"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s = 
"uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs = 
"urn:schemas-microsoft-com:rowset" xmlns:z = "#RowsetSchema" xmlns:b = 
"urn:schemas-microsoft-com:office:publisher" xmlns:ss = 
"urn:schemas-microsoft-com:office:spreadsheet" xmlns:c = 
"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc = 
"urn:schemas-microsoft-com:office:odc" xmlns:oa = 
"urn:schemas-microsoft-com:office:activation" xmlns:html = 
"http://www.w3.org/TR/REC-html40" xmlns:q = 
"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc = 
"http://microsoft.com/officenet/conferencing" XMLNS:D = "DAV:" XMLNS:Repl = 
"http://schemas.microsoft.com/repl/" xmlns:mt = 
"http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2 = 
"http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ppda = 
"http://www.passport.com/NameSpace.xsd" xmlns:ois = 
"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir = 
"http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds = 
"http://www.w3.org/2000/09/xmldsig#" xmlns:dsp = 
"http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc = 
"http://schemas.microsoft.com/data/udc" xmlns:xsd = 
"http://www.w3.org/2001/XMLSchema" xmlns:sub = 
"http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec = 
"http://www.w3.org/2001/04/xmlenc#" xmlns:sp = 
"http://schemas.microsoft.com/sharepoint/" xmlns:sps = 
"http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi = 
"http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs = 
"http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf = 
"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p = 
"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf = 
"http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss = 
"http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi = 
"http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi = 
"http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mver = 
"http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m = 
"http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels = 
"http://schemas.openxmlformats.org/package/2006/relationships" xmlns:spwp = 
"http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t = 
"http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m = 
"http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:pptsl = 
"http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl = 
"http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" 
XMLNS:Z = "urn:schemas-microsoft-com:" xmlns:st = ""><HEAD>
<META content="text/html; charset=us-ascii" http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 8.00.6001.18828">
<STYLE>
<!--
 /* Font Definitions */
 @font-face
        {font-family:Wingdings;
        panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
        {font-family:Consolas;
        panose-1:2 11 6 9 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
pre
        {mso-style-priority:99;
        mso-style-link:"HTML Preformatted Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:10.0pt;
        font-family:"Courier New";}
span.HTMLPreformattedChar
        {mso-style-name:"HTML Preformatted Char";
        mso-style-priority:99;
        mso-style-link:"HTML Preformatted";
        font-family:Consolas;}
span.EmailStyle19
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;}
@page Section1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
        {page:Section1;}
 /* List Definitions */
 @list l0
        {mso-list-id:381635263;
        mso-list-template-ids:2013818982;}
@list l0:level1
        {mso-level-number-format:bullet;
        mso-level-text:\F0B7;
        mso-level-tab-stop:.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l1
        {mso-list-id:1105031630;
        mso-list-template-ids:1996151616;}
@list l1:level1
        {mso-level-number-format:bullet;
        mso-level-text:\F0B7;
        mso-level-tab-stop:.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l1:level2
        {mso-level-number-format:bullet;
        mso-level-text:o;
        mso-level-tab-stop:1.0in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:"Courier New";
        mso-bidi-font-family:"Times New Roman";}
@list l2
        {mso-list-id:1510174796;
        mso-list-template-ids:-672859318;}
@list l2:level1
        {mso-level-number-format:bullet;
        mso-level-text:\F0B7;
        mso-level-tab-stop:.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l2:level2
        {mso-level-number-format:bullet;
        mso-level-text:o;
        mso-level-tab-stop:1.0in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:"Courier New";
        mso-bidi-font-family:"Times New Roman";}
@list l3
        {mso-list-id:1777403035;
        mso-list-template-ids:-699772832;}
@list l3:level1
        {mso-level-number-format:bullet;
        mso-level-text:\F0B7;
        mso-level-tab-stop:.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l3:level2
        {mso-level-number-format:bullet;
        mso-level-text:o;
        mso-level-tab-stop:1.0in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:"Courier New";
        mso-bidi-font-family:"Times New Roman";}
@list l4
        {mso-list-id:2008436853;
        mso-list-template-ids:-685354228;}
@list l4:level1
        {mso-level-number-format:bullet;
        mso-level-text:\F0B7;
        mso-level-tab-stop:.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l4:level2
        {mso-level-number-format:bullet;
        mso-level-text:o;
        mso-level-tab-stop:1.0in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:"Courier New";
        mso-bidi-font-family:"Times New Roman";}
@list l5
        {mso-list-id:2074574166;
        mso-list-template-ids:1448664290;}
@list l5:level1
        {mso-level-number-format:bullet;
        mso-level-text:\F0B7;
        mso-level-tab-stop:.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l5:level2
        {mso-level-number-format:bullet;
        mso-level-text:o;
        mso-level-tab-stop:1.0in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:"Courier New";
        mso-bidi-font-family:"Times New Roman";}
ol
        {margin-bottom:0in;}
ul
        {margin-bottom:0in;}
-->
</STYLE>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]--></HEAD>
<BODY lang=EN-US link=blue vLink=purple>
<DIV dir=ltr align=left><SPAN class=006533013-13012010><FONT 
face="Book Antiqua">I'll&nbsp;throw my hat in the ring for your consideration. 
This would be helpful&nbsp;for me&nbsp;to have for&nbsp;the PHP port for 
example. There are places where we're needing to go off-road for 
language-specific reasons, in those circumstances it would be particularly 
helpful to make sure the security checks/effects are normalized based on a 
common spec. </FONT></SPAN></DIV>
<DIV align=left><SPAN class=006533013-13012010><FONT 
face="Book Antiqua"></FONT></SPAN>&nbsp;</DIV>
<DIV align=left><SPAN class=006533013-13012010><FONT 
face="Book Antiqua">Tangential, related to terminology/concepts throughout the 
email chain below, I'd like to continue to draw people's attention to this 
document: <A 
href="http://www.owasp.org/images/8/82/Esapi-design-patterns.pdf">http://www.owasp.org/images/8/82/Esapi-design-patterns.pdf</A></FONT></SPAN></DIV>
<DIV align=left><SPAN class=006533013-13012010><FONT 
face="Book Antiqua"></FONT></SPAN>&nbsp;</DIV>
<DIV align=left><SPAN class=006533013-13012010><FONT face="Book Antiqua">Vote 
Mike. </FONT></SPAN></DIV>
<DIV align=left><SPAN class=006533013-13012010><FONT 
face="Book Antiqua"></FONT></SPAN>&nbsp;</DIV>
<DIV align=left><FONT face="Book Antiqua">Mike&nbsp;<SPAN 
class=760305716-15062009>B.</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV><BR>
<DIV dir=ltr lang=en-us class=OutlookMessageHeader align=left>
<HR tabIndex=-1>
<FONT size=2 face=Tahoma><B>From:</B> esapi-user-bounces@lists.owasp.org 
[mailto:esapi-user-bounces@lists.owasp.org] <B>On Behalf Of </B>Jeff 
Williams<BR><B>Sent:</B> Wednesday, January 13, 2010 12:13 AM<BR><B>To:</B> 
mike.boberski@gmail.com; Dinis Cruz<BR><B>Cc:</B> rob.spremulli+esapi@gmail.com; 
ESAPI-Developers; esapi-user@lists.owasp.org<BR><B>Subject:</B> [Esapi-user] 
ESAPI Technology Compatibility Kit (TCK)<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV class=Section1>
<P class=MsoNormal><SPAN 
style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt">(Pulled 
off of SC-L)<o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN 
style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt"><o:p>&nbsp;</o:p></SPAN></P>
<P class=MsoNormal><SPAN 
style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt">I 
suggest that we should *<B>not</B>* call this the ESTAPI.&nbsp; It&#8217;s confusing 
and inaccurate.&nbsp; As I&#8217;ve mentioned before, I really think the right model 
for this is the Java Technology Compatibility Kit (TCK).&nbsp; <A 
href="http://jcp.org/en/resources/tdk">http://jcp.org/en/resources/tdk</A>.<o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN 
style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt"><o:p>&nbsp;</o:p></SPAN></P>
<P class=MsoNormal><SPAN 
style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt">I 
think separating the interfaces from the concrete classes within the Java 
implementation is a weak attempt to achieve this. The right approach is to 
really write a technology-independent specification and create the rest of the 
TCK.&nbsp; This should be relatively easy since we have several different 
working implementations.&nbsp; Incidentally, writing the spec fairly late in the 
process is the recipe for most successful technologies.<o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN 
style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt"><o:p>&nbsp;</o:p></SPAN></P>
<P class=MsoNormal><SPAN 
style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt">Is 
anyone interested in leading this important effort (with support from the rest 
of the team)?&nbsp; I&#8217;m seeking someone with the right combination of technical, 
managerial, and writing skills to pull this off 
effectively.<o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN 
style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt"><o:p>&nbsp;</o:p></SPAN></P>
<P class=MsoNormal><SPAN 
style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt">--Jeff<o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN 
style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt"><o:p>&nbsp;</o:p></SPAN></P>
<P class=MsoNormal><SPAN 
style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt"><o:p>&nbsp;</o:p></SPAN></P>
<DIV 
style="BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<P class=MsoNormal><B><SPAN 
style="FONT-FAMILY: 'Tahoma','sans-serif'; FONT-SIZE: 10pt">From:</SPAN></B><SPAN 
style="FONT-FAMILY: 'Tahoma','sans-serif'; FONT-SIZE: 10pt"> 
esapi-user-bounces@lists.owasp.org [mailto:esapi-user-bounces@lists.owasp.org] 
<B>On Behalf Of </B>Mike Boberski<BR><B>Sent:</B> Tuesday, January 12, 2010 7:47 
PM<BR><B>To:</B> Dinis Cruz<BR><B>Cc:</B> rob.spremulli+esapi@gmail.com; 
ESAPI-Developers; esapi-user@lists.owasp.org; 
SC-L@securecoding.org<BR><B>Subject:</B> Re: [Esapi-user] [Esapi-dev] 
Recommending ESAPI?<o:p></o:p></SPAN></P></DIV>
<P class=MsoNormal><o:p>&nbsp;</o:p></P>
<P style="MARGIN-BOTTOM: 12pt" class=MsoNormal>&gt; we start to create standards 
for how Security Controls should behave [and basically the rest of the 
post]<BR><BR>I submit ASVS for your consideration. If one is further concerned 
about building blocks in the environment, check out Common Criteria and FIPS 
140-2.<BR><BR>Also,<BR><BR>There have also been discussions about creating 
standardized test suites for ESAPI implementations to ensure consistent security 
checks/effects across ESAPI language implementations, but I don't think that's 
what you're getting at.<BR><BR>It's not hard (with respect) to differentiate 
interfaces from reference implementations from adapters (customized controls), 
please see the design patterns doc I wrote that's posted to the project page. 
I'm not sure I see advantages to further rearranging and splitting out the 
interfaces.<BR><BR>Best,<BR><BR clear=all>Mike<BR><BR><o:p></o:p></P>
<DIV>
<P class=MsoNormal>On Tue, Jan 12, 2010 at 7:38 PM, Dinis Cruz &lt;<A 
href="mailto:dinis.cruz@googlemail.com">dinis.cruz@googlemail.com</A>&gt; 
wrote:<o:p></o:p></P>
<P class=MsoNormal>My view is that the key to make this work is to create the 
ESTAPI, which is the Enterprise Security <B>Testing</B> API<o:p></o:p></P>
<DIV>
<P class=MsoNormal><o:p>&nbsp;</o:p></P></DIV>
<DIV>
<P class=MsoNormal>This way we would have (for every 
language):<o:p></o:p></P></DIV>
<DIV>
<UL type=disc>
  <LI 
  style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto; mso-list: l0 level1 lfo1" 
  class=MsoNormal><B>ESAPI Interfaces</B> - which describe the functionality 
  that each security control should have<o:p></o:p> 
  <LI 
  style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto; mso-list: l0 level1 lfo1" 
  class=MsoNormal><B>ESTAPI</B> - Unit Tests that check the behaviour of the 
  security controls<o:p></o:p> 
  <LI 
  style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto; mso-list: l0 level1 lfo1" 
  class=MsoNormal><B>ESAPI Reference Implementation(s) </B>- Which are 
  (wherever&nbsp;possible) 'production ready' versions of those security 
  controls (and &nbsp;in most cases a one-to-one mapping to the&nbsp;ESAPI 
  Interfaces)<o:p></o:p> 
  <LI 
  style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto; mso-list: l0 level1 lfo1" 
  class=MsoNormal><B>Framework XYZ ESAPI 'connectors'</B> - Which wrap (or 
  expose) the security controls defined in the ESAPI Interfaces in Framework 
  XYZ<o:p></o:p> </LI></UL>
<DIV>
<P class=MsoNormal>What I really like about this world, is that we (Application 
Security Consultants)&nbsp;we start to create standards for how Security 
Controls should behave. and&nbsp;(as important)&nbsp;are able to work with the 
Framework developers without they felling that ESAPI is a 'competitor' to they 
Framework. After all, the way we will really change the market is when the 
Frameworks used by the majority of developers adopt ESAPI (or its 
principles)<o:p></o:p></P></DIV>
<DIV>
<P class=MsoNormal><o:p>&nbsp;</o:p></P></DIV>
<DIV>
<P class=MsoNormal>Of course that the Framework developers are more than 
welcomed to grab large parts (or even all) of the code provided by the ESAPI 
reference implementation(s). But the key is that they (the framework developers) 
must: a) take ownership of the code and b) respect the ESAPI 
Interfaces.<o:p></o:p></P></DIV>
<DIV>
<P class=MsoNormal><o:p>&nbsp;</o:p></P></DIV>
<DIV>
<P class=MsoNormal>And hey, if the Framework developers decide NOT to implement 
a particular security control, that is fine too.&nbsp;<o:p></o:p></P></DIV>
<DIV>
<P class=MsoNormal><o:p>&nbsp;</o:p></P></DIV>
<DIV>
<P class=MsoNormal>BUT!&nbsp;<o:p></o:p></P></DIV>
<DIV>
<P class=MsoNormal><o:p>&nbsp;</o:p></P></DIV>
<DIV>
<P class=MsoNormal>I would at least expect them to provide detailed information 
why they made that decision and why they chose NOT to implement or support it 
(which would allow us (Security community) to respectably agree or disagree with 
their choices (hey for some Frameworks, being insecure is a feature :) 
)<o:p></o:p></P></DIV>
<DIV>
<P class=MsoNormal><o:p>&nbsp;</o:p></P></DIV>
<DIV>
<P class=MsoNormal>Finally, In addition to all the advantages that we will have 
when frameworks adopt these security controls, there is one that for me is 
probably the MOST important one: <B>An 'ESAPI compliant app'</B> (which btw is a 
term we still have to agree what exactly means),<B> is an app that is providing 
explicit information about where they (the developers) think their (the app) 
security controls are located</B>.<o:p></o:p></P></DIV>
<DIV>
<P class=MsoNormal><o:p>&nbsp;</o:p></P></DIV>
<DIV>
<P class=MsoNormal>In another works, via the ESAPI Interfaces (and the ESTAPI 
tests) the developers are actually telling us (the security 
consultants):&nbsp;<o:p></o:p></P></DIV>
<DIV>
<P class=MsoNormal>&nbsp;&nbsp;a) what they think their application's attack 
surface is and &nbsp;<o:p></o:p></P></DIV>
<DIV>
<P class=MsoNormal>&nbsp;&nbsp;b) what is the security behaviour that they have 
already tested for<o:p></o:p></P></DIV>
<DIV>
<P class=MsoNormal><o:p>&nbsp;</o:p></P></DIV>
<DIV>
<P class=MsoNormal>Of course that they can game the system, which is why we 
(Security Consultants) will still be needed (we will also need to make sure that 
they implemented the security controls properly). But compare that to today's 
(2009) world, were we are lucky to get an up-to-date application diagram and 
a&nbsp;reasonable&nbsp;accurate&nbsp;description of how the application was 
actually coded and behaves.&nbsp;<o:p></o:p></P></DIV>
<DIV>
<P class=MsoNormal><o:p>&nbsp;</o:p></P></DIV>
<DIV>
<P class=MsoNormal>This would also (finally) give the application security tools 
(white, black, glass, gray, pink, blue) a&nbsp;fighting&nbsp;change to 
automatically, or operator-driven, understand what is going on and report 
back:&nbsp;<o:p></o:p></P></DIV>
<DIV>
<P class=MsoNormal>&nbsp;&nbsp;- what it knows (security vulnerabilities) and 
(as important)&nbsp;<o:p></o:p></P></DIV>
<DIV>
<P class=MsoNormal>&nbsp;&nbsp;- what it doesn't know / understand <BR>(ok there 
is a lot more that these tools will provide us (for example ESTAPI tests) but 
that is a topic for another post)<o:p></o:p></P></DIV>
<DIV>
<P class=MsoNormal><o:p>&nbsp;</o:p></P></DIV>
<DIV>
<P class=MsoNormal>So, for me, the key added value of the ESAPI Interfaces, is 
that it will provide us (Security Consultants) a way to understand how the app 
works (from a security point of view) and to be able to finally be able to give 
the clients what they want: Visibility, Assurance and the ability to make 
'knowledgeable Risk-based decisions'.<o:p></o:p></P></DIV>
<DIV>
<P class=MsoNormal><o:p>&nbsp;</o:p></P></DIV>
<DIV>
<P class=MsoNormal>Dinis Cruz<o:p></o:p></P></DIV>
<P class=MsoNormal><o:p>&nbsp;</o:p></P>
<DIV>
<P class=MsoNormal>2010/1/12 Jim Manico &lt;<A 
href="mailto:jim.manico@owasp.org" 
target=_blank>jim.manico@owasp.org</A>&gt;<o:p></o:p></P>
<DIV>
<P class=MsoNormal>Very well said.<BR><BR>On this note, I think we may wish to 
consider formally splitting the interfaces from the reference implementation. We 
could then build a test framework that's tests those interfaces - so we can 
verify different implementations of ESAPI. Expand this out in a cross-language 
way, and we have some serious magic to work with.<BR><BR>This is Dinis' idea, 
but I'm starting to see the light.<BR><SPAN style="COLOR: #888888"><BR>- 
Jim</SPAN><o:p></o:p></P>
<DIV>
<DIV>
<P class=MsoNormal><BR><BR><BR><BR>&nbsp;<BR><BR><o:p></o:p></P>
<DIV>
<P class=MsoNormal>An FYI from personal experience, be extra careful with the 
dependencies, particularly if you develop on an appserver that optimized for 
debug and production.<o:p></o:p></P></DIV>
<DIV>
<P class=MsoNormal>&nbsp;<o:p></o:p></P></DIV>
<DIV>
<P class=MsoNormal>You may need these libraries even if you are not using the 
area of the ESAPI RI that uses them.&nbsp; The -Xverify:none JVM argument 
changes how the classloader pre-caches some classes, particularly 
Exceptions.&nbsp; Despite not needing to use safe file upload capabilities, 
without that JVM arg is was looking for Exceptions found in the commons-uploads 
jar<o:p></o:p></P></DIV>
<DIV>
<P class=MsoNormal>&nbsp;<o:p></o:p></P></DIV>
<DIV>
<P class=MsoNormal><BR>&nbsp;<o:p></o:p></P></DIV>
<DIV>
<P class=MsoNormal>On Tue, Jan 12, 2010 at 6:54 AM, Jim Manico &lt;<A 
href="mailto:jim.manico@owasp.org" target=_blank>jim.manico@owasp.org</A>&gt; 
wrote:<o:p></o:p></P>
<DIV>
<P class=MsoNormal>You know Dinis, when I first read your email I was bit 
offended. Same with much of John Stevens' email. <o:p></o:p></P>
<DIV>
<P style="MARGIN-BOTTOM: 12pt" class=MsoNormal><BR>But you know? You are trying 
to help us. These kinds of pragmatic questions need to be answered.<BR><BR>So 
here goes.<o:p></o:p></P></DIV>
<DIV>
<BLOCKQUOTE style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">
  <DIV>
  <P class=MsoNormal><SPAN 
  style="FONT-FAMILY: 'Arial','sans-serif'; FONT-SIZE: 8pt">Following the recent 
  thread on Java 6 security and ESAPI,&nbsp;I just would like to ask the 
  following clarifications:&nbsp;<o:p></o:p></SPAN></P></DIV>
  <DIV>
  <P class=MsoNormal><SPAN 
  style="FONT-FAMILY: 'Arial','sans-serif'; FONT-SIZE: 8pt"><o:p>&nbsp;</o:p></SPAN></P></DIV>
  <DIV>
  <P class=MsoNormal><SPAN 
  style="FONT-FAMILY: 'Arial','sans-serif'; FONT-SIZE: 8pt">1) For an existing 
  web application currently using a MVC framework (like Spring or Struts) are we 
  today (9th Jan 2009) officially recommending&nbsp;that this web application 
  development team adds OWASP's ESAPI.jar to the list of 'external' APIs (i.e. 
  libs) they use, support and maintain?<o:p></o:p></SPAN></P></DIV></BLOCKQUOTE>
<P class=MsoNormal><o:p>&nbsp;</o:p></P></DIV>
<DIV>
<P style="MARGIN-BOTTOM: 12pt" class=MsoNormal>I can personally attest for ESAPI 
2.0 rc4 integration into Struts 1.3.x, where I've used ESAPI for several years, 
from the early days. I'm not deeply familiar with Spring. I would not say this 
is a trivial exercise, but it certainly is possible. <o:p></o:p></P></DIV>
<BLOCKQUOTE style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">
  <DIV>
  <P class=MsoNormal><SPAN 
  style="FONT-FAMILY: 'Arial','sans-serif'; FONT-SIZE: 8pt"><o:p>&nbsp;</o:p></SPAN></P></DIV>
  <DIV>
  <DIV>
  <P class=MsoNormal><SPAN 
  style="FONT-FAMILY: 'Arial','sans-serif'; FONT-SIZE: 8pt">2) When adopting the 
  OWASP ESAPI's J2EE implementation, is ESAPI.jar ALL they need to add? or are 
  there other dependencies (i.e. jars) that also need</SPAN><SPAN 
  style="FONT-FAMILY: 'Arial','sans-serif'">&nbsp;to be added, supported and 
  maintained? (for example on the '<B>Dependencies</B>' section of 
  the&nbsp;</SPAN><SPAN 
  style="FONT-FAMILY: 'Arial','sans-serif'; FONT-SIZE: 8pt"><A 
  href="http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API#tab=Java_EE" 
  target=_blank><SPAN style="COLOR: #2a5db0; FONT-SIZE: 12pt">ESAPI Java 
  EE</SPAN></A></SPAN><SPAN style="FONT-FAMILY: 'Arial','sans-serif'">&nbsp;page 
  (i.e. Tab) it seems to imply that there are other *.jars needed)</SPAN><SPAN 
  style="FONT-FAMILY: 'Arial','sans-serif'; FONT-SIZE: 8pt"><o:p></o:p></SPAN></P></DIV></DIV></BLOCKQUOTE>
<P class=MsoNormal><o:p>&nbsp;</o:p></P>
<DIV>
<P style="MARGIN-BOTTOM: 12pt" class=MsoNormal>ESAPI.jar has significant 
dependencies - something that is a problem, in general, in the Java world. I'm 
optimistic about the new Java 7 component framework - but that is a long way 
off.&nbsp; In the meantime:<o:p></o:p></P></DIV>
<P class=MsoNormal>(from <A 
href="http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API#tab=Java_EE" 
target=_blank>http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API#tab=Java_EE</A>) 
<o:p></o:p></P>
<DIV>
<P class=MsoNormal><BR><BR><I>There are no dependencies on the ESAPI 
<B>interfaces</B> other than standard Java EE. However, the reference 
implementation does have dependencies that are detailed below. The reference 
implementation takes advantage of a few existing libraries. <B><U>This list may 
not be totally complete.</U></B>&nbsp;</I> <o:p></o:p></P></DIV>
<UL type=disc>
  <LI 
  style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto; mso-list: l3 level1 lfo2" 
  class=MsoNormal><I>DefaultAccessController needs&#8230; </I><o:p></o:p></LI></UL>
<UL type=disc>
  <UL type=circle>
    <LI 
    style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto; mso-list: l3 level2 lfo2" 
    class=MsoNormal><I>Commons-Configuration 1.5 </I><o:p></o:p></LI></UL></UL>
<UL type=disc>
  <LI 
  style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto; mso-list: l4 level1 lfo3" 
  class=MsoNormal><I>DefaultValidator needs&#8230; </I><o:p></o:p></LI></UL>
<DIV>
<UL type=disc>
  <UL type=circle>
    <LI 
    style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto; mso-list: l4 level2 lfo3" 
    class=MsoNormal><I>AntiSamy 1.2 (there may be a few transitive dependencies 
    here) </I><o:p></o:p></LI></UL></UL></DIV>
<UL type=disc>
  <UL type=circle>
    <LI 
    style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto; mso-list: l4 level2 lfo3" 
    class=MsoNormal><I>NekoHTML 0.9.5 </I><o:p></o:p>
    <LI 
    style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto; mso-list: l4 level2 lfo3" 
    class=MsoNormal><I>Xerces 2.9.1 </I><o:p></o:p></LI></UL></UL>
<UL type=disc>
  <LI 
  style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto; mso-list: l2 level1 lfo4" 
  class=MsoNormal><I>Log4J Logger needs&#8230; </I><o:p></o:p></LI></UL>
<UL type=disc>
  <UL type=circle>
    <LI 
    style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto; mso-list: l2 level2 lfo4" 
    class=MsoNormal><I>Log4j 1.2.12 </I><o:p></o:p></LI></UL></UL>
<UL type=disc>
  <LI 
  style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto; mso-list: l5 level1 lfo5" 
  class=MsoNormal><I>DefaultHTTPUtilities needs&#8230; </I><o:p></o:p></LI></UL>
<UL type=disc>
  <UL type=circle>
    <LI 
    style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto; mso-list: l5 level2 lfo5" 
    class=MsoNormal><I>Commons-FileUpload 1.2 </I><o:p></o:p></LI></UL></UL>
<UL type=disc>
  <LI 
  style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto; mso-list: l1 level1 lfo6" 
  class=MsoNormal><I>WAF needs </I><o:p></o:p></LI></UL>
<DIV>
<UL type=disc>
  <UL type=circle>
    <LI 
    style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto; mso-list: l1 level2 lfo6" 
    class=MsoNormal><I>XOM 1.0 (there may be a few transitive dependencies here) 
    </I><o:p></o:p></LI></UL></UL></DIV>
<UL type=disc>
  <UL type=circle>
    <LI 
    style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto; mso-list: l1 level2 lfo6" 
    class=MsoNormal><I>Commons-FileUpload 1.2 </I><o:p></o:p></LI></UL></UL>
<DIV>
<P class=MsoNormal><BR><BR><o:p></o:p></P>
<DIV>
<P class=MsoNormal><SPAN 
style="FONT-FAMILY: 'Arial','sans-serif'; FONT-SIZE: 8pt"><o:p>&nbsp;</o:p></SPAN></P></DIV>
<DIV>
<P class=MsoNormal><SPAN style="FONT-FAMILY: 'Arial','sans-serif'">3) Where can 
I find detailed information about each of the 9 Security Controls that ESAPI.jar 
currently supports: 1) Authentication, 2)&nbsp;Access control, 3) Input 
validation, 4) Output encoding/escaping, 5) Cryptography, 6) Error handling and 
logging, 7) Communication security, 8) HTTP security and 9) Security 
configuration? (I took this list of controls from the&nbsp;<A 
href="http://www.owasp.org/images/8/81/Esapi-datasheet.pdf" 
target=_blank>Introduction to ESAPI pdf)</A></SPAN><SPAN 
style="FONT-FAMILY: 'Arial','sans-serif'; FONT-SIZE: 8pt"><o:p></o:p></SPAN></P></DIV>
<P class=MsoNormal><o:p>&nbsp;</o:p></P></DIV>
<DIV>
<P style="MARGIN-BOTTOM: 12pt" class=MsoNormal>Detailed from a marketing 
perspective? :) The best technical information is our Javadoc pages at <A 
href="http://owasp-esapi-java.googlecode.com/svn/trunk_doc/2.0-rc4/index.html" 
target=_blank>http://owasp-esapi-java.googlecode.com/svn/trunk_doc/2.0-rc4/index.html</A> 
which are not complete, but are fairly decent. We have also been very good about 
answering questions, fast, on esapi-users and esapi-dev. But you are right - 
docs are evolving, but we need more. <o:p></o:p></P></DIV>
<DIV>
<BLOCKQUOTE style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">
  <DIV>
  <P class=MsoNormal><SPAN style="FONT-FAMILY: 'Arial','sans-serif'">4) When 
  adopting EASPI.jar, are we recommending that the developers should adopt or 
  retrofit their existing code on the areas affected by those 9 Security 
  Controls? (i.e. code related to: Authentication,&nbsp;Access 
  control,&nbsp;Input validation,&nbsp;Output encoding/escaping, Cryptography, 
  Error handling and logging, Communication security, HTTP security and Security 
  configuration) </SPAN><SPAN 
  style="FONT-FAMILY: 'Arial','sans-serif'; FONT-SIZE: 8pt"><o:p></o:p></SPAN></P></DIV></BLOCKQUOTE></DIV>
<DIV>
<P class=MsoNormal>It really depends on the situation. But I get your point - 
I've seen the Validator, Encoder, Utils and Error Handling modules used in 
retrofitting situations successfully. I'm not so sure about the 
others.<o:p></o:p></P></DIV>
<BLOCKQUOTE style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">
  <DIV>
  <P class=MsoNormal><SPAN 
  style="FONT-FAMILY: 'Arial','sans-serif'; FONT-SIZE: 8pt"><o:p>&nbsp;</o:p></SPAN></P></DIV>
  <DIV>
  <DIV>
  <P class=MsoNormal><SPAN style="FONT-FAMILY: 'Arial','sans-serif'">5) Should 
  we recommend the adoption of ALL 9 Security Controls? or are there some 
  controls that are not ready today (9 Jan 2009) for production environments and 
  should not be&nbsp;recommended? (for example is the 'Authentication' control 
  as mature as the 'Error handling and logging' control?)</SPAN><SPAN 
  style="FONT-FAMILY: 'Arial','sans-serif'; FONT-SIZE: 8pt"><o:p></o:p></SPAN></P></DIV></DIV></BLOCKQUOTE>
<P style="MARGIN-BOTTOM: 12pt" class=MsoNormal>I personally grade the reference 
2.0 implementation as follows:<SPAN 
style="FONT-FAMILY: 'Arial','sans-serif'"><o:p></o:p></SPAN></P>
<DIV>
<P class=MsoNormal><SPAN style="FONT-FAMILY: 'Arial','sans-serif'">1) 
Authentication&nbsp;&nbsp; C (Needs deeper enterprise 
integration)<BR>2)&nbsp;Access control&nbsp;&nbsp; B- (This is just a really 
tough issue, and usually requires deep application-specific context. Plus we 
have some good ideas on the table from Beef that I'd like to consider)<BR>3) 
Input validation&nbsp;&nbsp; A- (needs better messaging and internationalization 
(thanks Sklarew for making us think in the right direction about this)<BR>4) 
Output encoding/escaping&nbsp;&nbsp; A (Go Jeff, my only A. :) We do need a 
performance tuning pass (easy) and DOM XSS encoding functions)<BR>5) 
Cryptography&nbsp; A- (Great work Kevin, this is a huge huge improvement from 
1.4)<o:p></o:p></SPAN></P></DIV>
<P class=MsoNormal><SPAN style="FONT-FAMILY: 'Arial','sans-serif'">6) Error 
handling and logging&nbsp; B+ (Nice work on designing this from Wichers)<BR>7) 
Communication security ? <o:p></o:p></SPAN></P>
<DIV>
<P style="MARGIN-BOTTOM: 12pt" class=MsoNormal><SPAN 
style="FONT-FAMILY: 'Arial','sans-serif'">8) HTTP security B- (Great utilities! 
I'd like to see some of these decoupled a bit more)<BR>9) Security configuration 
?<BR><BR>Digging deeper....<o:p></o:p></SPAN></P></DIV>
<P class=MsoNormal>I personally use almost all of ESAPI. I've written my own 
Hibernate Authentication layer - but it's very specific to my data model. It's 
very difficult to decouple this from my app and would be difficult to donate it 
to the project effectively. Same with access control. My data model is VERY 
complex, and donating it without SQL scripts, hibernate configuration, and a 
whole lot of other code - is a great challenge. (Not to mention that my employer 
owns the code ;) The flat-file authenticator is just a proof of concept and 
should never be used in a production environment of any kind, IMO. The 
thread-local nature of the authenticator, while I use it and love it, needs to 
be reconsidered since other classes, like the loggers, depend on it. Error 
handling is fairly solid - and is only a thin layer on top of known logging 
methods + security specific messaging. The encoder was handed down from Gosling 
himself - given to Jeff - who gifted it to us. :) I want the encoder to be a 
hard-coded part of ESAPI. :) The validator and encoder can be dropped into any 
project fairly easy. Same with much of the HTTP Utils. The Encryptor from 1.4 
should be avoided, which impacts other portions of the codebase. <A 
href="http://owasp-esapi-java.googlecode.com/svn/trunk/documentation/esapi4java-core-2.0-readme-crypto-changes.html" 
target=_blank>http://owasp-esapi-java.googlecode.com/svn/trunk/documentation/esapi4java-core-2.0-readme-crypto-changes.html</A>&nbsp; 
. 2.0 is going to be a very big milestone; I'm pretty stoked about what I'm 
seeing from the team. <o:p></o:p></P>
<DIV>
<P style="MARGIN-BOTTOM: 12pt" class=MsoNormal><BR><BR>Most importantly, it's 
easy to use the ESAPI configuration layer to over-ride any of the reference 
implementation with your personal authenticator or access controller (so long as 
you implement the ESAPI interfaces), as I have for my projects. 
<o:p></o:p></P></DIV>
<BLOCKQUOTE style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">
  <DIV>
  <P class=MsoNormal><SPAN 
  style="FONT-FAMILY: 'Arial','sans-serif'; FONT-SIZE: 8pt"><o:p>&nbsp;</o:p></SPAN></P></DIV>
  <DIV>
  <DIV>
  <P class=MsoNormal><SPAN style="FONT-FAMILY: 'Arial','sans-serif'">6) Are 
  there commercial (i.e.&nbsp;paid)&nbsp;support services available for the 
  companies who want to add ESAPI.jar to they application?</SPAN><SPAN 
  style="FONT-FAMILY: 'Arial','sans-serif'; FONT-SIZE: 8pt"><o:p></o:p></SPAN></P></DIV></DIV></BLOCKQUOTE>
<P class=MsoNormal><o:p>&nbsp;</o:p></P>
<DIV>
<P class=MsoNormal>I hesitate to mention this, and I'm not trying to pimp - but 
I'm respectfully answering all of your questions. Aspect offers these services. 
I've been working with Jeff on some of those efforts. It's working out well for 
Aspects clients, I'd dare say. If someone else wishes to speak up on this topic, 
please do. Open.<o:p></o:p></P></DIV>
<BLOCKQUOTE style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">
  <DIV>
  <P class=MsoNormal><SPAN 
  style="FONT-FAMILY: 'Arial','sans-serif'; FONT-SIZE: 8pt"><o:p>&nbsp;</o:p></SPAN></P></DIV>
  <DIV>
  <DIV>
  <P class=MsoNormal><SPAN style="FONT-FAMILY: 'Arial','sans-serif'">7) What is 
  the version of ESAPI.jar that we should recommend? the version 1.4 (which 
  lo</SPAN><SPAN style="FONT-FAMILY: 'Arial','sans-serif'; FONT-SIZE: 8pt">oks 
  like a stable release) or the version 2.0 rc4 (which looks like it is a 
  Release Candidate)<o:p></o:p></SPAN></P></DIV></DIV></BLOCKQUOTE>
<P class=MsoNormal>ESAPI 1.4.1 is <B>very </B>far behind 2.0 rc4.&nbsp; Java 4 
is way past end of lifecycle - but it's still in very wide use, so we plan to 
back-port all of ESAPI 2.0 to 1.4. Or at least as much as we can. I'm making 
some changes this week and plan on releasing 1.4.2 this 
week.<BR><BR><o:p></o:p></P>
<DIV>
<P class=MsoNormal><SPAN 
style="FONT-FAMILY: 'Arial','sans-serif'; FONT-SIZE: 8pt"><o:p>&nbsp;</o:p></SPAN></P></DIV>
<DIV>
<DIV>
<P class=MsoNormal><SPAN 
style="FONT-FAMILY: 'Arial','sans-serif'; FONT-SIZE: 8pt">8) Where can I find 
the documentation of where and how ESAPI should be used? More importantly, where 
can I find the information of how it CAN NOT or SHOULD NOT be used (i.e. the 
cases where even when the EASPI.jar are used, the application is still 
vulnerable)<o:p></o:p></SPAN></P></DIV></DIV>
<P class=MsoNormal>Yea, Docs. We need more docs. Boberski has done incredible 
work in this area.<BR><BR><o:p></o:p></P>
<DIV>
<P class=MsoNormal><SPAN 
style="FONT-FAMILY: 'Arial','sans-serif'; FONT-SIZE: 8pt"><o:p>&nbsp;</o:p></SPAN></P></DIV>
<DIV>
<DIV>
<P class=MsoNormal><SPAN 
style="FONT-FAMILY: 'Arial','sans-serif'; FONT-SIZE: 8pt">9) if there list of 
companies that have currently added ESAPI.jar to their applications and have 
deployed it? (i.e. real world usage of EASPI)<o:p></o:p></SPAN></P></DIV></DIV>
<P class=MsoNormal>Under "users and adopters" <A 
href="http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API#tab=Contributors.2FUsers" 
target=_blank>http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API#tab=Contributors.2FUsers</A> 
<o:p></o:p></P>
<DIV>
<P class=MsoNormal><BR><BR><o:p></o:p></P>
<DIV>
<P class=MsoNormal><SPAN 
style="FONT-FAMILY: 'Arial','sans-serif'; FONT-SIZE: 8pt"><o:p>&nbsp;</o:p></SPAN></P></DIV>
<DIV>
<P class=MsoNormal><SPAN 
style="FONT-FAMILY: 'Arial','sans-serif'; FONT-SIZE: 8pt">10) Has the 
recommended ESAPI.jar (1.4 or 2.0 rc4) been through a security review? and if so 
where can I read its report?<o:p></o:p></SPAN></P></DIV></DIV>
<P class=MsoNormal>Yes and see #8 sentence 2.<BR><BR><o:p></o:p></P>
<DIV>
<P class=MsoNormal><SPAN 
style="FONT-FAMILY: 'Arial','sans-serif'; FONT-SIZE: 8pt"><o:p>&nbsp;</o:p></SPAN></P></DIV>
<DIV>
<DIV>
<P class=MsoNormal><SPAN 
style="FONT-FAMILY: 'Arial','sans-serif'; FONT-SIZE: 8pt">11)&nbsp;when Jim 
says&nbsp;<I>"...&nbsp;you can build a new secure app without an ESAPI. But libs 
like OWASP ESAPI will get you there faster and 
cheaper....",&nbsp;<B>&nbsp;</B></I>do we have peer-reviewed data that suports 
this claim? <o:p></o:p></SPAN></P></DIV></DIV>
<DIV>
<P class=MsoNormal>Nope. I'm shooting from the hip and I consider this as common 
sense. But I agree, we REALLY need more assurance evidence that is published on 
the wiki - perhaps we should run o2 against the ESAPI codebase for starters. Or 
maybe someone can donate code review services and publish that report on our 
wiki. I hear you. Assurance, published assurance, is fundamental. 
<o:p></o:p></P></DIV>
<BLOCKQUOTE style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">
  <DIV>
  <P class=MsoNormal><SPAN 
  style="FONT-FAMILY: 'Arial','sans-serif'; FONT-SIZE: 8pt"><o:p>&nbsp;</o:p></SPAN></P></DIV>
  <DIV>
  <DIV>
  <P class=MsoNormal><SPAN 
  style="FONT-FAMILY: 'Arial','sans-serif'; FONT-SIZE: 8pt">12) Is there a 
  roadmap or how-to for companies that wish to adopt ESAPI.jar on an a) new 
  application or b) existing real-world 
  application'?<o:p></o:p></SPAN></P></DIV></DIV></BLOCKQUOTE>
<P class=MsoNormal>See #8 sentence 2. <o:p></o:p></P>
<DIV>
<BLOCKQUOTE style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">
  <DIV>
  <P class=MsoNormal><SPAN 
  style="FONT-FAMILY: 'Arial','sans-serif'; FONT-SIZE: 8pt"><o:p>&nbsp;</o:p></SPAN></P></DIV>
  <DIV>
  <P class=MsoNormal><SPAN 
  style="FONT-FAMILY: 'Arial','sans-serif'; FONT-SIZE: 8pt">13) What about the 
  current&nbsp;implementations&nbsp;of ESAPI for the other languages. Are we 
  also&nbsp;recommending&nbsp;their 
use?<o:p></o:p></SPAN></P></DIV></BLOCKQUOTE></DIV>
<P class=MsoNormal>Most are beta or alpha - with sparkles of 1.0. But I'd love 
to hear the other language leaders chime in here. I focus on the Java version of 
ESAPI. <o:p></o:p></P>
<DIV>
<P class=MsoNormal><BR><BR><o:p></o:p></P>
<DIV>
<P class=MsoNormal><SPAN 
style="FONT-FAMILY: 'Arial','sans-serif'; FONT-SIZE: 8pt"><o:p>&nbsp;</o:p></SPAN></P></DIV>
<DIV>
<P class=MsoNormal><SPAN 
style="FONT-FAMILY: 'Arial','sans-serif'; FONT-SIZE: 8pt">14) If a development 
team decides to use (for example) Spring and ESAPI together in their (new or 
existing) application, what are the&nbsp;recommended 'parts' from each of those 
APIs (Spring and EASPI) that the developers should be using? (for example: a) 
use Encoding from ESAPI, b) use Authentication from Spring, c) 
use&nbsp;Authorization&nbsp;from ESAPI, d) use Error Handling from Spring, e) 
use Logging from ESAPI, etc...)<o:p></o:p></SPAN></P></DIV>
<P class=MsoNormal><o:p>&nbsp;</o:p></P></DIV>
<P class=MsoNormal>I just don't know how to answer this question. I think for 
starters, the completeness of our encoder helps stop XSS cold in a way that is a 
bit better than the frameworks. And Jeff authorer a great cheat sheet to go 
alongside it. <A 
href="http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet" 
target=_blank>http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet</A> 
<BR><BR><o:p></o:p></P>
<DIV>
<P class=MsoNormal><SPAN 
style="FONT-FAMILY: 'Arial','sans-serif'; FONT-SIZE: 8pt"><o:p>&nbsp;</o:p></SPAN></P></DIV>
<DIV>
<P class=MsoNormal><SPAN 
style="FONT-FAMILY: 'Arial','sans-serif'; FONT-SIZE: 8pt">Thanks<o:p></o:p></SPAN></P></DIV>
<DIV>
<P class=MsoNormal><SPAN 
style="FONT-FAMILY: 'Arial','sans-serif'; FONT-SIZE: 8pt"><o:p>&nbsp;</o:p></SPAN></P></DIV>
<DIV>
<P class=MsoNormal><SPAN 
style="FONT-FAMILY: 'Arial','sans-serif'; FONT-SIZE: 8pt">Dinis 
Cruz<o:p></o:p></SPAN></P></DIV>
<P class=MsoNormal><o:p>&nbsp;</o:p></P>
<DIV>
<P class=MsoNormal>I'm not going to shy away from these emails any longer. Is 
this all you got, Dinis? John Steven? Bring it on, I'll do my best to answer as 
honestly as I can.<BR><BR>But let me tell you, Dinis. I would not consider 
building any Java app without ESAPI. :) (please note the "I" statement - I've 
been deep in the code for years, I'm not saying its easy - it requires 
significant investment of time to use all of ESAPI as it stands 
today).<BR><BR>Another 18 hour day - I need sleep. :)<BR><BR>Regards,<BR>- 
Jim<o:p></o:p></P></DIV></DIV>
<P style="MARGIN-BOTTOM: 12pt" 
class=MsoNormal><BR>_______________________________________________<BR>Esapi-dev 
mailing list<BR><A href="mailto:Esapi-dev@lists.owasp.org" 
target=_blank>Esapi-dev@lists.owasp.org</A><BR><A 
href="https://lists.owasp.org/mailman/listinfo/esapi-dev" 
target=_blank>https://lists.owasp.org/mailman/listinfo/esapi-dev</A><o:p></o:p></P></DIV>
<P class=MsoNormal><o:p>&nbsp;</o:p></P>
<P style="MARGIN-BOTTOM: 12pt" class=MsoNormal><o:p>&nbsp;</o:p></P></DIV></DIV>
<DIV><PRE>-- <o:p></o:p></PRE><PRE>Jim Manico<o:p></o:p></PRE><PRE>OWASP Podcast Host/Producer<o:p></o:p></PRE><PRE><A href="http://www.manico.net" target=_blank>http://www.manico.net</A><o:p></o:p></PRE></DIV></DIV></DIV>
<P class=MsoNormal><o:p>&nbsp;</o:p></P></DIV>
<P style="MARGIN-BOTTOM: 12pt" 
class=MsoNormal><BR>_______________________________________________<BR>Esapi-user 
mailing list<BR><A 
href="mailto:Esapi-user@lists.owasp.org">Esapi-user@lists.owasp.org</A><BR><A 
href="https://lists.owasp.org/mailman/listinfo/esapi-user" 
target=_blank>https://lists.owasp.org/mailman/listinfo/esapi-user</A><o:p></o:p></P></DIV>
<P class=MsoNormal><o:p>&nbsp;</o:p></P></DIV></BODY></HTML>