[Esapi-dev] Help regarding issue 251

August Detlefsen augustd at codemagi.com
Mon Oct 13 19:05:42 UTC 2014


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/5a441846/attachment.html>


More information about the Esapi-dev mailing list