Re: [TCLCORE] Upgrade of Tcl's String Hash Algorithm

[Colin M. <co...@ch...>]

Donal K. Fellows wrote:
> On 15/02/2010 20:55, Tom Jackson wrote:
>
>> Regardless of any problems with the current hash, why does anyone care
>> if some idiot chooses an array to store HTTP headers? Should the Tcl
>> language protect everyone because they don't realize they need to
>> understand that user data needs to be validated, or at least not
>> trusted?
>
> WTF are you talking about? I take it you seem to think that validating
> is done before the initial parse of the values into a data structure,
> rather than afterwards? Interesting concept. I'm not aware of any
> non-trivial web server that does that.
>
>> Of course I'm on record as being opposed to using an array to handle
>> HTTP headers, only the hard headed would continue to use arrays to
>> represent  HTTP headers, or create any local variables automatically.
>> Instead, what you do is to create a representation of the user data
>> and then query it using known keys.

The HTTP spec permits a client to send headers with essentially 
arbitrary names.  Anything which matches X-* is a valid HTTP header, 
according to the 1.0 and 1.1 specs.  I presume it's possible to craft a 
series of such headers which would exploit an easily exploitable hash.  
Validation of individual headers, then, isn't really a viable approach.

One could work around the possibility of a spammy malicious client 
sending too much of this stuff, pragmatically one would limit the size 
of headers.

I doubt whether the issue is that HTTP servers using hashed structures 
can be made to degenerate.  I think it's more that any use of hashed 
structures can be thus subverted.  HTTP servers are probably only an 
obvious example where a dict or array is exploitable.

BTW, I haven't read the record Tom is on, decrying the use of arrays to 
store HTTP headers.  I think Donal's right, though - they're the obvious 
data type, and no other data type seems to me to have the desired 
properties.

Colin.