On Mon, 21 Nov 2005 23:44:27 +0000 Robert Wittams wrote:
> > In ASP.NET (my > > > > We have all used crap implementations of many ideas - a large > proportion of which are made by the same company as your example. The > existance of a crap implementation does not preclude a good > implementation. I've used that horrible feature in ASP.net as well - > it is nothing like as granular as this - more like Ians Safepost > thing actually. If the default method of getting POST or GET parameters either rejects "unsafe" content (presumably content that appears to be a XSS attack), or strips it out (which was what was being suggested in the post I replied to), this will amount to the same thing as the ASP.NET implementation - the developer finds out later that parts of the site are not usable, due to the framework being 'helpful'. > This is a documentation issue. It needs to be made very clear that > this is not going to save you from unknown attacks, it is just going > to filter input in very specific ways. But the API should reflect what is going on, as well as the documentation. request.GET['foo'] does not reflect that some fairly advanced filtering is going on, especially if you have other methods like request.GET.as_int etc, and very quickly people will either think it is doing nothing, or think of request.GET['foo'] as a "safe" request.GET, instead of what it really is, which is request.GET.as_xss_protected_html(). I'm not saying (and wasn't saying before) that we shouldn't provide this kind of filtering, but it should be blindingly obvious what it going on. > The point is that *when, not if, you fail* the system should let you > fail *as safely as possible*, rather than as dangerously as possible. Data loss due to parts of input being stripped out by a safety mechanism (when the developer had already built adequate checks into the code) is also failure, and so is a user being unable to input the required data due to some error message saying 'malicious data detected'. When the developer uses request.GET and request.POST, they shouldn't have nasty surprises like that hidden in them. If we want to include this kind of thing, it should be explicit in the API. Regards, Luke -- "Outside of a dog, a book is a man's best friend... inside of a dog, it's too dark to read." Luke Plant || L.Plant.98 (at) cantab.net || http://lukeplant.me.uk/
