[Esapi-dev] Help regarding issue 251

Kevin W. Wall kevin.w.wall at gmail.com
Thu Oct 16 02:12:10 UTC 2014


I'm relatively new to GitHub, but I think the general way it works is
that you create your own personal fork (typically on GitHub, but
anywhere that is publicly accessible works) and then you just shoot
your URL to someone
to merge it. I'm not sure, but I think that Chris might be the only one who
can currently merge something to GitHub. I _might_ be able to, but I have
never attempted.

Anyhow, thanks for the patch. We'll take a look.

-kevin

On Wed, Oct 15, 2014 at 10:06 PM, August Detlefsen <augustd at codemagi.com> wrote:
> 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.
>>>
>>>
>



-- 
Blog: http://off-the-wall-security.blogspot.com/
NSA: All your crypto bit are belong to us.


More information about the Esapi-dev mailing list