How to protect your website from hacker attacks

Written by Ramón Saquete

If you want your websites to have a good security level, it’s important to know in advance how they can be attacked. You must also keep in mind that, even when your website is completely protected, after a certain amount of time, new attacks can emerge and penetrate the defences you previously created. The best thing we can do to avoid these attacks is to keep our code always updated, and to design measures that will allow us to recover from these attacks as quickly as possible. If Google flags our website as an attacker, we must also request another review as soon as possible.

Each different technology has its own weak spots, and with new technologies new attack points inevitably appear. In this post we are going to expose the most common ones:

Code injection:

Code injection consists in injecting malicious code into a website, and it can affect client side code and server side code. This means we could face attacks that inject HTML, CSS, JavaScript, SQL and PHP code, as well as server console commands.

Some developers only filter code injection in fields which are visible to users, namely the URL address or form elements. Moreover, automatic tools for detection of holes in security don’t go much farther. However, hackers can modify any parameter sent through the communications channel, be it in the HTTP protocol headers, AJAX requests, or hidden form fields. This is done with WebScarab, PAros or Burp tools, which act as a proxy between the hacker’s browser and the server, allowing the attacker to see all content and modify it that very moment in any way they like. Hackers are very patient: if they want to attack a specific target, they can spend weeks, and even months searching for vulnerabilities of this kind.

In the following paragraphs we’re going to explain –in very general terms– the most common code injection attacks and how to prevent them:

SQL injection

SQL code injection can be used to gain access to the private area of a website, to steal or to delete information, make modifications, and even to take complete control of a server, including all data bases and websites that are on it. These attacks are usually carried out using a single quote, which closes an SQL chain and the “- -” that is used to make comments. Here’s an original example illustrating this type of attacks, taken from the xkcd webcomic:

The way to prevent these attacks is to use, at the very least, the filtering functions provided by development frameworks, and to always try to establish a unique character encoding, because if it accepts several different ones, the attacker can circumvent the filter by introducing UTF-7 characters.

XSS (Cross Site Scripting)

JavaScript code injection coming from other domains can be used to capture keystrokes, launch Denial of Service (DoS) attacks, scan the internal user network, mount phishing attacks, obtain a user’s geolocation through HTML5 JavaScript, etc. Even though the most common attack is usually cookie theft, or of any other information that can be found in HTML5’s new local storage features, way too many times the attack is made with the purpose of entering users’ administration area.

These attacks are usually carried out by entering code into fields that can be seen on the website. This kind of attacks can be persistent or non-persistent. If they are persistent, it is because they can be seen by all users who are visiting the website, after the attack has been made. Those, which are non-persistent require a little more “social engineering” to trick a particular user into clicking on a link leading to a previously prepared attack. This link will possibly redirect to a URL carrying an attack within its Querystring, or it could redirect to a website, which upon downloading, may automatically send a form with the attack through POST.

Again, the best way to avoid this kind of attacks is to filter all entries with the available frameworks, although sometimes there are vulnerabilities affecting these frameworks and every website using them becomes exposed. To put an example, here we can name the <%tag> attack that affects some .NET framework versions. Moreover, data URIs provide a new way to skip these filters. In these cases, we’re left no other choice but to update frameworks or our website’s code.

On the other hand, in order to increase security of cookies containing session information it is highly recommended to activate the HttpOnly flag, and in the case of HTTPS, the Secure flag as well.

CSRF (Cross Site Request Forgery)

Cross site request forgery consists of making a victim click on a link created by the attacker, when said victim has opened their session on a website, so that this link performs a specific action in their private area. For example, if the “add friend on Facebook” URL was something like this: http://www.facebook.com/addfriend.php?id=userid, the Forever Alone attacker could create the exact same link, but with their user ID, posting it on their Facebook public profile. This way, if someone who’s logged in clicked on the link, they would add the attacker as a friend.

To protect ourselves from this sort of attacks, we can add a hash –which is difficult to calculate and should only be valid for the current session– as a required parameter for actions that a registered user can perform. This way, another user cannot build a URL with this parameter, as they can’t find out what the hash is.

It was due to a combination of this sort of attack with the previous one (XSS) that computer worms became famous in 2005.

Samy, a virus that propagated across MySpace social networking site, affected every person who visited an infected user’s profile. What it did was add Samy’s profile to the user’s friends list, amongst other things. This virus spread to over a million MySpace profiles over the course of only 20 hours, forcing the website to shut down its service in order to solve this issue. The author of this virus was sentenced to a rather cruel punishment: to spend 3 years without using a computer. To honour them, a programming library was created under the name of AntiSamy, as part of the OWASP project (Open Web Application Security Project). It allows users to enter certain HTML tags, so as to escape XSS attacks.

Other kinds of attacks

• Password recovery after a brute-force attack:  An attacker can obtain a user’s password by trying out as many passwords as possible, or by entering the most frequently used ones. One way to avoid this, is to establish a limit on the maximum number of attempts that a user can enter the correct password.
• Session ID stealing: if an attacker can predict the next session ID that an application is going to issue, they will be able to impersonate the next user who is going to log in. This tactic reached its peak in 2012, after PHP session ID generators appeared, for the purpose of carrying out this sort of brute-force attacks. If generated identifiers are easily predicable, a hacker could detect the flaw using an analysis tool, like the one provided by Webscarab.
• Exposed information: the data base and the code themselves could be exposed (due to version control system use), and they can be recovered from Google Hacking Data Base. We can also find comments within the code that might give away its internal functioning.
• Server or network attacks: these are an entirely different world. Attacks to poorly protected servers could give the attacker access to the entire website, or to allow DoS attacks to succeed. DoS attacks can be carried out by shooting multiple requests to a web server from several different places, until the server gives up. A system administrator must be prepared, having all the necessary tools at their disposal to filter this kind of attacks, in addition to tools to detect intrusions to FTP or SSH services, and try to maintain the server’s software as updated as possible.

There’s a infinite number of attacks affecting all sorts of technologies, namely Flash, SilverLight, LDAP directories, ActiveX components, Java applets; and many others, which can be applied to several different technologies at the same time, like attacks to content management systems and their plugins, buffer overflow attacks, SSRF attacks, spam bots that collect e-mails and fill in forms automatically, etc.

However, the weakest spot isn’t the server or a website’s programming, but the user. If a user is naive, he could be attacked, regardless of how well our website is protected. However, if our users are warned against phishing attacks, are careful enough to stay away from a virus, don’t use open or poorly protected Wi-Fi networks, and keep their Internet browsers up to date, they shouldn’t run into problems.