Cal Henderson makes a good point regarding this: you never
know when you might have to escape data in a different manner for display elsewhere,
so data should usually be stored in its plain-text form. An exception might be
made for Unicode: it is usually important to ensure that data stored in a Unicode
encoding is well-formed, lest it cause problems in processing. In situations like this,
it is usually best to check for well-formedness at both ingress and egress.
Of course, things are rarely this simple. The reason XSS attacks are still so common
is that often developers want their untrusted users to be able to enter arbitrary
HTML, just not the ???verboten tags??? and ???verboten attributes?????”those that can execute
scripts. And filtering them out is harder than it might seem (see the section
???Canonicalization: What??™s in a Name?,??? later in the chapter, for the reason why).
Rails provides some help here, through the sanitize( ) method. This method
removes form and script tags, elides the onSomething attributes, and kills any URIs
with the ???javascript:??? scheme. The default set of prohibited tags and attributes may
be sufficient to block execution of arbitrary script. This method is used just like h( ):
<% @post.comments.each do |comment| %>
<%=sanitize comment.html %><% end %>
However, you should be very, very careful when using blacklisting such as this.
Pages:
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220