In part 1 of 'How websites get hacked' I started off by talking about why sites are hacked these days, what common attack methods there are and then I took a closer look at server level security and database security. In this part I'm going to focus on site code attacks which are the most common attack method.

 

CrossSite Scripting

CrossSite Scripting or XSS is the more complex of these two attack methods and requires a little more work by the attacker. There are three main types of XSS attack which all vary in difficulty. We'll focus on the easier and more common two attacks.

 

The concept of a XSS attack is simple: get some malious code to run in the victims web browser to steal or redirect data such as log-in credentials or sensitive data. This can be achieved because the browser is intellegent and can execute code independantly of the server. If you can trick the browser into executing code not sent from your server, or even trick the server into sending code to the browser that you didn't intend then you can execute an XSS attack.

 

XSS scenario A (Persistant)

In this scenario the attacker uses a form (such as a comments or contact form) to send some javascript or clever HTML to the server which is then stored in the backend database. When someone else (another logged in user for example) looks at the submitted comment, the malicious code is downloaded to their browser and run. This code might be a block of javascript which picks up the users session data (or even just what is showing on the screen at that time) and then sends it on to the attacker. This will happen for every user that views that comment potentially effecting a large group of people.

 

 

XSS scenario B (non-persistant)

This is slightly more difficult and requires some social engineering. The idea is that you might have something like a search engine on your site. When you type something into the search engine the results page might show you what you searched for (the untreated text you entered). An attacker could use this fact to send some code to the search engine which is then executed directly on the search results page.

 

You might think this is not a problem because only the person using the search engine is going to see the results page right? well, not quite. How about this scenario:

1. Bad GuyA gains access to part of a site which has billing details and also has some sort of order ID search.
2. Bad Guy A works out that the search facility can be used for XSS and constucts a URL which will submit malicious code to the order ID search facility processing funtion.
3. Good User B logs into the website to check the status of their order and whilst they are logged in Bad Guy B sends them an email containing the malicious link to click saying there has been a problem with their order and they have to fill in an information form
4. Good User B clicks the malicious link and it submits the XSS attack to the seach facility.
5. Using Good User B's authenticated session the XSS attack is run on Good User B's browser and accesses the billing details pages sending Good User B's billing details to Bad Guy A.

Follow that? its a little tricky to get your head around and requires some co-ordination and social engineering but it does work and has been used successfully by attackers on many websites.

 

SQL injection

This type of attack is a bit more common and is easier to execute on many sites. It relies on the target site having a backend database which contains user information or sensitive data. SQL is a programming language which is generally used to tell databases what data to select and send back to the user.

 

This method of attack sends malicious SQL to the database through a web form such as a contact form, comments form or search form. The idea is that the malicious SQL will subvert the normal database actions of the form and force the database to return something sensitive like passwords or billing data which will then be sent back to the browser.

For the attack to be successful several factors must be present:

• If the SQL fails and the database sends an error back to the browser the attacker can use this error message to deduce the structure of the database through a trial and error method. If the error message is hidden then the attacker has no idea if they are getting close or not.
• The output from the target form could be subverted and forced to display data that the developer never intended like usernames and passwords instead of telephone numbers and addresses. Make sure the output script is designed only to output certain information and that the SQL the form uses only returns the information that is absolutely required from the database instead of getting all the columns in the database table.

 

Defending against these attacks - Validation

You can take several simple steps to defend against both of these attack methods. The simplest and most effective method of shoring up your application code is to thoroughly validate any input that comes from the browser through forms and query strings (the bit after ? in the URL). You can do this by taking an exclusive approach, this means:

 

• Only letting through values and data-types you expect to see and discarding anything which doesn't fit the pattern (e.g. dont accept a sting value when you're expecting a numeric).
• Actively strip any input of HTML tags using regular expressions.
• Check specifically for script blocks and strip them out.
• Use regular expressions to match email addresses and postcodes/ZIP code form inputs.
• Escape quotes at all costs, many scripting languages will have a built-in method for doing this
• Insert data in to the database using something like a prepared query rather than constructing raw SQL strings. This should automatically help to strip quotes and other nasties.
• If your script/application does error for any reason, be sure to hide any error messages from the user. This gives the hacker far less information to play with.

Database Access

Conclusion

It can be easier than you think to do SQL injection or XSS but by using at least some of the methods above you make life much harder for any potential crackers. Validating input is crucial and that will go a long way to preventing the bad guys from getting in.

In the next part I'm going to take a look at social engineering and see what practical measures you can take to stop your staff from give away the keys to the kingdom.