Remove the SilverStripe generator meta tag

Oh dear, SilverStripe 2.3.1+ now has an updated meta tag function that has a “generator” meta tag which includes detailed version numbers of the CMS. Eg for version 2.3.1, it has the text: “SilverStripe 2.3.1 – http://www.silverstripe.com”. Take a look here as to why I think this is a bad idea.

This is a real pity, and not something I want to have in a production website. SilverStripe is a great CMS and development framework and deserves praise (as does the web development company behind it, SilverStripe), but not right down to the release number!

Removing the generator tag is pretty straightforward:

  1. Open the Page.ss for your theme. Eg for blackcandy, open /themes/blackcandy/templates/Page.ss
  2. Remove this function call: $MetaTags(false) (could be $MetaTags(true) either)
  3. This prevents the generator tag from being output, but it stops a few other meta tags too, so I suggest you add the following to your Page.ss in the <head> section:
    <title><% if MetaTitle %>$MetaTitle <% else %>$Title <% end_if %>- MyWebSiteName</title>
    <% if MetaKeywords %><meta name="keywords" http-equiv="keywords" content="$MetaKeywords" /><% end_if %>
    <% if MetaDescription %><meta name="description" http-equiv="description" content="$MetaDescription" /><% end_if %>
    <meta name="generator" http-equiv="generator" content="SilverStripe - http://www.silverstripe.com" />
  4. <meta http-equiv="Content-type" content="text/html; charset=utf-8" />
    <meta http-equiv="Content-Language" content="en"/>

  5. Save your file and upload if necessary. Once you flush the cache, your should see the changes

Now you might notice that I did slightly more than just meta tags there: I also updated the <title> tag. The $MetaTags function call I removed can output a title tag if $MetaTags(true) rather than false is set and you have a meta title set for your page in addition to the standard title.

This is a good idea for some pages. For example, a page on a site I was recently working on was called “Home”. This was fine for the navigation label and actual on page title, but “Home – MyWebsiteName” does not look good for a window title or in google search results, so we used the meta title to set something which only appears in the meta data and not on the actual page, which was more descriptive and useful.

You might also notice I did not completely remove the generator tag. Well I do want to show my support for SilverStripe so in this particular instance I have just removed any mention of version numbers. At least you now have control over this text.

Some caveats though: my code above replaces what the MetaTags function currently does, but this may change in future so that were additional functionality added to the function, you might be missing out. It also gathers data such as the language and content-type automatically which you need to set manually in my code (if you need to change it).

I will blog again on the MetaTags function if it does change. A perfect reason for subscribing to my RSS feed!

Comments (5)

The lock on my door is a Yale Model AG34

door lockNo, I don’t suppose that is the first thing you are going to tell a perfect stranger now is it? How about someone who has just called to your door? More unlikely still.

The Rant:
Which is why it really annoys me that some web applications insist on vanity tags displaying to the world what software system you are using, and worse still, sometimes it shows what version you are using!

Just what is required to execute a zero-day attack on your poor little website. Or indeed make it far too easy for evil minded people to find sites running out of date software.

Is it on your site?
Examine the source code of your web page. It will be between the “head” tags at the top of the page. Take for example the screenshot of the html code on a blog I visited the other day. You can clearly see from the generator meta tag that not only is the blog powered by WordPress, but it is running version 2.5.1. In this example, the blogger is probably fine. There are a couple of security fixes released since WordPress 2.5.1 was out in July, but none that I would rate as vital. But is it really a good idea to let the world know:
a) what web application you are running?
b) what exact version you have installed?
wordpress generator meta

The cure
Now, I was going to go into a big rant about just how pointless I thought the generator meta tag was anyway, but I have to decided to bite my tongue and concentrate on the real evil: including the version number.

This is just plain old bad idea. I was really annoyed to see it creep back into the WordPress blogs I manage recently as the location has been switched from the wordpress header template file to the WordPress internals (from WordPress 2.5 on). So even if you thought you had removed it, if you upgraded to 2.5 or later, it might be back in there again!

There is a relatively easy way to remove it again however, and this should be permanent unless they change this again in a future major version release.
Add the following line to the functions.php file of your WordPress theme:
remove_action('wp_head', 'wp_generator');
(within the php code tags)

For other web applications, you may need to check the documentation or search the support forums for answers on how to remove the generator tag.

Comments (1)

Uninvited guests…

I have just recently switched this website from the Drupal CMS to WordPress. Within the last 24 hours I have had the first symptoms of an irritation I have noticed on other blogs I mangage. Almost as soon as the conversion was complete, I had two suspicious user sign-ups. Suspicious in that they occurred in very short order for a relatively low traffic website, and guess what, they both end in “.ru”, the Russian domain ending.

Now I am not in favour of tarring everyone with the same brush, I am sure most Russians couldn’t give an Abkhazia about my blog, but there is something fishy going on. Another blog I managed has over 1,500 registered users, yet over 800 of those users have emails ending in “.ru”.

