Dave Elkins

If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!

Preventing XSS attacks in your Rails application turns out to be fairly easy thanks to some built in functionalities of Rails.

Lets first start out talking about ways to prevent XSS scripting in general before we see how rails can help us. These are three things you can do:

• Validate all request parameters and form data with what are acceptable values. The best defense against XSS is to state what is allowed and only accept that. Of course that is not possible in every case but a lot of the time is possible - for example, validating numbers, dates, email addresses and using regular expressions.
• For data that can not be validated easily, it needs to be sanitize or html entity encoded. This will prevent malicious code from being presented to the browser raw.
• When displaying data make sure to encode it using html entities.

How can Rails help?….

Validating Data

Active Record Validations - Use AR Validations to make sure data complies with what you expect. There are number of built in validations and a ton of plugins that add more.

Use the Validate() method - AR Validations don’t do enough? Then implement the validate method to add more flexible rules.

Use attr_protected - Here is a link to a good article about it [click here].

Learn how to use regular expressions. They can be difficult to understand but they are powerful and are very useful.

HTML Entity Encoding of Data

Use the h() function in views when displaying data from the database or data that has been submitted through a form. This is very important. It will encode the data into HTML entities and this will give you a lot of protection against most XSS attacks.

Use CGI.escapeHTML() in places where the h() function is not available. It does the same thing as the h() function but it just requires a little extra typing.

In JavaScript, if you are going to use something from the URL or from the user and display it then make sure you use the escape() or escapeURI() functions.

Coming up

I am going to write about and find more resources about AR Validations and using validations w/o AR.

The Ruby on Rails Security Blog has a couple great post about session hijacking and how to prevent it in your Rails applications. This is a great blog that has a lot of good information about web app security for rails.

http://www.rorsecurity.info/2007/04/12/session-hijacking/ http://www.rorsecurity.info/2007/04/15/session-fixation-in-rails/

What is it?

Cross Site Scripting, or XSS has it is commonly referred to, is when an attacker use malicious scripting code to either attack an end user’s computer, impersonate another user or attack a web site. This can be done in several ways from malicious web sites to an attacker injecting code into unprotected site.

Where did the name come from?

The name is misleading because it really only characterizes one type of scripting attack that XSS now encompasses; this is because when it was originally coined the problem was not fully understood and there has been no effort to find a better name [1].

The original threat was that an attacker would use various means to get around the security policy of only code from the host domain could be executed. This turned out to be only a very small subset of a large problem.

Types of attacks

The first type is normally called Dom-based or local XSS. This is where there is a problem in the client-side scripting where it takes part of the url and uses it to produce content on the page. If the input is not sanitized or encode properly this code presents a hole for an XSS attack [1].

The second type, and most common, is when the user’s input is used directly in the creation of a page or response. This presents a huge hole if the server side does not do any filtering or encoding to “clean” the input.

The third type, which is similar to the second type, is when the user input is stored permanently and then redisplayed for other users with encoding it with HTML entities. This is the most powerful because one preach could affect a large number of users.

What to do?

In future post, I will go into more detail about particular attacks and how we as developers can secure our sites and applications from these types of attacks. I will be focusing on how to secure your rails applications.

References

1. http://en.wikipedia.org/wiki/Cross_site_scripting
2. http://www.owasp.org/index.php/XSS_Attacks
3. http://www.cgisecurity.com/articles/xss-faq.shtml

Over the next couple of weeks I am going to start writing about web application security and types of attacks that we as developers must know about and defend our applications against.

The three main types of attacks are:

1. Cross Site Scripting (XSS)
2. Cross Site Request Forgery (CSRF)
3. SQL Injection

These are significant issues and there is a large number of variations on these attacks.  The good news is that there are some very easy steps to take to prevent these attacks and there is a lot of overlap in defending against these attacks.

Stay tuned for more.

Steve Odom has released Elastic Rails which is a plugin that allows you to easily deploy your Rails app to EC2 using Capistrano.

This looks like a really good intro guide to Capistrano. I have been meaning to try out Capistrano and I think this is the tutorial I am going to use to get started.

http://www.softiesonrails.com/2007/4/5/the-absolute-moron-s-guide-to-capistrano

Steve Gibson continues his excellent series on scripting security. He talks about cross-site scripting in the is episode. He goes into details about how an attack works, gives some examples and provides several great links. This is a must listen to for anyone developing web sites or web applications.

Have a listen [link]

In this episode, Leo Laporte and Steve Gibson talk about Cross Site Scripting - what it is, some of the dangers, examples of attacks and discuss automated tools that help expose venerabilities in your web app or site. They also discuss in depth something called Jikto that can potential take over your computer through JavaScript.

Go check it out [link]

There are two plugins that can help prevent CSRF attacks. I have not had a chance to take these for a test drive but I will soon and I blog about how they work. CSRF stands for Cross-site request forgery Attack (link) and is an upcoming type of attack used against web sites.

Security Extensions

The first plugin is called Security extensions and can be downloaded at http://svn.aviditybytes.com/rails/plugins/security_extensions/.

CSRF Killer

The second plugin is called CSRF Killer and it can be downloaded at http://activereload.net/2007/3/6/your-requests-are-safe-with-us

This one is made by Rick Olsen who has made a ton of popular plugins for rails. This page has a lot of information about CSRF attacks [link].

Conclusions

Neither of these will be silver bullets but they can help and do not add a lot of overhead to your development and it makes your job easier when it comes to securing your web apps.

Nadav Samet provides a good description of the three major attacks that happen that can be prevented through the code of your web site.

Here is the link.