A few of us at MxM have waited several weeks for O2 to sort out their supply issue with iPhones for business users (we nearly gave up and bought them as ordinary punters from Carphone Warehouse, but the Free of Charge thing seemed worth hanging on for…).

Here’s a picture of Stuart to show just how delighted he is to be in possession of a 3G iPhone in time for next week’s Rails Europe conference. Face saved.

With the economy in general down-turn and the consequent drop in advertising spend, we joked with a client last night that they should look at investing in bingo, dieting or dating, even though it’s pretty far from their usual business. So I’m not altogether surprised to hear that Penguin Books have got into dating.

Like many others, I’ve been watching Penguin’s development online with interest and have been impressed by their willingness to slough off the ‘dusty’ publisher reputation to experiment with some very novel (ahem) ideas like the One Million Penguins wiki-novel (which seems to have suffered an attack from an anti-virus software provider so I can’t link to it), the spy novel Google maps mash-up We Tell Stories or their crowd controlled site for young readers: Spinebreakers.

I haven’t had much experience of dating sites, having been in a long-term relationship for, well, a long time. But in the interests of science or something, I briefly checked out PenguinDating - Penguin Books’ collaboration with Match.com.

You can find a like-minded soul who reads the same books and authors as you, but it’s a very small part of the profile and is hidden way down the page. If I were a bookish type trying out online dating for the first time under the auspices of my favourite publisher, I’d want there to be a bit more emphasis on the literary stuff. Once you get past the home page, it’s a match.com i-frame headed up by PenguinDating. Partnering with match.com makes clear commercial sense, but the collaboration would have more weight with users if the user experience and expectation had been given more prominence and TLC. A little bit of custom service design to adapt match.com for the Penguin audience would make a big difference.

If finding a match is as confusing as the navigation (why does the PenguinDating logo link back to the Penguin UK home page?), you’ll have finished A la recherche du temps perdu by the time you find someone.

Sending email programmatically can be tricky, especially if you’re sending it in bulk.

Unless you’re careful it tends to get marked as spam, and the problem is exacerbated by the fact you’re unlikely to know about it - users rarely trawl through their spam folder - and rarer still let you know your email has been caught there.

Solving this problem is a bit of a dark art, like SEO, since spam filters tend to be a bit arbitrary but here are a few tips that will help:

Send from a static IP address:
Email providers often blacklist blocks of dynamic IP addresses since these are often used by spammers. So, make sure you’re sending it from a static IP.

Don’t include images
This is a contentious one, but I’ve seen a fair amount of legitimate corporate email sent to the spam folder because of the inclusion of a company logo. I prefer to play it safe and, if possible, only send plain text emails.

SPF records
The Sender Policy Framework (SPF) was introduced to combat fake sender addresses, which nearly all abusive e-mail messages carry.

I’ve gone to my inbox before, only to find thousands of autoresponders and failed delivery messages. Initially I thought my webserver had been hacked, but instead the spammers were just setting the sender address as my one - to try and make them look more legitimate.

SPF is designed to combat this and allows the owner of a domain to specify their mail sending policy, e.g. which mail servers they use to send mail from their domain. You need to set a SPF record on your domain’s DNS record so receiving servers can check whether the message complies with the domain’s stated policy. You can see SPF at work if you look at an email’s header, you can do this in GMail like this:

Here we can see that Twitter hasn’t configured SPF correctly:
Received-SPF: softfail (google.com: domain of transitioning noreply@twitter.com does not designate 66.7.206.23 as permitted sender) client-ip=66.7.206.23;

There are lots of good articles out there, I recommend the easyDNS one, but you should be able to find one specific to your DNS provider.

Reverse DNS Record
Reverse DNS is a way of associating an IP address with its domain name. Email providers often check that the reverse DNS record of the IP that sent an email is the same as the sender’s domain to determine whether the email’s spam (although they generally don’t require that these are the same).