So what is going on here? Initial suspicion was that this was a way of attempting to place spam comments on the blog, but does not seem to pan out. Firstly, the Akismet plugin does not seem to have a problem catching comment spam whether the user is registered or not. Not that I could find any relationship between these “dodgy users” and the comments that had been placed into the Spam bin by Akismet.

So I haven’t worried too much about them since they don’t seem to be doing any damage.

As I mentioned earlier, this is a new blog. Comments have been open on it, but I have only just activated the Akismet plugin. So there were about 24 hours during which comment spam could have been placed on the blog yet it wasn’t, even by the suspicious new users. Strange huh?

It seems then that there must be another reason for these signups other than comment spam. They may be trying to exploit known vulnerabilities in older versions of WordPress.

In any event, to see if I can cut this out, I have installed a new plugin, Register Plus, this has quite a number of nifty features around user registration which have been a bit lacking in WordPress to date. The features I have so far activated are:

  • Email address confirmation for new users
  • Users can set their own passwords
  • Custom logo on the registration page

There are a number of additional features worth checking out, but so far those are the ones I will be using.

I will see how I get on over the next few weeks and if successful, I will roll out the plugin to other WordPress sites I manage.

My suspicion is that these “dodgy signups” are driven by an automated bot and this may well not be able to use the new registration form. If that fails, then I am pretty sure the email addresses are invalid and therefore the user accounts are not activated and will be removed after 7 days.

In the last resort, there is also a captcha feature, but I would prefer not to have to use that. Hate the bloody things!

Another blogger who doesn’t think much of the fake user signups is using the Sabre plugin, but I am going to see how I get on with Register Plus before employing yet another plugin that only does one specific task. They become a nigthmare to manage them all.

Comments

Blood on Broadway

So when I became a blood donor 5 years ago I didn’t think that one day my records would be stolen in a mugging in New York [1].
I doubt most people did. I don’t recall seeing a check box saying, “tick here to opt out of the IBTS giving your personal data away to organisations in foreign countries as and when we decide to upgrade our software”.

Such is the world we live in.
Frankly I’m surprised the loss of the data was such a physical one, rather than a hack.

So here are my main issues with the Irish Blood Transfusion Service:

  1. I really do not think you have the right to simply dish out my personal information (including what communicable diseases I may or may not have) to just anyone as and when you like to.
  2. There is no excuse, not one, for sending across 170,000 patient records. For any kind of “upgrade” or “testing”. Quite frankly if this was to run testing, then there is no reason except for sheer laziness for the data not to have been scrubbed, removing personal information. It isn’t that hard. The last time I did it for a project involving confidential patient information, it took about 2 hours. Including a cup of tea.
  3. The IBTS chief executive says the data is encrypted. He says the odds of decrypting the data are the same as winning the Euromillions jackpot 10 weeks in a row. You are either wrong, still misinformed or just lying Andrew Kelly. The certainty of it being decrypted is 100%. The only variables are how long and how much resources you want to throw at the AES-256 encryption. And of course, the encryption passphrase, which is probably “IBTS” or “Password01″.

But it is great to know that the IBTS and the New York Blood Centre are both “deeply concerned” about the loss of the data.
Frankly, I’m concerned at the lack of blood flow to the brains in charge of the IBTS.

[1] Irish Times news report

Comments

WordPress: Are your user’s email addresses secure?

Jason Roe has pointed out a potential security issue for WordPress which I picked up on via boards.ie.

The issue can allow someone to scrape email addresses and other contact details from a wordpress site that allows user registration on it.

In the grand scale of things, it isn’t the worst, but it certainly is not kosher to allow someone’s email address to be seen when you have assured them it will be private.

This was of concern to me as I recently completed a project that is powered by WordPress and there are several hundred registered users. I zipped on over and sure enough, it was vulnerable (it was running WordPress 2.04).

I immediately went about upgrading to the latest version of WordPress 2.0x, version 2.06. This is not affected, but there is a mistake in the related code. Line 60 of the file /wp-admin/user-edit.php has the following:

die__('You do not have permission to edit this user.');

It should be

die(__('You do not have permission to edit this user.'));

It isn’t a biggie, it just throws a php error rather than telling the nosey parker to mind their own beeswax. I will report it to WordPress now if someone hasn’t already.

WordPress is an increasingly popular web publishing tool and with popularity comes security holes, from simple bugs like this one not being spotted through to people running versions that should have been upgraded a year ago. On the whole, I’m comfortable with it’s standard of coding and security.

I’m quite sure other, less popular applications have as many issues, but they go unnoticed without as many users poking and prodding the software.

It is sometimes easy to be lazy and leave that upgrade to another day, but issues like this highlight the importance of keeping up to date with the latest developments of your chosen web applications.

Comments

A new way to track visitors, but where is AJAX leading us to?

Here is an idea for all those big supermarket chains out there: as customers enter the store, give them an RFID tag to wear. That way, with the use of some strategically placed readers, customers could be tracked right across the store. Store managers could identify where people spend most of their time, what aisles are popular, what spots on a particular aisle people slow down at (there might be a promotional item at that spot). The possibilities for gathering useful data are endless.

So why don’t they do it? I’m pretty sure most people would give them a two-fingered salute and take their business elsewhere. Unless all the supermarkets did it at the same time and then we would have no choice.

