Dave Elkins

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

The Ruby on Rails Security Blog has a post about a potential XSS issue with to_json.

Enjoy.

The Ruby on Rails Security blog has a good article about SQL Injection and Ruby on Rails.  Check out the SQL Injection article.

Enjoy.

Here is an interesting article by Bruce Schneier about the benefits and issues with penetration testing - “Is Penetration Testing Worth It?”.

I think it makes a lot of sense.  I have been researching what types security testing tools are out there and wondering what is the best way to test for security flaws.

Is it better to take outside approach where you look at the system from an attackers perspective?  Or is it better to look from the inside and use all the information available to identify areas where you may be venerable?

I would think the latter would be better because you have more information to work with.  I think it is better to restrict your attack surface, make a security plan and focus on the top venerabilities like Bruce Schneier suggests.

http://www.rorsecurity.info/2007/05/04/dom-injection-attacks/

http://www.rorsecurity.info/2007/05/04/defeating-input-filters-for-injection/

enjoy!

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 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]