Friday, December 15, 2006

UTF-8, rails vaildations and all that jazz

To be honest, it never occurred to me that Ruby did not natively support Unicode given its roots. Alas, Ruby really has no clue about multi-byte character encodings, except Regexp that can handle UTF-8 if the 'u' specifier is used. But wait, given that UTF-8 is the default encoding for XHTML etc., what affect does this have in Rails applications? A lot and not much at all at the same time. Let me explain the little I know about this.

I ran into this issue on the first rails app I deployed. Even though I had pretty tight validation regexs on my models, every once in a while user provided content would clearly contain Unicode and not display correctly. Damn, that is scary. My validations where not stopping this data from making it into the model. The app served out XHTML 1.0 Strict pages with charaset set to UTF-8. By default browsers POST form data in the same encoding as the page containing the form; In this case UTF-8. All it takes is one cut&paste from MS Office into a form field (think bullet points etc.) to end up with Unicode in the form parameter values. The reason I was ending up with multi-byte values that were not displaying correctly it two-part.

The more trivial side of the issue is that it turns out Safari has a bug when handling response data from XmlHttpRequest that contains multi-byte encoded characters. This issue is resolved by explicitly setting the encoding on AJAX responses. The more troublesome issue is how the multi-byte characters made it past the validations on the ActiveRecord models. After a little experimentation I came up with this:

irb(main):036:0> utf8 = "\342\200\271script\342\200\272"
=> "\342\200\271script\342\200\272"
irb(main):037:0> test_regex = /^[\w]+$/u
=> /^[\w]+$/u
irb(main):038:0> m = test_regex.match utf8
=> #
irb(main):039:0> m[0]
=> "\342\200\271script\342\200\272"
irb(main):040:0> test_regex = /^[-a-zA-Z0-9_.]+$/u
=> /^[-a-zA-Z0-9_.]+$/u
irb(main):041:0> m = test_regex.match utf8
=> nil

Argh, \w in UTF-8 enabled Regexp matches most, if not all, of the UTF-8 character set above the single-byte encodable ASCII subset. Fortunately, it appears that Ruby's Regexp UTF-8 string handling does not honor overlong-encoded characters, so it appears if you are doing validations that exclude many of the characters generally needed to inject HTML or Javascript, it is unlikely that they can simply be avoided by using overlong UTF-8 encodings. That is good news. However, if multi-byte encoded characters make it into your models and you use methods like sanitize() or h() to do some safety filtering on presentation, don't expect them to do their jobs well.

In summary, there is potential for some security issues to arise out of acceptance of multi-byte encoded data, but the most straight-forward issues like direct tag and script injection will generally not escape past your input validations. As I research this more, I will keep you posted.

Thursday, December 14, 2006

Session fixation in Rails

If you are not familar with session fixation vulnerabilities, just google it or hit up wikipedia.

By default Rails supports sessions and uses CGI::Session to handle session management. CGI::Session defaults to setting the session id in a cookie, but it has a backup:

"If the client has cookies disabled, the session id must be included as a parameter of all requests sent by the client to the server. The CGI::Session class in conjunction with the CGI class will transparently add the session id as a hidden input field to all forms generated using the CGI.form HTML generation method. No built-in support is provided for other mechanisms, such as URL re-writing."

OK, so there is an avenue to exploit session fixation without having to be able to manipulate cookies (through a client-side vulnerability) in Rails. Hack a little on CGI.form to figure out the parameter name that will make it accept a session id from a form parameter (so the attack would be to modify the form served via an XSS vulnerability or rehost the form in a phish variation). Sessions are on by default in Rails, so we need a to remediate this issue. Here are a couple of options:

1. Disable session support in your application if you can. It may be a little more of a design challenge, but in some cases you can safely avoid having to maintain state between client and server. Edit app/controllers/application.rb and add "session :off" to it. There you go, sessions are disabled.

2. OK, you need sessions. Fine. In an app I wrote, there are a few views that are unauthenticated, a bunch of views that are authenticated, a login mechanism and sessions are used to store error/response messages in the unauthenticated views and to hold the user object in the authenticated views. The risk of session fixation in the unauthenticated views in very minimal, but it does give an attacker a very easy mechanism to obtain a valid session id. Once the user is authenticated, knowing the session id provides access as the user, but that is a different issue (session hijacking) assuming we fix session fixation. We really just need to protect the transition for unauthenticated to authenticated by changing the session id on the transition, which is controlled by the login mechanism. The application is largely RESTful, so a GET to /user/login yields the XHTML login form and a POST to /user/login attempts to authenticate the user with the parameter values. In the user controller, I added "session :new_session => true, :session_expires => (Time::new + (60 * 60 * 24)), :only => :login, :if => Proc::new {|req| req.post? }" The :if parameter provides an anonymous function that checks whether the current request is a POST to be consistent with the REST semantics of user controller actions. The other parameters are self-explanatory. Even if an attacker steers the user to the login view with a know session id, when the user authenticates the session id will change. There you go, authentication yields a different session id.

