Written by Ramón Saquete
Índice
In order to implement Webs with a good level of security it is necessary to know how they can be attacked. It should also be borne in mind that, even if the Web is totally secure, new attacks may emerge over time that can penetrate the defenses that have been set up. The best thing we can do to avoid these attacks is to always have the code updated and have measures in place to recover from the attack as quickly as possible and if Google labels us as an attacking page, ask for a review as soon as possible.
Each technology has its own weaknesses and the new ones bring new points of attack and, for this reason, I am going to expose the most known ones:
Code injection:
Code injection is about inserting malicious code into the Web, either client or server-side code. Thus we have attacks that inject HTML code, CSS, Javascript, SQL, PHP, server console commands, etc.
Some programmers only filter code injection in fields that are visible to the user, such as the URL or form fields. In addition, automatic tools for detecting security holes do not go much further. However, hackers can modify any parameter sent in the communication, whether it is in HTTP protocol headers, AJAX requests or hidden form fields. This is done with tools such as WebScarab, Paros or Burp that act as a proxy between the hacker’s browser and the server, allowing to see all the content of the communication and modify it on the fly at the attacker’s will. Hackers are very patient: if they want to attack a particular target, they can spend weeks or months looking for such vulnerabilities.
I will now outline, very briefly, 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 Web site, steal or delete information, make modifications to the Web site, or even take complete control of the server with all the databases and Web sites that exist on it. Typically, these attacks are carried out by using the single quotation mark, which closes a string in SQL, and “- -” which is used to place comments. Below is an original example to illustrate this type of attack, translated from the Webcomic xkcd:
The way to prevent these attacks is to use, at least, the filtering functions provided by the different development frameworks and always try to set the encoding of the page because if it accepts several encodings, they can bypass the filter by entering characters in UTF7.
XSS (Cross Site Scripting)
Javascript injection from other domains can be used to capture keystrokes, launch denial of service attacks, scan the user’s internal network, mount phishing attacks, obtain the user’s geolocation with HTML5 Javascript, etc. Although the most common is usually the theft of Cookies or other information that we can find in the new local storage features of HTML5, many times the attack is performed in order to enter the user’s administration area.
The way to do this is usually by entering code in fields that when sent are reflected on the Web. This type of attack can be persistent or not. Persistent attacks are persistent because they remain on the Web for all users after the attack has been carried out. Non-persistent ones require some social engineering to trick a particular user into clicking on a link prepared with the attack. The link can be a redirect that leads to a URL that has the attack in the Querystring or it can lead to a Web, that when loaded, automatically makes a form submission by POST with the attack.
Again, the form of to avoid this type of attacks is to filter all the entries with the available frameworks, although sometimes vulnerabilities are found that affect these frameworks and all the Webs that use them are exposed, as for example, the attack <%label> of some versions of the .NET framework. In addition, data URIs provide a new way to bypass these filters. In these cases there is no choice but to update the frameworks or the Web code.
On the other hand, to increase the security of Cookies containing session information, it is recommended to activate the HttpOnly flag and, in case of using HTTPS, also activate the Secure flag.
CSRF (Cross Site Request Forgery)
Cross-request forgery consists of getting the victim to click on a link created by the attacker when the victim is logged on to the Web, so that the link performs an action in his private area. For example, if to add a friend on Facebook, the URL would be something like http://www.facebook.com/addfriend.php?id=idusuario, the Forever Alone attacker could create the same link but with your user id and put it on your public Facebook profile. So if someone who is logged in clicks on the link you will be added as a friend.
The way to protect against such attacks is to add a hash, which is difficult to calculate and only valid for the current session, as a required parameter for the actions available to the logged-in user. This way another user cannot construct a URL with that parameter since he cannot know the hash.
With a mixture of this type of attack and the previous one, the worm became famous in 2005.
Samy, a virus that was introduced on the MySpace social network and spread to every person who visited the profile of someone infected. What it did was to add the profile of the author Samy, in a hero section. The virus spread to more than a million profiles in 20 hours, forcing Myspace to shut down the service in order to fix the problem. The author was sentenced to a rather cruel punishment: three years without using a computer. To its credit, we have the AntiSamy Web programming library, which is part of the OWASP (Open Web Application Security Project). This allows the user to enter some HTML tags without being able to perform XSS attacks.
Other types of attacks
- Brute-force password recovery: An attacker can obtain the password of a known user by trying all possible or most common passwords. The way to avoid this is to allow a maximum number of attempts to enter the correct password.
- Session ID theft: if the attacker can predict the next session ID to be given by the application, he will be able to impersonate the next user to log in. This has gained momentum in 2012, as PHP session identifier generators appeared to perform brute force attacks of this type. If the generated identifier is easily predictable, a hacker can detect it using an analysis tool such as the one provided by Webscarab.
- Exposed information: the database itself or the code (due to the use of the version control system) may be exposed to the attack, and can be retrieved from Google with Google Hacking Data Base attacks. We can also find comments in the code that give away the inner workings.
- Attacks on the server or your network: They are a world apart. Attacks on poorly protected servers can give the attacker access to the entire Web or allow DoS (Denial of Service) attacks to succeed. DoS attacks are usually performed by launching multiple requests to the Web server from different sites until the server crashes. The system administrator must be prepared with the appropriate tools to filter this type of attack, as well as having tools to detect intrusions to services such as FTP or SSH and to keep the server software up to date.
There are countless other attacks that affect all kinds of technologies such as Flash, SilverLight, LDAP directories, ActiveX components, Java applets, and many others applicable to various technologies, such as attacks on CMS’s and their plugins, attacks of buffer overflow, attacks SSRF, Spam bots that collect e-mails and fill out forms automatically, etc.
However, the weakest point is not the server or the Web programming, it is the user. If the user is very naive, he can be attacked regardless of the security we have in our Web. But if you’re vigilant about phishing attacks, are careful not to catch viruses, don’t use open or poorly protected Wi-Fi networks, and have an up-to-date browser, then you should have no problems.
