Skip links hacked – Security archive case study

Security Archive: Remembering security incidents to make sure we don’t commit the same mistakes over and over again.

Want to read more stories like this one? Follow @sucuri_security on twitter or subscribe to our RSS feed. Interested in a web site security monitoring solution? Visit

Jan 17th, 2008. Every person who visited the site of the famous programming language Perl (, got redirected to a porn site hosted at Uh-oh, when was it hacked? Did anyone compromised the source code from Perl? What about the accounts at, where they stolen?

During these incidents, people tend to overreact and think of the worst. However, what happened was very simple… That was the official explanation:

We at O’Reilly just got bit on, which redirected to a porn site courtesy a piece of remotely-included Javascript. One of our advertisers was using an ads system that required our pages to load Javascript from their site. It only took three things to turn into (1) the advertiser’s domain lapsed, (2) the porn company bought it, (3) they replaced the Javascript that we were loading with a small chunk that redirected to the porn site (note that nothing on or about changed).

Very interesting.. The servers weren’t hacked at all (or even touched). A simple remote javascript got modified and their site became a “porn” paradise.

What mistakes they did:

  1. They included javascript from remote sites. This is a common thing nowadays (specially if you run ads), but you have to choose your sources wisely. Google is a good one, but grepblogs doesn’t sound very authoritative.
  2. The domain expired, the javascript was not loading and nobody noticed. That means that they were not monitoring the site as they should.

What to learn from it and how to protect ourselves?

  1. Limit the amount of external content you embed on your site. If you need ads, choose a reputable company that will not go away and will take security seriously.
  2. Monitor the content of what you include on your site. If you have to use scripts from remote locations, regularly check if they are still in business, check if the script is still responding properly and if they didn’t get compromised.
  3. That’s the best advice: whenever possible, store your content locally where you can control.

What do you think? What additional steps we can take to avoid issues like that?