Spent some more time going over the OWASP list. The PDF[1] is really well put together and a recommended read if you are serious about security.
I think we should put some effort into supporting some of these items. A4(Insecure Direct Object References) and A5(Cross-Site Request Forgery) seems straight forward to implement in Click. bob [1]: http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202010.pdf (3MB) On 21/04/2010 09:36, Bob Schellink wrote: > It should be plausible to handle A4 (direct object reference) through a > custom HiddenField and > ActionLink. In a future release of Click we could ship such controls. > > regards > > bob > > > On 21/04/2010 09:15, Bob Schellink wrote: >> Hi George, >> >> On 20/04/2010 22:33, georgex wrote: >>> >>> How well does a typical Click webapp hold against the following 10 security >>> risks? >>> http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project >> >> >> I'm not aware of any effort to make Click apps secure against the OWASP top >> 10 (interesting effort), >> so if your application is publicly hosted and contains sensitive data, make >> sure you understand >> security well or find a security expert to help out. >> >> That said: >> >> A1(injection): shouldn't be a problem with ORM's or PreparedStatements >> A2(XSS): Click controls escape their values at rendering time, however >> Velocity variables are *not* >> escaped by default so if you reference untrusted code through a Velocity >> variable make sure you >> escape it e.g: >> >> $format.escape(customer.description) >> >> The rest of the list seems quite application specific and won't be handled >> by Click automatically. >> >> kind regards >> >> bob >> >> > > >
