[Esapi-dev] Help regarding issue 251

August Detlefsen augustd at codemagi.com
Thu Oct 16 02:06:26 UTC 2014


OK, apparently I don't have permission to commit on Github either...

Here is a patch file. Do with it as you will.

-August

On Mon, Oct 13, 2014 at 2:29 PM, Kevin W. Wall <kevin.w.wall at gmail.com>
wrote:

> 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/20141015/ee71f9ae/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Issue_251.patch
Type: application/octet-stream
Size: 2442 bytes
Desc: not available
URL: <http://lists.owasp.org/pipermail/esapi-dev/attachments/20141015/ee71f9ae/attachment.obj>


More information about the Esapi-dev mailing list