Luke Plant wrote: > On Sun, 20 Nov 2005 20:21:54 -0600 Jacob Kaplan-Moss wrote: > > > This highlights the problem with this approach - what is "safe"? Safe > for output in HTML? Safe against SQL injection attacks (assume for a > second someone isn't using Django's DB backend)? Safe for inserting > directly into PDF or Postscript? Safe to be eval'ed in Python?
This is something that needs to be defined, but the need for a definition does not preclude that definition ever being known. The precise classes of attacks that are protected against should be explicitly documented. > 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. > I think I could live with it if you *always* had to specify what the > output format of GET and POST should be, but a magical default format > is a really bad idea IMO. The magic is never good enough to rely on for > security, because it is impossible to know what the app is going to do > with the data. So you can end up developing *less* secure apps - if > you are encouraging the developer to believe that the default output is > "safe" (against an unspecified attack) you are telling them they don't > need to worry about security, but they always do. You also have to know > all about browser peculiarities, as someone else mentioned, and you can > never protect against tomorrow's bugs and exploits. 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. > You *cannot* make development at this level idiot proof. Until you > can, you should never say "it's OK to be an idiot here, we'll watch out > for you." (I hope that doesn't sound arrogant -- I know perfectly well > I am capable of being an idiot and not sanitising input, but the > framework encouraging me not to think won't help me do better). 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.
