badlyDrawnToy

Some time ago, I provided a simple JQuery solution for replacing target="_blank" when writing Strict XHTML. However, one commenter recently pointed out that my solution does not work if the rel attribute contains more than one value e.g. rel="external nofollow"

Well, JQuery to the rescue again. A very slight modification to the Attribute Filter fixes this issue. The code now reads:

$(function() {
	$('a[rel*=external]').click( function() {
		window.open(this.href);
		return false;
	});
});

Notice the asterisk. This matches attributes that contain a certain value, as explained in the JQuery docs.

However, this isn’t the full redux. Thanks to the power of JQuery, we can identify external links without the need for the rel="external" attribute at all.

Assuming that all internal links are relative e.g. href="/contact", we can simply search for all hyperlinks whose anchor contains a fully qualified url, or more precisely starts with http e.g. href="http://some.site.com".

The final code now looks like this:

$(function() {
	$('a[href^=http]').click( function() {
		window.open(this.href);
		return false;
	});
});

And that’s the power of JQuery

Tags: JQuery, linkedin

I spent several hours last week rescuing two WordPress blogs (this blog and GastroGrrl) that had both been exploited, and had become victims of nefarious spam links.

h2. WordPress Exploit

The exploit was remarkably clever. Only when Google’s search engine spider (googlebot) visited the site, did it include spam links at the footer of the page. The links were only visible when looking at the text-only version of the cached copy in google’s index. The reason I’d found the spam, was because the keywords showed up in the Google Analytics application, and GastroGrrl was no longer appearing in google’s index.

The exploits were a couple of files found on the web server – disguised as jpg and png image files – that were in fact malicious PHP scripts. The scripts went as far as adding a new user to the database.

I had no alternative except to completely reinstall both the WordPress application, and also the database. Twice. Not much fun.

The installs were up to date, though a few months ago, I was late in updating the software. Yesterday, WordPress announced another security update to version 2.6.5.

Along with the release, was a note that the version number had skipped from 2.6.3 to 2.6.5 due to a malicious, fake version of a 2.6.4 release existing online. Several months ago, an official WordPress download was hacked on the official servers, and exploits were widely distributed.

h2. Open Source Risk

Keeping open source weblog applications, like WordPress, up-to-date, can become quite an administrative overhead for those that manage client blogs. As weblogs have moved into the business/PR/marketing domain, many of those managing the blogs are not fully-fledged system administrators with the knowledge on how to secure their database or unix file permissions. This is a potential risk to the customer.

The problem is not limited to WordPress. OSCommerce, Drupal, Joomla – all popular open source applications – have all had exploit issues. This is not so much because the applications are poorly coded; it’s the nature of open source – anyone can examine the code. The more popular the application, the more likely it will be exploited.

In my work with Stan, when we discuss client requirements, we consider 3rd party open source solutions versus bespoke development. Much of the decision is based on the specific requirements, but increasingly, we also consider the security risk, and maintenance overhead.

A simple example is the ubiquitous CAPTCHA utilities found on web forms. They are an obvious target for spammers, who want to leave spam comments on weblogs etc. Open source CAPTCHA’s became a popular way to thwart such spam, and have become increasingly complex as they face a continuing battle with the spammers. In my opinion, this problem has now gone full circle. When applying a CAPTCHA solution to a web form, I choose *not* to implement a standard, open-source solution, opting instead for my own, less complex, easier to exploit, implementation. It may be easier to exploit, but who is going to bother?

Open source is great. My day-to-day development utilises numerous open-source applications. However, when a customer’s reputation is at stake, and indeed our client relationship, one has to ask the question – is open source software a risk to your business?

Tags: linkedin, open source, spam, wordpress

I was chatting yesterday with my friend Simon about my somewhat late discovery of Yahoo! Pipes. I knew about it, I’d just never played with it. Pipes is ideal if you’re looking to create a mash-up from RSS feeds. Simon asked if Pipes were constrained by the Same Origin Policy whereby XHR requests are restricted to the domain serving the original page. I said I’d look into it.
more »

Tags: cross site scripting, JQuery, linkedin, same domain policy, xhr, yahoo pipes