Bob Schellink wrote: > > I don't see how a filter can protect against SQL injection. Unless you are > talking about XSS which > is something else altogether. > Well, I'm not sure how it's called (but I guess it's not cross site scripting - since it's on the same site), but e.g. a Filter could block "/../../../" or similar value patterns to parameters (in the case of a file system).
George. > Malcolm Edgar-2 wrote: >> >> Click does not provide any specific facilities to prevent SQL >> injection attacks, as this is an application domain requirement. >> > You are fully right, but if something like this happens, the blame goes > always to the web framework too, since everything passes through the web > layer. > > > Malcolm Edgar-2 wrote: >> >> and potentially a application level Filter strip dangerous characters, >> or to reject these requests. >> > This is interesting. > It would be helpful if there would be such a Filter example in > click-examples and/or Best Practices. > > I couldn't find so far a good example for Java that would not have a bad > impact on performance :(. > > thanks, > George. > P.S. It was my mistake to consider "SQL injection" even if that parameter > attack happens in the absence of an SQL database and the attacker gains > access , e.g. in case of XML persistence, or simple file system operations > (although I haven't found how this type of attach is called). -- View this message in context: http://n2.nabble.com/How-sure-is-Click-agains-SQL-injections-tp4813027p4817101.html Sent from the click-development mailing list archive at Nabble.com.
