That Was Mean

For the past few weeks I have been spending a few minutes here and there putting together a catalog web site. Now, you may be asking what kind of catalog system would Mike be working on? Let me fill you in….

It all started with a co-worker, an awesome guy, and a few tasteful jokes. One bad joke later I wanted to get him back in a way that no man can deny: publishing a public wronging on the Internet. And, with that, thatwasmean was born.

It started as a very simple logging of things said in the office.

The categories grew for different needs.

The color schemes changes as suggestions came in.

But what I have found most interesting so far is the cohesiveness between posts. They relate to each other, even spread across multiple days, and you can generally figure out what goes with what and the livelihood of that incident within our office.

So, with all that said, ThatWasMean.com launches to a little more of a public scale. It was developed in Ruby on Rails, hosted using Phusion Passenger and Apache, and is evolving slowly… Check it out and provide any feedback.

go to ThatWasMean

Ruby Regular Expressions – Security Risk

This post is a half reminder to elaborate when I have free time… But in short, there is nothing wrong with Ruby regular expressions, except that they behave differently than one might expect (in general and if coming from Perl RegEx).

Here is the dealy, from the Programming Ruby book by Dave Thomas:

The patterns ^ and $ match the beginning and end of a line, respectively. These are often
used to anchor a pattern match: for example, /^option/ matches the word option only if it
appears at the start of a line. The sequence \A matches the beginning of a string, and \z and
\Z match the end of a string.

All sounds good right? Well, it turns out that Ruby will execute code within a regular expression if you can pass multi-line input to the parser. For example… Given

class EmailAttachment < ActiveRecord::Base
validates_format_of :attachment, :with => /^[\w\.\-\+]+$/
end

You can easily pass in

attachment.txt%0A<script>alert('open_sesame')</script>

which is converted (as %0A is a URL encoded new line), by ROR, into

"attachment.txt\n<script>alert('open_sesame')</script>"

You can think about the implications of this, feel free… I have been able to have some fun with my own personal site and getting arbitrary JavaScript and (worse) shell commands to execute. Also, I believe this may cause a larger security whole within routes for Rails (at least 2.1.0). I’ll investigate this more later, as the beginning of this post says.