There’s already a danger in Example 2-4, called
HTML injection. While the source of @message
and @bonus
is clear at the moment—the controller
code is stupidly simple and receives no user input—more complicated
programs offer opportunities for malicious users to send their own HTML
through parameters or form fields. To reduce their odds of causing a
problem, wrap values that you know aren’t supposed to contain HTML in an
h
function, short for html_escape()
. Example 2-7 shows a safer
version of the code from Example 2-5.
Example 2-7. Modifying index.html.erb to use instance variables from the controller
<html> <head><title><%= h(@message) %> </title></head> <body> <h1><%= h
(@message) %></h1> <p>This is a greeting from app/views/hello/index.html.erb</p> <p><%= h
(@bonus) %></p> </body> </html>
Using h()
isn’t always
appropriate because there will be times when you want to include HTML
directly, without turning "this is
bold" into "this is
<b>bold</b>
.” Sometimes applications need to be
able to say bold instead of
<b>bold</b>. For these cases, you can use sanitize()
instead of h()
. The
sanitize
function escapes form
and script
tags and removes event handling
attributes whose names start with on
,
as well as links starting with javascript:
. Using the h()
and sanitize()
functions does take more typing,
but it can spare you considerable pain later on, for security reasons
that Chapter 18 will
explore in more depth. (You can, of course, leave them off in the rare
cases where you’re really intending to include everything, even the
dangerous parts, when you know you’ve managed the dangers within the
controller code.)
If sanitize()
isn’t strong
enough for you, you can explore the white_list
plug-in at http://weblog.techno-weenie.net/2006/9/3/white-listing-plugin-for-rails.