Nathaniel S. H. Brown wrote:
In order to implement this properly you'd need to do a HTML parse (including _javascript_!) of the string passed to h and validate that. Obviously, parsing HTML is overkill for performance. And it's still open whether the question "should something be escaped here" is decidable at all. I believe it isn't.As I said before, I (or we, for whoever is in support) can solve the minor details, and provide solutions with a little bit of creativity. I am of the opinion that if you see points such as the ones you mentioned, you may also be able to see how to fix them, if you so desire. I have some suggestions.* Introducing this will break existing applications, which already make use of h, since h isn't idempotent.As I said previously, this could be available as a configuration option, negating your remark about breaking existing applications. You would have to explicitly choose to break your own application. And where would that leave you? Providing the option to enable the XSS security for those who do choose for it. When enabled, the h function would be wiser at detecting what it is that it's encoding. One idea is to have a safe list of tags and html code which can be verified, such as those found on the Nice try, but the proof obligation w.r.t. implementability and performance is on the proposer of the change.* And of course, it would severely hurt performance.I wouldn't mind seeing a benchmark of <%= '<p>test</p> %> vs. <%=h '<p>test</p>' %> to back this statement up. Understandably, the h method does do a bit more. But how much more? And what about caching? Why don't you go ahead and implement a plugin that changes <%= semantics? Not that I would recommend it or give it a good chance of success in the community, but it's up to you if you want to put effort into this. -- stefan -- For rails performance tuning, see: http://railsexpress.de/blog Subscription: http://railsexpress.de/blog/xml/rss20/feed.xml |
_______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core