[Esapi-user] [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.
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
> On Mon, Oct 6, 2014 at 5:39 PM, Kevin W. Wall <kevin.w.wall at gmail.com>
>> [Apologies for the minor rearrangement to clean up the top posting.
>> On Mon, Oct 6, 2014 at 8:18 PM, August Detlefsen <augustd at codemagi.com>
>> > On Sat, Oct 4, 2014 at 3:28 AM, Fabio Cerullo <fcerullo at owasp.org>
>> >> I belleve August has a point. We cannot handle all date formats that
>> >> be represented out there, but we definitely need to make sure the ones
>> >> 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
>> >>> quotes. You just need to create a specific formatter to handle cases
>> >>> "Today is October 3, 2014". The format String would look something
>> >>> this:
>> >>> "'Today is' MMMM d, yyyy"
>> >>> So if someone needed to, they could definitely handle such odd cases
>> >>> ESAPI. But IMHO the default should be to strictly validate dates to
>> >>> 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
>> 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,
>> 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
>> > like:
>> Ah, there it is. 'Lenient' is the word that I was looking for. I
>> 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"
>> > not match the formatted parsed date, "Sep 11, 2001". I could easily
>> > 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
>> 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?
>> Blog: http://off-the-wall-security.blogspot.com/
>> NSA: All your crypto bit are belong to us.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Esapi-user