A number of our sites have come under cross-site scripting attacks in the last few days. From reading other blogs this seems to be a pretty widespread wave of automated attacks, not specifically targeted at any of our sites.

Cross-site scripting is a technique used to either compromise the databases that lie behind many modern websites or trick the website into displaying some malicious code. These attacks are pretty easy to carry out, as they only require changing some parts of the URL that visitors use to access your site.

The URL is often used to pass parameters which carry information between parts of the site - for example in a Content Management System, the url might carry a parameter like 'articleid' to indicate the page to be displayed e.g.

www.mycms.com/showpage.cfm?articleid=12367

Because the URL can be so easily changed, web developers need to validate all the data that comes from the URL to make sure it is what they expect before they start using it. In this case, to confirm that 'articleid' is a number - unfortunately this can sometimes be overlooked in the heat of development.

An attacker could alter this URL parameter to include an additional database command or link to a potentially dodgy site, e.g.

www.mycms.com/showpage.cfm?articleid=12367';DELETE FROM articles;

If the articleid parameter is not just a number, we can assume that someone is fiddling with the URL and take appropriate action.

Fortunately we develop our sites using industry standard security techniques so none of our websites seems to have been penetrated, but if you have a site developed elsewhere, it may be worth checking with your developers that they are aware of the issue and have taken appropriate steps.

This series of attacks was a good reminder to us though to go back and re-confirm that our code wasn't vulnerable - and also confirmed to us that the time spent securing sites is never time wasted.

Many people come across problems using content management systems like Wordpress and Joomla on Windows Servers. One of the problems is folder permissions when you try to upload images or other content.

There are thousands of tutorials out there on how to fix this on Linux servers - chmod the properties of the folder to '777' - but what can you do when you are using a Windows server running IIs?

The error message I was getting in Wordpress was:

You may get a similar message from Mambo, Joomla or other content management systems.

In the case of Wordpress, the wp-content folder needs to be writable to IIs - or more specifically the internet user on your server. So how do you do this on Windows? Like all these things, its only easy when you know how.

Assuming you have access to the server e.g. by remote desktop:

1. Navigate to the wp-content directory. This will most likely be in inetpub/wwwroot/yourdomain or a similar folder in the main web root.
2. Right-click on the folder, select Properties, and then the 'Security' tab.
3. This will show a list of the users with rights on your machine. You need to determine which one is used by the IIs process to serve web pages - usually the name in brackets after the username will be prefixed IUSR. In our case, as we are running Plesk to manage our server, the username is Plesk IIS User (ServerName/IUSR_mydomain)


4. The only permissions set for this user will probably be the 'List Folder Contents'. You need to add the 'Write' permission, by clicking that box.
5. Click 'Apply'.
6. You're done (hopefully).

If you have the Plesk Control Panel, you can set these permissions directly in Plesk without having to remote desktop to the server:

1. Click Domains, then the relevant domain, then File Manager. Navigate through the folders so you can see the appropriate directory name
2. Click on the yellow padlock icon ('Change Permissions for Directory')

3. Again choose the appropriate IIs user (the one with IUSR_ in the name)
4. Click the 'Write' option
5. Click OK.

Please let me know if you found this useful.