OmegaSoft - Developer Sandbox - Pitfalls of user interaction on your web service

User interaction with your website or web services, can make your website more appealing to the visitors it attracts and tempt new visitors to return to your site in the future. Tools such as guestbook’s, forums and blogs allow this interaction, however with more and more people turning to the internet as a daily part of their lives, the likelihood that malicious users may attempt to harm your website has increased.

First and foremost, you, as the website administrator are responsible for the content on your site. Even content posted by visitors through interactive features. Anything that appears on your website that may offend others may leave you liable to face either criminal or civil charges, or both.

Take for example a guestbook. Without security measures in place, a user may post a body of text on your website that has been plagiarised from a copyrighted source. You may not have seen the information, but the information has appeared on your website. Although it was posted by an anonymous user, the original author of the works will hold you responsible.

Another example may include a user posting HTML code into your guestbook, to create a clickable link to their own website(s). Let’s assume they are a competitor website, you may then see your customer/visitor numbers dwindle. Or if they were even more malicious, they could add JavaScript to a post and create annoying pop-up windows with adverts to their products, close browsers, create scary messages…

However, more recently – and the trend will only get worse – automated agents are now routinely visiting websites with user interaction tools and posting thousands of spam messages, either to sell something, promote something or give your website a bad name.


<?php

echo $_GET[‘comment’];

?>

You are printing to screen a comment made by a user. The comment has not been filtered and will display the message, whether it is a genuine or malicious.

Wherever possible, always attempt to send messages across from input forms using the POST method. The GET method will leave the comment visible in the URL. E.g. http://mysite/?comment=nasty+message

Never allow users (unless of course you want to) to post comments which may contain HTML/JavaScript code. The best way to prevent this, is filter the comment using PHP’s strip_tags() function.


<?php

$message = strip_tags($_POST[‘comment’]);

?>

It’s worthwhile investigating whether it is advantageous to post the comment. You’ve already established that code has been stripped out of the post. At this stage, you can ignore any posts with code, if you have decided that it’s not worth analysing anymore.


<?php

$message = strip_tags($_POST[‘comment’]);

if($_POST[‘comment’]) == $message)
{
    do_something();
}
else
{
    // Do nothing, it was a nasty post
}

?>

You are simply comparing the original comment text with the text after it has been filtered by strip_tags(). If the two messages are identical, then no code has been stripped.

If your website allows users to post code, always use the htmlspecialchars() function to turn the code into viewable text, so that the code is displayed and not obeyed.


<?php

$message = htmlspecialchars($_POST[‘comment’]);

?>

This type of checking will most likely eliminate a huge percentage of your user’s comments that were unwanted.

Your messages will either be stored on a flat file or a database as a permanent repository. It is worthwhile storing the date and time and the IP address of the user who has made the comment. Not only do you have records of who is posting on your website, you can use this data to make future preventative decisions.

Say for example, you have successfully blocked three comments from a particular IP address from posting on your system by identifying they have posted code. After the third attempt, you can set up an automatic block on their IP address to prevent them from posting again in future.


<?php

$banned = array(‘111.11.11.1’, ‘127.01.0.0’, 122.25.222.23);

if(in_array($_SERVER['REMOTE_ADDR'], $banned)
{
    // Go no further, execute nothing else for this user
    exit;
}

?>

The array $banned[] will have to be dynamic (say) stored in a database, so that new IP addresses can be blacklisted automatically without changing your source code.

There are new ideas being used, which Sandbox will investigate thoroughly in the future, which forces users to type random characters displayed in an obscured image into an authorisation box.

This is designed to prevent automated agents from posting on your site. The automotive agent will probably have trouble reading the characters within the obscured image. As the noise in the image will confuse the shape of the letters. However humans can read the random code at ease.

This article has touched on some preventative measures users can take to prevent malicious comments appearing on your site via automated or manual clients. While no method is 100 percent reliable, except for manually authorising every comment, the methods described above help reduce a huge percentage of your unwanted messages.

It is worth nothing though, that even large commercial websites, such as BBC News Online, which feature a ‘comments’ section, do not automatically post messages on their website until they have been manually verified.

Developer Comments

Donna Jones
User input should never be displayed directly onto a website, without some form of filtering to remove characters which could harm your site. Like code! A function should ideally be setup to accept the globals and then strip_tags() any code out of their strings.

Code Libraries

Projects & Resources

Pitfalls of user interaction on your web service

Developer Comments