Reverse DNS is setup by configuring PTR records (Pointer Records) in your DNS server. To make changed to your Reverse DNS PTR records, you must contact the company where you get your IP addresses from, usually a hosting facility or an ISP.

Try running nslookup on your domain name’s IP - that will show you the Reverse DNS Record.
Here’s the result from 75.101.158.59 (aireohq.com)

  nslookup 75.101.158.59
  Server:		62.140.195.84
  Address:	62.140.195.84#53

  Non-authoritative answer:
  59.158.101.75.in-addr.arpa	name = ec2-75-101-158-59.compute-1.amazonaws.com.

This is another problem with sending email from EC2 - the Reverse DNS Record doesn’t match the sender’s domain, and you can’t change the PTR Records to rectify the problem.

MX Records
This one’s really important - most email providers will check the sender domain’s MX Record to see if the server that sent the email is included. You can check the MX Records for your domain like this:
dig -t mx madebymany.co.uk

Delegation
Well, the easiest cop out solution is to delegate your email sending to a SMTP relay like AuthSMTP or easydns. These guys usually send so much email that they have agreements with the major ISPs so their email doesn’t get marked as spam. Don’t forget to configure your SPF record to authorize the relay to send email on your behalf. Paul Dowman has a good tutorial on how to relay mail from an EC2 instance to AuthSMTP through Postfix.

There are other ways that mail gets marked as spam, but you can’t influence most of them. Keep checking the SMTP logs to see if mail gets rejected, since usually there’s a helpful explanation.

Does anyone have any other tips?

Our latest release, Protect The Human, a social campaigning platform developed for Amnesty International’s UK division, marks an important milestone in Made by Many’s life. It’s nearing our first birthday and on the back of the private beta release of Metrotwin, we quietly released Protect The Human to the world on Tuesday.

Today is the first day that the wider world’s attention will be drawn to Protect The Human as it sees the release of tickets for Amnesty’s Secret Policeman’s Ball and the announcement from the High Court that evidence from Guantanamo prisoner Binyam Mohamed is admissible in his case to escape the death penalty. His case has been highlighted by Amnesty’s Individuals at Risk campaign for the past few years. (You can help raise awareness of his plight by taking action on Protect The Human.)

The juxtaposition of these two events is classic Amnesty: the tricky balance of important human rights issues with the lighter side of life; and Made by Many, in collaboration with our Ruby on Rails development partner New Bamboo, are very proud to have played a part in helping Amnesty get the message out to the wider population.

We worked very closely with Amnesty to define their online campaigning needs and ambitions before entering into a period of service definition to flesh out exactly what the site would do and how. The close relationship with Amnesty and New Bamboo continued throughout the project’s design and development. We’re looking forward to the future as Amnesty’s commitment to the web as an additional campaigning channel grows.

The site was built over an intensive 3-month period using Agile project, design and development methodologies (more of which we’ll reveal in a future blog post) and in true Agile style, the site will continue to be improved with iterative releases. Keep an eye on the site (and this blog) for release of more features over the coming weeks.

So what can you do on Protect The Human? Well, you can share, comment on and bookmark content from around the web to spread the word about human rights issues that matter to you.

And you can show your support by contributing the smallest action. What we’re aiming to do is to encourage more people to get involved with human rights without banging the drum and coming over all heavy-handed.

Your contribution can be as quick as a comment on a video, gallery or bookmark you’ve seen on Protect The Human. Or you could send it to a friend. For anyone who wants to spend a little more time, users can add their own bookmarks, create their gallery of images or upload a video relating to human rights.

We anticipate that the site will significantly contribute to Amnesty UK’s target to engage with 1 million people by 2011.

Stay tuned for a case study on the project with more detail on how we worked together with both Amnesty and New Bamboo.

I’ve recently been doing a bit of Rails auditing, and I thought that I’d just run through the main things I check; all fairly generic attacks that aren’t specific to particular Rails websites.

