All,
On 12/29/11 3:25 PM, Christopher Schultz wrote:
On 12/29/11 12:35 PM, Luke Meyer wrote:
Worth noting that TreeMap makes all storage O(log n), so the normal
case takes a hit in order to mitigate the worst case (i.e. malicious
case).
When n is small, though, O(n) ~= O(log n).
I'd be
Mark,
On 12/28/11 5:28 PM, Mark Thomas wrote:
Tomcat has implemented a work-around for this issue by providing a new
option (maxParameterCount) to limit the number of parameters processed
for a single request. This default limit is 1: high enough to be
unlikely to affect any application;
From: Mark Thomas
While both POST-size-limiting and parameter-count-limiting are
both reasonable mitigating procedures, would the use of a
randomized-hash be something worth doing?
I don't know. My instinct is that it wouldn't but I could be wrong.
Referring to
On 29/12/2011 15:44, Christopher Schultz wrote:
Mark,
On 12/28/11 5:28 PM, Mark Thomas wrote:
Tomcat has implemented a work-around for this issue by providing
a new option (maxParameterCount) to limit the number of
parameters processed for a single request. This default limit is
1:
2011/12/29 Christopher Schultz ch...@christopherschultz.net:
Mark,
On 12/28/11 5:28 PM, Mark Thomas wrote:
Tomcat has implemented a work-around for this issue by providing a new
option (maxParameterCount) to limit the number of parameters processed
for a single request. This default limit is
Luke,
On 12/29/11 12:35 PM, Luke Meyer wrote:
From: Mark Thomas
While both POST-size-limiting and parameter-count-limiting are
both reasonable mitigating procedures, would the use of a
randomized-hash be something worth doing?
I don't know. My instinct is that it wouldn't but I could be
You may have read about a recently announced vulnerability rooted in the
Java hashtable implementation [1]. Since Apache Tomcat uses a hashtable
for storing HTTP request parameters, it is affected by this issue.
As per [1], it appears that Oracle will not be providing a fix for this
vulnerability
