[Esapi-user] [Owasp-leaders] [Esapi-dev] Crypto attack and OWASP

Boberski, Michael [USA] boberski_michael at bah.com
Mon May 3 13:19:06 EDT 2010

Groovy. Here you go: http://code.google.com/p/owasp-esapi-java/wiki/esapi4java_v2_Appendix_Reporting_bugs

I could use a hand if you'd like to take a first crack at it, using your samples. Or, I can do so. The goal of the current ESAPI "documentation sprint" is to collect stuff up and write stuff down!

Also, for folks clicking through the TOC on the above page, I sure could use a hand filling out the code samples in the "Sample usage" pages here: http://code.google.com/p/owasp-esapi-java/wiki/esapi4java_v2_Sample_usage  If interested, please email the ESAPI developer's list.


Mike B.

From: esapi-user-bounces at lists.owasp.org [mailto:esapi-user-bounces at lists.owasp.org] On Behalf Of Chris Schmidt
Sent: Monday, May 03, 2010 12:54 PM
To: Michael Coates
Cc: ESAPI-Developers; owasp-leaders at lists.owasp.org; ESAPI-Users
Subject: Re: [Esapi-user] [Owasp-leaders] [Esapi-dev] Crypto attack and OWASP

That was the main point that I was trying to get across as well Michael. While notification lists are important, having the process documented is *very* important.

Examples we can go off of:

Summary of what I think we need:

1. Any issues tagged with Security in Issue Tracker should be hidden to non-commiters (if possible)
2. A certificate available for download to allow researchers to encrypt vulnerability details that they e-mail to us
3. A notification list for security-alerts
4. Define an expected response time to resolve vulnerabilities
5. Do we go with CVE labels for vulnerabilities or use our own labeling system

I think that these 5 things should probably be owasp wide, and projects should be required to have a link on their *main pages* pointing people to the OWASP Policy for reporting Security Vulnerabilities.

The policy itself should be pretty standard,

1. Send as much info as possible, including PoC code if available.
2. Ask nicely to not disclose publicly until we have had a chance to respond and/or resolve
3, Encouraged use of OWASP cert to encrypt details of vuln in e-mail

We should have a central e-mail distribution that goes to project leads for all owasp projects (something along the lines of vulnerable at owasp.org<mailto:vulnerable at owasp.org>)

We should only encourage people to submit security vulnerabilities using Issue Trackers if we have the ability to *hide* those issues from anonymous and/or non project commiters.

On Mon, May 3, 2010 at 9:47 AM, Michael Coates <michael.coates at owasp.org<mailto:michael.coates at owasp.org>> wrote:
This event raises a really important issue for consideration - how will security issues in ESAPI be handled?  Despite our best efforts there will be security issues that pop up from time to time. One thing that may hold organizations back from adopting ESAPI is a documented understanding of how OWASP/ESAPI will handle security bugs in ESAPI. Mainly, we need to document how security bugs should be reported to OWASP, how OWASP will traige the issue, how the issue and risk will be communicated to the ESAPI user community, how the issue will be fixed and whether post mortem details will be published.

But to Jeff's point, there are always those who will publicly disclose an issue before contacting the vendor/software owner.  However, this isn't that bad. The worst would be a private disclosure to an maliciously focused group.  (Granted private disclosure to the software owner before public disclosure is the preferred approach).

Michael Coates

On 5/2/10 2:40 PM, Jim Manico wrote:
It's my opinion that OWASP needs an organization-wide security
notification email list but I was turned down. And thats ok. So for
now we can email the esapi-dev and the esapi-users list with any

Jim Manico

On May 2, 2010, at 2:15 PM, Chris Schmidt<chrisisbeef at gmail.com<mailto:chrisisbeef at gmail.com>>  wrote:

I think this also may partially be a result of not having a well
defined and documented process for reportig vulnerabilities in the
code. Did we ever get anywhere with setting up a mailing list or group
for security notifications?

Sent from my iPwn