For the auditors out there, you should be looking for "session :off" or "session :new_session => true" that covers the unauthenticated/authenticated transition in those rails apps growing like weeds in your front yard.

Oh, and I am sure there is a more elegant solution, and with the beauty of rails, I am sure someone will figure out how to package it in a plugin. I also use one-time, time-limited nonces to validate forms were served from the server, but that only hinders the form rehosting (phish) version of the attack (forces the attacker to proxy, a different threat altogether, or periodically re-GET the form, which is generally easy to spot in logs). Dealing with the session fixation issue is still necessary.

Welcome to the New-school

I finally decided to contribute something to the global knowledge-base. Whether this something is of interest to you is yet to be determined. You may ask what is the deal with the blog name, so let's start there.

In the underground, hackers were often referred to as either old-school or new-school, with the latter term being somewhat derogatory. I always considered myself on the cusp. The old-school was long in the tooth when I started hacking freebsd, linux and Windows NT 3.1. Shell accounts on Netcom did not compare to X.25. But I had the old-school ethic and interest, and many of my friends are straight-up old-school: the NWA of globally connected networks. WTF you say? I am getting there--just explaining my relationship with the new-school term.

The role of a security engineer is rapidly changing. Five to ten years ago, security engineers handled a lot of firewall configuration; IDS deployment; anti-virus; pentesting and in enlightened environments, code review/programmer training. Now, security engineering is moving towards an aspect of, or integral part of, the software development process. I think the following factors are contributing to this change:

1. For a number of very pragmatic reasons (simplifying operations and responsibility, improved product knowledge, easier to configure products with better defaults, device-ifying of many things), much of the network side of security engineering has moved into network engineering. Any product company building a networking device with security functionality should be expecting it to be managed by network engineers. Network engineers are, in the end, responsible for the network infrastructure, and if packets flow through it, it is part of the network infrastructure. Having split-responsibility for networking devices complicates trouble-shooting and increases MTTR.

2. In-house software development is rapidly increasing as many business leverage the internet for some or all of their revenue stream. I worked at Amazon.com for a total of three years, and it may come as a shock to hear that Amazon largely considers itself a software platform development company. Simply put, Amazon's software platform enables its revenue stream, and Amazon's ability to be agile with regard to features and platform direction is critical to its success. Amazon is an internet company, but not only internet companies are highly dependent on software agility. The financial industry stands on the cutting edge of computing and software development. And software product companies have taken notice; look at Microsoft. What does this have to do with security engineering? If you have been paying any attention to the security space, you have witnessed the rise of the application-level vulnerability. Core OS network-connected services where once the focus of vulnerability research. If one thing was learned about security, it was that only the necessary services should be exposed externally. Indeed, the average company has a radically improved external security posture with regard to exposed services. What is left? Web applications springing up like weeds and the SOA offerings coming online. Of course there is also the core software these applications depend on, going all the way down to the OS (and beyond).

Where should the focus of security expertise be applied? It does not take a genius to figure that it is better to build security in than try to bolt it on, hence the re-focus of security engineering towards the software development process. This brings us to the new new-school.

Some of the old-school are not all that prepared for the new new-school, while others are deeply thankful to finally start working on the real security problem: design and implementation of software, hardware and everything inbetween. Design and implementation baby. Yeah, now we are talking. Well, sort of. I also have another little bias that is a love of dynamic programming languages. To some of the old-school, dynamic programming languages are considered toy-like, suitable for scripting at best, near sacrilegious, dangerous and should be exercised from real programs. Not in this new new-school; we are all over this dynamic programming language sh*t and intend to use it for everything we can get away with.

There you go. This blog is about security as part of software design and implementation with a bent on dynamic programming languages. It actually just might be a place that I jot down little things I notice and learn while hacking Ruby on Rails apps, but I don't know if that is enough for a BLOG, so I will pretend the scope is big and worthy of notice. Time for me to shut up and add some real content.