[Esapi-user] [Esapi-dev] Response Splitting
jim.manico at owasp.org
Wed Jan 26 15:09:27 EST 2011
Fine Jeff, you can continue to critique my reasoning all you want, but
we are going to have to agree to disagree.
How about we end this thread with something we agree on.
We need low-level primitives for ESAPI. An encodeHeader or safeHeader
function where a developer could safely prevent HTTP/RS at the time of
placing untrusted data into a header is a good thing. Fair?
> 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.
> 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:
>> 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.
>> 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:
>>>>> 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
>>>> 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
>>> Esapi-user mailing list
>>> Esapi-user at lists.owasp.org
>> Esapi-user mailing list
>> Esapi-user at lists.owasp.org
More information about the Esapi-user