From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id pBV12w0w003306 for ; Sat, 31 Dec 2011 02:02:58 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AswCAChe/k7AbSoIe2dsb2JhbABDhQ+nRSIBARYmBCGBcgEBBAEjVhALCQ8CAiYCAhQYRBuHXwKjfZEpE4Ech0aCBDNjBI1HhzqSNg X-IronPort-AV: E=Sophos;i="4.71,435,1320620400"; d="scan'208";a="137328719" Received: from einhorn.in-berlin.de ([192.109.42.8]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 Dec 2011 02:02:52 +0100 X-Envelope-From: oliver@first.in-berlin.de Received: from first (e178004174.adsl.alicedsl.de [85.178.4.174]) (authenticated bits=0) by einhorn.in-berlin.de (8.13.6/8.13.6/Debian-1) with ESMTP id pBV12qEM031407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 31 Dec 2011 02:02:52 +0100 Received: by first (Postfix, from userid 1000) id E1F9F154036A; Sat, 31 Dec 2011 02:02:51 +0100 (CET) Date: Sat, 31 Dec 2011 02:02:51 +0100 From: oliver To: rixed@happyleptic.org Cc: caml-list@inria.fr Message-ID: <20111231010251.GC2801@siouxsie> References: <1325263446.5036.104.camel@samsung> <20111230174030.GA29317@yeeloong.happyleptic.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20111230174030.GA29317@yeeloong.happyleptic.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-Scanned-By: MIMEDefang_at_IN-Berlin_e.V. on 192.109.42.8 Subject: Re: [Caml-list] Hashtbl and security On Fri, Dec 30, 2011 at 06:40:30PM +0100, rixed@happyleptic.org wrote: > I will probably tell something very stupid, but HTML specs > do not prevent a client to post 1M values with the same name, > so whatever your hash function you cannot do much, can you? [...] That's a feature. > > The simplest solution I can think of that prevents all attacks > of this kind (but could reject some valid POST in theory) would > be to store the bucket lengths and use it to detect and reject > "obviously biaised" insertions. [...] How do you define "obvious" and "biased"? Sometimes, the distinction between feature and bug depends on the context... Ciao, Oliver