On May 2, 2010, at 2:55 PM, "Jeff Williams"<jeff.williams at owasp.org<mailto:jeff.williams at owasp.org>>

IMHO this is just one more sign of a healthy security ecosystem.
There will always be folks who think it's 37337 to release an
unknown exploit regardless of the harm it causes. But complaining
about it won't help.  No matter what, we need to have a measured
response capability ready. It's entirely possible that this is an
esoteric risk that doesn't really expose any real applications,
however it could also be critical. At this point we don't know. I'm
looking forward to evaluating the alleged flaw, whatever it might be.


-----Original Message-----
From: owasp-leaders-bounces at lists.owasp.org<mailto:owasp-leaders-bounces at lists.owasp.org> [mailto:owasp-leaders-<mailto:owasp-leaders->
bounces at lists.owasp.org<mailto:bounces at lists.owasp.org>] On Behalf Of Jim Manico
Sent: Sunday, May 02, 2010 1:30 PM
To: owasp-leaders at lists.owasp.org<mailto:owasp-leaders at lists.owasp.org>; ESAPI-Developers; ESAPI-Users
Subject: Re: [Owasp-leaders] Crypto attack and OWASP

We deprecated 1.4 encryption and are seeking bids for professional
cryptographic-centric review of ESAPI 2.0 rc6 before we promote ESAPI
to GA (general availability). I have stated on several occasions that
no one should be using ESAPI for cryptographic storage in production
apps - yet.

However, I do have issue with the irresponsible nature of this

We leave the finding of thes bugs as an exercise for readers

And I know that members of OWASP would NEVER pull a stunt like this
any vendor. Our ethics put community and open way above glory-

Jim Manico

On May 2, 2010, at 1:50 AM, Christian Heinrich<christian.heinrich at owasp.org<mailto:christian.heinrich at owasp.org>



To quote https://media.blackhat.com/bh-eu-10/whitepapers/Duong_Rizzo/BlackHat-EU-2010-Duong-Rizzo-Padding-Oracle-wp.pdf


OWASP ESAPI 20, which stands for OWASP Enterprise Security API
Toolkits, is a project that claim to "help software developers gu
against security-related design and implementation flaws." Howe
found that all OWASP ESAPI for Java up to version 2.0 RC2 are
vulnerable to Padding Oracle attacks 21. There were some significant
changes in ESAPI Encryption API since 2.0 RC3 22. Unfortunately,
these changes are heading towards the correct direction, i.e.
the ciphertex or using an authenticated encryption mode, but at the
time of this writing, there are still some bugs in the latest
implementation 23 that make applications using ESAPI for Java still
vulnerable to Padding Oracle attacks. ."

On Fri, Mar 5, 2010 at 12:15 PM, Nam Nguyen<namn at bluemoon.com.vn<mailto:namn at bluemoon.com.vn>>

Quote: We show that even OWASP folks can't get it right, how can an
average Joe survive this new class of vulnerabilities?


Anyone going to BH-EU?

Christian Heinrich - http://www.owasp.org/index.php/user:cmlh
OWASP "Google Hacking" Project Lead - http://sn.im/
OWASP-Leaders mailing list
OWASP-Leaders at lists.owasp.org<mailto:OWASP-Leaders at lists.owasp.org>

OWASP-Leaders mailing list
OWASP-Leaders at lists.owasp.org<mailto:OWASP-Leaders at lists.owasp.org>

Esapi-dev mailing list
Esapi-dev at lists.owasp.org<mailto:Esapi-dev at lists.owasp.org>

Esapi-user mailing list
Esapi-user at lists.owasp.org<mailto:Esapi-user at lists.owasp.org>

OWASP-Leaders mailing list
OWASP-Leaders at lists.owasp.org<mailto:OWASP-Leaders at lists.owasp.org>

Chris Schmidt


Check out OWASP ESAPI for Java

OWASP ESAPI for JavaScript

Yet Another Developers Blog

Bio and Resume
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/esapi-user/attachments/20100503/5ca6c2d5/attachment.html 

More information about the Esapi-user mailing list