[Esapi-dev] Help regarding issue 251
Kevin W. Wall
kevin.w.wall at gmail.com
Tue Oct 7 00:39:35 UTC 2014
[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.
>> On Saturday, October 4, 2014, August Detlefsen <augustd at codemagi.com>
>>> 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
>>> "'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
> 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
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?
NSA: All your crypto bit are belong to us.
More information about the Esapi-dev