Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>The most common threats to look out for are attempts to elevate privilege through this class. For instance if you have a user table with an admin attribute used to determine if a user is an admin, even if this attribute cannot be set in the form you describe a user can craft a post to the action of the form on the page with <code>&amp;admin=true</code> or <code>&amp;admin=1</code> depending on the corresponding column data type.</p> <p>The protection against this is specifying in your model the attributes that are updatable through mass-assignment.</p> <p>You do this with the <code>attr_accessible</code> method.</p> <pre><code>attr_accessor :x, :y, :admin attr_accessible :x, :y </code></pre> <p>This will prevent the admin attribute from being updated through an <code>update_attributes</code> call typically used in an edit action.</p> <p>The other thing to watch out for is automated sign-ups. For this there are a couple of things you can do. The most common is to implement a captcha. Without this someone could write a script that creates 1_000_000 users in your table making it very difficult to determine which are real and which are fake. You may also think about logging sign-up attempts by IP and restricting the number of requests for an hours time, for instance.</p> <p>As for your edit page protection, the most common way to protect this is to use a before_filter in your controller that makes sure the user has some piece of session information before allowing the page to be rendered.</p> <pre><code>class UsersController &lt; ApplicationController before_filter :protect, :only =&gt; [:edit] private def protect unless current_user redirect_to login_path end end end </code></pre> <p>Just some examples. I'm sure there are many more ways to protect yourself but this will at least give you an idea of the places that need attention to prevent the most basic attempts at wrecking your day. The problem with this topic is that the techniques used to break/hijack your site are ever-evolving. Some people think they are covered and get hit anyway. Backup your data frequently via script, write other scripts that check the integrity of your database. If you see a sudden leap in user instances of the table you'll know something is up, review the logs and restore your data. </p> <p>If your site is popular, it will get attacked, period.</p> <p>Another thing regarding captcha, I've heard that ANYTHING displayed on a screen can be scraped by script so as safe as this may seem there are talented people out there that can dance around your security like the Macarena.</p> <p>Be as proactive as possible and have your reactive measures well thought-out.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload