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: Live Edition 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.