[Esapi-user] [Esapi-dev] Response Splitting

Jeff Williams jeff.williams at owasp.org
Wed Jan 26 15:39:55 EST 2011


This is exactly why premature optimization is the root of all evil.

A regex doesn't take anywhere close to a tenth of a second.  A simple but not terrifically naive test on my laptop, accounting for JIT and GC, shows that for the types of regexes we use in ESAPI it is just under .0003 milliseconds (yes .0003 MILLIseconds) across many millions of matching operations.

I've spoken about this for years.  Validation is not likely to be a performance problem any more than having the extra weight of brakes slows down cars.

Jim, you're sending a very dangerous message.  This is roughly the same reaction I got at Sun btw.

--Jeff

PS - I have no issue at all with providing options, modularity, etc...  It's only your reasoning that is flawed.


On Jan 26, 2011, at 2:05 PM, "Jim Manico" <jim.manico at owasp.org> wrote:

> Jeff,
> 
> I'm working on apps where request latency/delay needs to stay under 2 
> seconds (think futures/stock trading, ebay like apps, etc). One 
> regular expression may only take on average 1/10 of a second to fire. 
> If I run 2 regExs (one at header population time [generic], and 
> another contextually based on the input [contextual]) then I'm doing 
> unnecessary validation. I'd rather only do the contextual and kill the "generic".
> 
> This is not always the case, most of the time to "wrappers" are 
> fantastic since they provide "automatic security". I just want options.
> Again Jeff : I like your work around filters and wrappers. It's solid 
> thinking. I just want options when "that way" is not best for a 
> specific team or codebase for a number of reasons.
> 
> A low level primitive "encodeHeader" or "safeHeader" which 
> encodes/validates to stop HTTP/RS is a positive feature.
> 
> Again Jeff, what you are doing around these "wrappers" is solid. They 
> have their use, even the SafeResponse/SafeRequest stuff.
> 
> But we needs options. Low level primitives have the most flexibility, 
> and we should include them in ESAPI. ESAPI-lite, coming soon, will be 
> focused on delivering these primitives in a way that is much more 
> seamless than the current ESAPI code-base.
> 
> Respectfully,
> Jim
> 
> PS: "MILLIONS of requests", ey? 
> http://www.youtube.com/watch?v=jTmXHvGZiSY
> 
> 
>> Esapifilter must die.. I have never used it because I want more 
>> control over my requests :)
>> 
>> That being said, I wrote an awesome securityfilter using dependency 
>> injection lately :)
>> 
>> Sent from my iPwn
>> 
>> On Jan 25, 2011, at 8:30 PM, "Kevin W. Wall" <kevin.w.wall at gmail.com> wrote:
>> 
>>> On 01/25/2011 09:57 PM, Jeff Williams wrote:
>>> [SNIP]
>>>> Ahh wait – you’re talking about specifically using 
>>>> ESAPIFilter/SafeRequest/SafeResponse, aren’t you?  I’m suggesting 
>>>> the use of targeted wrappers to prevent header injection.  I do 
>>>> believe that the ESAPIFilter has caused issues since it does 
>>>> everything.  But I see no problem with the idea of ResponseWrappers in general.
>>> 
>>> I think a JavaEE Servlet Filter is exactly what Jim was referring 
>>> to. I think using targeted wrappers is a better approach and I would 
>>> expect it to have minimal performance impact. OTOH, we could do much 
>>> better on optimizing ESAPIFilter.
>>> 
>>> -kevin
>>> --
>>> Kevin W. Wall
>>> "The most likely way for the world to be destroyed, most experts 
>>> agree, is by accident. That's where we come in; we're computer professionals.
>>> We cause accidents."        -- Nathaniel Borenstein, co-creator of MIME
>>> 
>>> _______________________________________________
>>> Esapi-user mailing list
>>> Esapi-user at lists.owasp.org
>>> https://lists.owasp.org/mailman/listinfo/esapi-user
>> _______________________________________________
>> Esapi-user mailing list
>> Esapi-user at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/esapi-user
> 
> _______________________________________________
> Esapi-user mailing list
> Esapi-user at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/esapi-user



More information about the Esapi-user mailing list