You might have heard that the United Nation Web site was hacked Sunday morning. As of Sunday evening was still open to attacks.
What is surprising (or is it?), is that it was easily hacked through a SQL injection attack. If any self-called Web developer were to tell me they don’t know what SQL injection is, I would tell them to change career.
A typical SQL injection attack is made possible when an application does not filter SQL escape characters for character strings. When SQL statements are constructed, string delimiters are inserted in the statement to change the statement or terminate the statement and execute other SQL statements.
For example (typical examples from Wikipedia):
sql = "SELECT * FROM users WHERE name = '" + userName + "';"
This statement checks for a user name (it could also check for a password). As you see, the userName variable is concatenated to the string and surrounded by quotes, the usual literal string escape character in SQL. However, such code is very poor and open to attack because if userName comes from a user input, the user can inject additional quotes by supplying something like:
a' or 1=1
When reconstructed by the deficient code, the SQL statement becomes:
SELECT * FROM users WHERE name = 'a' or 1 = 1;
If that statement was used for some kind of authentication mechanism, it would always be true and the system might open content that was not intended for the current user.
In the case of the UN web site, one of the original Web pages that was hacked can be viewed here.
The titles for the latest speeches were changed to “Hacked By kerem125 M0sted and Gsy
That is CyberProtest Hey Ýsrail and Usa
dont kill children and other people
Peace for ever
No war”.
The Web site was probably hacked through one of the speeches Web page, which have a URL as follows:
http://www.un.org/apps/news/infocus/sgspeeches/statments_full.asp?statID=105
As you can see, this kind of hyperlink takes the parameter:
statID=105
Well, by simply appending a quote to this URL, anyone was able to access their database with the security permissions of the Web application. So, the hackers were able to insert (or update) different speeches that are supplied from the database by concocting their own SQL statements.
It now seems that a filter has been installed on their server, because if you try this URL, you connection will be reset and you will not reach their Web server. Some basic Web security filter will filter out URLs that seem suspect and URL with quotes in them are rarely used and stopping these can mitigate these sort of attacks.
This might stop this attack, but if they had data entry forms with similar holes, they would still be open to attack. URL filtering would not stop these. You might put a plaster to try to protect a Web site, but in this case, the plaster has not been applied to other Web sites. For example, at this very moment, other Web sites are open to the same basic amateur holes. For example, the UNEP (United Nations Environment Programme), has also been defaced, probably through the same techniques.
Good security implies different layers of security. At the entry point of the network, you need good firewalls with filtering and intrusion detection systems and fully patched systems. But if the application opens up the database through programming holes, these are not worth much.
What’s more damning for an institution or a company that faces humiliation through such public attacks is that basic programming techniques would easily have avoided these holes in the first place:
- For performance and security reasons, it is recommended to use prepared SQL statements instead of dynamically building strings. All modern database engines support prepared statements.
- As an alternative to point #1, string inputs could filter escape characters. However, since most databases support multi-byte character sets and different character set settings, it can be quite easy to still leave some character escaping holes opened. If you need to do this instead (you don’t!), you would need a model that ensures that all input strings are correctly filtered. Leaving this task to the Web page developers will certainly leave some holes opened.
- There is a debate about using stored procedures, but by parameterizing inputs and forcing types, user inputs can be correctly filtered. Evidently, to avoid most holes, you would still need to use prepared statements to call stored procedures.
- A good object-oriented approach will also close some holes. In the example of the UN, the parameter is an integer corresponding to the identifier of a record. A typical entity class would necessitate to use integer properties and lookup methods that only accept integers to search by identifier. Therefore, by using strong types and forcing type conversions, this particular attack would not have happened.
- A 3-tier architecture will isolate the database access functions in separate layer. It does not stops vulnerabilities, but having the database facing code isolated helps to avoid adding new vulnerabilities.
- A model-view controller architectural pattern can further isolate the interface from the database.
In Web applications and Web sites, many more vulnerabilities can be made possible though amateurish programming:
- Incorrect use of hidden form fields. In HTML forms, hidden fields in forms can be quite useful. When used by amateurish programmers, they are dangerous. For example, I once stumbled on a shopping cart that used hidden fields for the prices of the products sold. By simply saving the HTML of the page to my desktop and changing the prices, I could have ordered the products with my own user-defined pricing injection! Fortunately for the company, it was before publishing of the web site and they called me to check the Web site. When it took me 5 minutes to find the hole and came back to them with my findings. The next thing I heard was that the developing company was fired and I would doubt they got paid.
- Incorrect use of cookies. When a Web application relies on cookies, it must be very careful about what is stored in the cookie. For example, a poorly developed web site could simply store a user id in the cookies for a “remember me” option. Then, a malicious user might change that identifier to something else and even maybe change his access to a user that has administrative access to the application. In that case, storing the identifier directly is a very bad idea. To at least avoid impersonating other users (without access to their computers), a secret random-like key could be stored. Still, someone with access to the computer could still do damage. Because of this, pages that give access to or allow to update sensitive information should be protected by asking the user to be authenticated, independently of a “remember me” option. There are a lot of different strategies to mitigate the risks of cookie usage.
- Code injection. Even if your application prevents SQL injection holes, it might still be vulnerable to certain types of code injection attacks if you allow user inputs. For example, with community features like discussion forums, the application needs to filter inputs to avoid Web site defacement through injection of HTML or Javascript code.
Application security is a serious matter and is more complex than what I can go in depth in this blog. I’ve noted a couple of beginner’s mistakes, but there is much more than this.
More often than not, especially for small businesses, Web projects will go to the lowest bidders that are not necessarily professionals in the domain. This approach can be risky. I wonder how much the UN paid for their Web sites… I wouldn’t think they would go to the lowest bidder. But, even when paying the right price, you can get more than what you bargain for. It is important to correctly research the credentials and experience of the developers that will do the coding.
An institution like the UN would at least need to get an independent consultant that know the right questions to ask the developers to verify that they do apply the best practices in their development.