click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From georgex <george.st...@yahoo.com>
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).

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.

Mime
View raw message