When it comes to the web, it isn’t a person’s body movements a website owner wants to know about, it’s their mouse movements. After all, unless you are visually impaired, the mouse is the manner in which most users interact with a website, hovering over links, scrolling, clicking etc.

A new web service, ClickTale, has come up with a way of recording these actions so that website owners can record and later review, every mouse movement and scrolling action a user has made throughout a given website on which it’s service has been installed. I haven’t used the service but from what I’ve read and seen of the client side javascript it loads on a user’s page, it makes use of some AJAX wizardry.

Clearly, this is certainly a very useful tool from the website owner’s perspective, but I would members of the general public be so happy about it if they knew it was there?

It has some great applications in beta testing, usability testing and debugging of websites, but I wonder if it isn’t going just a bit too far for general use? Just because you can do something, doesn’t mean you should.

ClickTale do address privacy in their FAQ, I’m parphrasing here, but it boils down to “we aren’t gathering any personal information on you, so it’s ok”.

Lets translate that back into the real world: “If I follow you around town all day recording your every movement, but I don’t ask you your name, thats acceptable”.

I’m not so sure.

Like I said, ClickTale looks like a great service, and I wish the guys every success, but it points to an issue that is becoming more and more relevant in relation to the use of the web’s belle de jour, AJAX.

AJAX can be used to capture lots of information, from mouse movements to form inputs, without the end user knowing about it, or before they have pressed a submit button. Gone are the days when a user knew they had to hit the submit button before their info was processed by a website.

If we are going to be using more and more AJAX in our web applications, and I don’t see why we shouldn’t (I just spent the past 2 days working on something that uses AJAX), we had better make sure we don’t freak users out and have them switch off Javascript in their browsers.

Comments

The Ongoing Cost of a Website

None of the websites I have custom coded from scratch have ever been hacked. I’m not saying I’m the world’s best web developer, I will assume my readership is smart enough to draw that inference for themselves!

On the other hand, several sites that I have worked on that used “off the shelf” type programs for CMS or e-commerce have run into problems of late. It stands to reason that if enough people use and abuse a product they will eventually find flaws and security holes in it. In every case, the security exploits had been known about for quite a while and patches/upgrades available .

So why weren’t things patched? Well, the reasons for not patching up mainly fell into two areas:

1. There was no longer a technical resource available to perform the required actions
2. The site had custom modifications that prevented a straightforward patch/upgrade

Now as a professional web developer I can’t really do much about it if a client doesn’t want to pay me or someone else to keep the site updated and patched. I’m unlikely to be overly pro-active about getting in touch with customers from a few years ago that might need to upgrade when a particular security flaw is uncovered, but I would drop them a mail if I thought it affected them.

I can understand a customer’s reluctance to engage me on an ongoing basis or even to bring me back in every year or so to perform updates. Most of the projects I do are brought to a stage where the site or web application can be managed and operated by non-technical users, the idea being that the customer stumps up a higher up front cost for a system that doesn’t require regular interventions and updates from a techie, thus saving them money in the long run. I think though, for my part I will have to flag the necessity of security updates to clients outside of any other ongoing maintenance/support contracts which they may or may not want.

Most of the off the shelf systems such as Joomla!, Mambo or X-Cart (which I use for some e-commerce projects ) have very easy patch/upgrade systems that would even allow a non-techie with a bit of bravado (and hopefully a database backup!) to perform the update.

This assumes however, that the core code and functions of the website application remain intact, and this is not always the case. The customer might require an extra piece of functionality that is not currently present and must be custom coded. In this case, the preference would be to develop some sort of module or plug in that stands outside of the core code, allowing a clean upgrade path. There is no guarantee your own custom code will still work once the update has been run, but in most cases it should be straightforward enough to do, and at least the main body of code has been updated without much trouble.

In instances where there have been modifications to the core code, the task becomes more complex. The developer then needs to see what the upgrade/patch is changing, and then manually apply the code updates/patches using some sort of text file comparison/merging tool. In short a bit of a nightmare!

There are often very good reasons at the time of development for modification of core code in this manner. It isn’t always possible to code add on functions as separate code or indeed source a program that does everything you want, exactly as you want it to, and if the customer has a genuine requirement for a particular feature, then who am I to argue?

I might not argue, but I should underline the seriousness of breaking the upgrade path to a product. It really adds significant costs to future upgrades which in turn might have the consequence of necessary updates and upgrades being put on the long finger.

It isn’t always the customer though. Sometimes the web developer can be lazy and simply lash something in any old way without worrying too much about how it might affect things in a years time when an upgrade is needed. After all, he or she will have retired to a non-extradition Caribbean island by then. As a developer it is important for me to ensure a clean path to future updates/upgrades for web applications wherever possible.
If your site is running an off the shelf web application, it is important that you make yourself aware of any security updates and alerts that come from the developers of the application. Even if it is just to check that your techie is applying the necessary updates, it is an important step. Ultimately it won’t be the guy who did the site 3 years ago that suffers most if your site is hacked using a year old exploit…

Comments