Protecting Your View from the Controller
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, ...
Get Learning Rails now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
