[Esapi-dev] Help regarding issue 251

Kevin W. Wall kevin.w.wall at gmail.com
Mon Oct 13 21:29:55 UTC 2014


No more commits on Google Code. ESAPI has now moved to GitHub.

-kevin
Sent from my Droid; please excuse typos.
On Oct 13, 2014 3:05 PM, "August Detlefsen" <augustd at codemagi.com> wrote:

> OK, I now have a fix that passes all tests, regardless of whether a
> lenient DateFormat is used.
>
> However, I seem to have lost my commit access. Can someone please re-add
> me?
>
> Thanks,
> August
>
> On Mon, Oct 6, 2014 at 5:39 PM, Kevin W. Wall <kevin.w.wall at gmail.com>
> wrote:
>
>> [Apologies for the minor rearrangement to clean up the top posting.
>> -kevin]
>>
>> On Mon, Oct 6, 2014 at 8:18 PM, August Detlefsen <augustd at codemagi.com>
>> wrote:
>> > On Sat, Oct 4, 2014 at 3:28 AM, Fabio Cerullo <fcerullo at owasp.org>
>> wrote:
>> >>
>> >> I belleve August has a point. We cannot handle all date formats that
>> could
>> >> be represented out there, but we definitely need to make sure the ones
>> we
>> >> accept are valid.
>> >>
>> >> Fabio
>> >>
>> >>
>> >> On Saturday, October 4, 2014, August Detlefsen <augustd at codemagi.com>
>> >> wrote:
>> >>>
>> >>> If you want to be able to handle non-date information in your date
>> >>> parsing, you can specify string literals in SimpleDateFormat by using
>> single
>> >>> quotes. You just need to create a specific formatter to handle cases
>> like
>> >>> "Today is October 3, 2014". The format String would look something
>> like
>> >>> this:
>> >>>
>> >>> "'Today is' MMMM d, yyyy"
>> >>>
>> >>> So if someone needed to, they could definitely handle such odd cases
>> with
>> >>> ESAPI. But IMHO the default should be to strictly validate dates to
>> conform
>> >>> to the specified format.
>>
>> Okay, that's great that Java provides a mechanism to do this, but AFAICT,
>> ESAPI itself provides no mechanism to do this.  I think again, the
>> question
>> is *should it*? (Note that this is a quite different argument than what we
>> should allow the default to be.) If this is doable within ESAPI today,
>> *how*
>> is it down? (And note, it almost certainly has to be done at the API level
>> so it can be controlled programmatically and not just through some ESAPI
>> property regex.)
>>
>> > Actually, with the code change I proposed, the tests fail. I think this
>> > actually is due to a flaw in the test methodology itself:
>> >
>> > The test instantiates a DateFormat like this:
>> >
>> > DateFormat format = SimpleDateFormat.getDateInstance();
>> >
>> > SimpleDateFormat.getInstance() will return a lenient date format using
>> > Java's default 'MEDIUM' pattern. When you format a date with the MEDIUM
>> > pattern, it returns a String like this:
>> >
>> > Oct 6, 2014
>> >
>> > But because the formatter is lenient, it is stall able to parse full
>> dates
>> > like:
>>
>> Ah, there it is. 'Lenient' is the word that I was looking for. I
>> mistakenly
>> referred to it as 'loose'. Hope that did not confuse anyone.
>>
>> >
>> > October 6, 2014
>> >
>> > into a valid Java Date object.
>> >
>> > In this case, the tests all fail because the input "September 11, 2001"
>> does
>> > not match the formatted parsed date, "Sep 11, 2001". I could easily
>> change
>> > the test methodology to use a fully-specified date formatter like:
>> >
>> > DateFormat format = new SimpleDateFormat("MMMM dd, yyyy");
>> >
>> > and all tests would pass, BUT, what is the expected operational use
>> case of
>> > ESAPI? Do we need to support lenient date formats? Or can developers be
>> > expected to specify full date formats when using ESAPI?
>>
>> And that exactly is why I posted, and in fact, asked Nalin Goel and
>> the two colleagues he is working with to post to *both* ESAPI-Dev and
>> ESAPI-User mailing lists.
>>
>> I think most of us will agree on what the safe (wrt security) defaults
>> are,
>> but I'm not so convinced that we understand the operational use cases of
>> developers who happen to be *using* ESAPI, which IMO is quite a different
>> thing.  We still have not heard from the *user* community on this. Does
>> that mean no one cares or no one is using these Validator methods?
>>
>> -kevin
>> --
>> Blog: http://off-the-wall-security.blogspot.com/
>> NSA: All your crypto bit are belong to us.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/esapi-dev/attachments/20141013/48b1ba8f/attachment.html>


More information about the Esapi-dev mailing list