How to protect your website from hackers

Interacting with your website like a normal user will provide a hacker with a huge amount of free information about the way the site works. They will spend a long time reading the code loaded into their browser. The browser and the code (including HTML) served as part of each page is what's known as the client side of things.

For example, one common technique used to keep track of user data is to send information about the user's session (their username and so on) to the browser and expect it to be sent back. In other words, the site has the browser keep track of which user is interacting by having it announce their credentials each time it submits any information.

In times past, these credentials might have contained a whole shopping cart, meaning people could simply edit the values of cart items before pressing the checkout button, thereby managing to purchase items at rock bottom prices without the site owner realising anything was wrong.

This led to the upsurge in remote shopping carts, where the only information handled by the browser is an encrypted cookie, which is passed to a remote payment handling system such as Google Checkout or PayPal.

Perhaps worse is the use of obviously named, unencrypted variables in the URL, which are passed to a server-side script to tell it which user is interacting with it. Without appropriate checks, this can lead to serious vulnerabilities.

When I was a network security consultant, one assignment was to assess the internal security of a company's network. I found unencrypted usernames and passwords going by on the network and headed for an internal time management system with a web interface.

After using these to log in, I was dismayed to discover that the user's account number on the system was part of the URL. What happened if I incremented the account number by one? I got full read/write access to someone else's data.

Sometimes, however, variables in URLs can be exploited in benign, useful ways.

For instance, when searching for messages in a forum, you might be presented with a large number of pages and no quick way of going directly to one in the middle of the range. The URL might contain the page number or even the result number that begins the current page. Try modifying this and pressing [Enter] to see if you're taken to the page you want to access.

There are also plenty of other pieces of information that a site might expect to receive from the browser verbatim, which can be manipulated or simply read for the useful information they contain.

Many of these pieces of information are contained within hidden fields. All the hacker needs to do is edit the page's source code locally, re-read it into a browser and click the appropriate link to send it back to the server.

ON SHOW: Hidden variables embedded within a web page. What might these variables do, and what would happen if one was changed?

Consider a field called 'Tries'. As part of on a login page, there's a good chance that this contains the number of login attempts the user has made. Resetting it to '1', '0', or something like '-1000' could provide the hacker with a way of bypassing a three strikes login attempt rule if the server only checks that the variable has a value above three.

Fields that hold usernames and passwords are meat and drink to keylogging and other snooping software.

Input box names

Another vulnerability involved in having the client side keep track of the user's session is a web page that uses the same names for any input boxes each time.

While it may be convenient for the site's users, who can use autocomplete for web input forms and select from previous input box values, if they wander away from their computer without locking the screen, anyone can select from these lists.

If the browser also fills in passwords, an interloper can access pretty much any site where the user has an account. Banks have started randomising the names of input boxes to prevent this problem, but most privately owned commercial websites don't.

Never ask client-side code to keep track of a user's session using unencrypted data. Instead, use an encrypted session cookie to store a session ID, and keep track of the session in a back-end database.

LIMITED INPUT: Decide which inputs you will allow in an input field rather than trying toguess everything that a user may enter – deliberately or accidentally

Cross-site scripting vulnerabilities (or XSS for short) are a class of bugs that hint at how much ingenuity there is in the online security community. XSS vulnerabilities can allow malicious hackers to inject code into served web pages that in turn can steal server-side information.

An XSS attack takes the form of a malicious link to a third-party site embedded in a hyperlink. It might be sent in spam or embedded in a site itself.

This is possible because hyperlinks can contain parameters designed to pass information to the back-end server, such as the current session cookie.

It's possible to supply the value for a variable using the markup tag in the link. Clicking a link sets off the associated piece of JavaScript, which can, in theory, be stored anywhere. Here's an example:

The link is on 'www.sitea.com', and calls a script called 'login.cgi'. The 'cgi' refers to the Common Gateway Interface. This is a method of extending web server functionality to allow rich interaction with the user.

The script itself contains a header line, which tells the server the language it is written in, meaning that it can be written in any convenient language, such as PHP, Perl, or JavaScript. The server calls the interpreter and the script runs.

In the example, the script is passed a variable called 'profile'. This enables the server to obtain the value of the variable. However, a hacker has replaced this with a malicious script.

To load a value into the 'profile' variable, the script loads and execute the script 'steal.cgi', stored on 'www.attackersite.com'. This script has its own variable, called 'cookie', which will be loaded with the content of the current session cookie. This may contain the user's password and username, plus other credentials such as credit card information.

If it isn't well encrypted, this information can be read. The script on the server must not trust anything blindly, and should strip out all references to external sites. However, with Twitter, MySpace and Facebook all falling victim to this class of attack recently, it looks like XSS attacks will remain a threat for a long time.

------------------------------------------------------------------------------------------------------

First published in PC Plus Issue 303

Liked this? Then check out The hacker's guide to website security

Sign up for TechRadar's free Weird Week in Tech newsletter
Get the oddest tech stories of the week, plus the most popular news and reviews delivered straight to your inbox. Sign up at http://www.techradar.com/register

Follow TechRadar on Twitter * Find us on Facebook