click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From georgex <>
Subject Re: How sure is Click agains SQL injections?
Date Mon, 29 Mar 2010 10:07:48 GMT

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).


> 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:
Sent from the click-development mailing list archive at

View raw message