Funny you should mention that - I just blogged about a solution very
much like what you describe. Check it out:

http://blog.explorationage.com/articles/2006/01/25/how-to-protect-your-rails-apps-against-cross-site-scripting-attacks

Kevin Olbrich wrote:
> m4dc4p wrote:
>
> > It's still only about 50% of the solution but I did think it was
> > interesting. One problem with it is that Rails is smart enough to HTML
> > encode values passed to many of its functions, so you will see
> > double-escaping. I also noticed that if I dumped something like
> > <%=params.%> on the page (to see all key-value pairs) the "name" value
> > inside would NOT be escaped. I don't how that value is displayed
> > without to_s being called, though.
>
> I tried to stir up a little discussion about this a few days ago.
> Personally I think the default behaviour of rails apps should be to
> escape data by default and only return unescaped stuff when requested.
>
> I don't think mucking with ERb is such a great idea since it is used for
> lots of other non-rails stuff.
>
> One solution I have been pondering is to modify the method_missing
> function so that when you request an attribute, it escapes the text
> coming back.  It should also define an alternate attribute called
> 'unsafe_#{attribute}' or 'unescaped_#{attribute}' in case you really
> want the raw data.
>
> This should protect against any text being retrieved by the database.
> It won't clean up instance variables if they don't originate in the
> database, but this should avoid the majority of problems.
> 
> _Kevin
> 
> -- 
> Posted via http://www.ruby-forum.com/.