Ian Holsman wrote: > On 21/08/2006, at 9:24 PM, [EMAIL PROTECTED] wrote: > > You deny everything by default, and have holes added when you need them. > and when you poke a hole you have a reference to why it is required > (ie what module needs a particular variable unfiltered) > > Things which you don't know will hurt you unfortunately. and by > using deny by default with a big sledgehammer will > stop a lot of these things before they even touch your code. > > doing it the other way requires a conscious effort to maintain the > firewall, and you won't know when you are failing. >
Hmm, didn't see the reply to this until now. Anyway - yes, you're right. But I think there is a tendency to go overboard with things like mod_security. For example, you can download huge lists of mod_sec rules at places like gotroot.com, which have some very broad spectrum anti SQL-injection, XSS etc rules e.g. last I looked at them there was a rule to deny all POSTs with various SQL keywords ( select, insert, drop, etc ). The chances of false positives are very high with things like this. I guess my major issue here is that the webserver should not be protecting crappy applications from themselves. Mod_security and similar should not be relied on. The application needs to do the relevant security. --Simon --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~----------~----~----~----~------~----~------~--~---
