Home arrow Ruby-on-Rails arrow Page 3 - Protecting Your Rails Ecommerce Application
RUBY-ON-RAILS

Protecting Your Rails Ecommerce Application


In this conclusion to a four-part series covering security for a Ruby on Rails ecommerce application, you'll learn how to protect the application against SQL injection, cross-site request forgery, and more. This article is excerpted from chapter eight of the book Practical Rails Projects, written by Eldon Alameda (Apress; ISBN: 1590597818).

Author Info:
By: Apress Publishing
Rating: 5 stars5 stars5 stars5 stars5 stars / 3
June 24, 2010
TABLE OF CONTENTS:
  1. · Protecting Your Rails Ecommerce Application
  2. · Protecting Your Application
  3. · URL and Form Manipulation
  4. · SQL Injection
  5. · Cross-Site Request Forgery

print this article
SEARCH DEVARTICLES

Protecting Your Rails Ecommerce Application - URL and Form Manipulation
(Page 3 of 5 )

Itís easy for people to build their own form by copying, for example, your registration form, and adding some fields to it, like this:

<input type="hidden" name="user[accepted]" value="1" />
<input type="hidden" name="user[admin]" value="1" />

Now suppose the malicious user submits this form to your standard registration action, which has something like this in it:

@user = User.create(params[:user])

This way, he might end up being an admin user.

It is fairly easy to protect against this type of manipulation in Rails. Just define sensitive attributes as protected:

class User < Activerecord::Base
 
attr_protected :accepted, :admin
end

Now these variables cannot be mass-assigned with a parameters hash like the one in the preceding example. However, you can still set them individually when needed:

@user.accepted = true

Another vulnerability raises its ugly head when you let users edit their information; for example, with URLs likehttp://www.domain.com/posts/edit/28. It wonít take long before someone notices that by changing the last part of the URL, she can get access to posts created by other people. You can protect your application from this by always getting to the objects through the logged-in user:

# BAD
@post = Post.find(params[:id])
# GOOD
@post = current_user.posts.find(params[:id])

If someone now tries to access a post that doesnít belong to her, anActiveRecord::RecordNotFoundexception is raised, which you can then rescue and show a Not Found page to the user:

rescue ActiveRecord::RecordNotFound
 
return render(:template => "/shared/404", :status => 404)
end


blog comments powered by Disqus
RUBY-ON-RAILS ARTICLES

- Ruby-on-Rails Faces Second Security Flaw in ...
- Ruby 2.0 Prepped for February 2013 Release
- Why LinkedIn Switched from Ruby on Rails
- Adding Style with Action Pack
- Handling HTML in Templates with Action Pack
- Filters, Controllers and Helpers in Action P...
- Action Pack and Controller Filters
- Action Pack Categories and Events
- Logging Out, Events and Templates with Actio...
- Action Pack Sessions and Architecture
- More on Action Pack Partial Templates
- Action Pack Partial Templates
- Displaying Error Messages with the Action Pa...
- Action Pack Request Parameters
- Creating an Action Pack Registration Form

Watch our Tech Videos 
Dev Articles Forums 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us 
Weekly Newsletter
 
Developer Updates  
Free Website Content 
Contact Us 
Site Map 
Privacy Policy 
Support 

Developer Shed Affiliates

 




© 2003-2018 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap
Popular Web Development Topics
All Web Development Tutorials