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-tp4813027p4817026.html Sent from the click-development mailing list archive at Nabble.com.