SQL injection
Actually, I haven’t seem much of this, probably because it’s one of the more well known attacks and people generally seem to be aware of it.

ActiveRecord will automatically escape any tainted data, but only if you use the correct syntax:

  User.find(:all, :conditions => ['name = ?', params[:name]])

All the question marks will get replaced by the escaped name parameter, so your SQL query will be immune to SQL injection attacks.

However, if you were do do something like this:

  User.find(:all, :conditions => ["name = #{params[:name]}”])

Well, you might as well be giving away your database credentials - an attack can post arbitrary SQL to your webserver, which it will happily execute.

However, it’s not just the :conditions options that is at risk - people sometimes forget to escape tainted strings when passing to :order and :limit (amongst others).

CSRF (Cross Site Request Forgery)
I’ve covered this before on my blog, and the problem has largely been solved with Rails’ built in protection against such attacks.
However, if you’re using GET requests to change state or make destructive actions you’re still at risk. A tell-tale sign is if they’re using :any in routes.rb - and not checking the request method in the controller action, for example:

  # routes.rb:
  map.resources :users, :member => {:approve => :any}

  # user_controller.rb
  def approve
    User.find(params[:id]).approve!
    redirect_to :action => ‘index’
  end

So if Bob gave Alice a url to http://example.com/users/1/approve - Alice would automatically approve that user (if she was logged in).

Usually this attack would be done with a hidden image, so Alice would visit Bob’s innocuous website completely unaware that she had just sent of a request to example.com, approving Bob’s account.

It’s also worth searching for ’skip_before_filter :verify_authenticity_token’ - to see if CSRF has been disabled anywhere.

So, to sum up, make sure the site you’re auditing is using the right HTTP methods, for the right actions; and make sure it’s using an updated Rails version (or using the CSRF killer plugin).

Cross Site Scripting (XSS)
An attacker can exploit XSS to steal session cookies and/or write arbitrary HTML into your website.
If you have any unescaped tainted strings (from the database, for example) displaying on your website, then your site is vulnerable.

Do a search for ‘<%=’ on the codebase to quickly find potentially dangerous strings, if the string is tainted (e.g. from params or the db), then it needs to be wrapped in the ‘h’ method, like this:

  <%=h @post.body %>

Better still, install the xss-shield plugin which will escape everything by default. Hopefully one day Rails will integrate this plugin and this will be less of a problem.

restful_authentication security problem
Last year there was a major security problem with restful-authentication which meant that an attacker would be able to log in without any credentials and use the first account found in the database (probably an admin one too). The plugin was subsequently patched - but it’s worth checking to see which version the site is using.

attr_accessor
I’ve saved the most common security flaw until last, not using attr_accessor and attr_protected correctly (or not using them at all).

The ActiveRecord method update_attributes is very convenient, and allows you to update your model easily with the request’s parameters. However, this can lead to some unforeseen consequences, like an attacker updating fields you weren’t expecting, like ‘is_admin’ and ‘role’.

The first thing I do when auditing, is to go to Rails schema.rb file (which incidentally I believe should always be checked into source control) and check the ‘users’ table (if there is one). A lot of sites have the ability to make a user an admin, or have different roles for users. It’s very important that those columns are attr_protected - i.e. they can’t be updated with update_attributes.

If they aren’t protected, it’s trivial for an attacker to guess the column name, add a few fields to a form, and make themselves an admin.

So there you have it, the most common security flaws in Rails applications. Can you think of any other ones?

Following up on Alex MacCaw’s post on collaborative filtering. The plugin we recently released acts_as_recommendable allows Rails developers to quickly add some user-driven recommendations of items to their latest great millionaire-making startup. At Made By Many we’ve been developing some great niche social-media Ruby On Rails sites recently with New Bamboo and Headshift. The new edge of social media is in the maths, commenting and rating is so old-school, it’s what you do with that data that counts.

This is going to be a tutorial for simple integration of acts_as_recommendable to recommend your users some books.

Read the rest of this entry