Related News

Security

IV. Hardening Steps to Mitigate Code Injection

by JUCC ISTF
/* The following article is extracted from the "Information Security Newsletter" published by the JUCC IS Task Force. */ 
 
Code injection attacks pose massive threats to the IT environment within universities. They could allow hackers to compromise universities' network, access and destroy their data, and take control of the information systems. As such, appropriate hardening steps should be in place to guard against these attacks. This can be achieved through development phase and environment configuration. Here are the guidelines:
 

1. Input Validation and Sanitisation

Injection attacks are performed by including special characters in the parameters sent from the client to the server. The most effective mitigation mechanism is to assume all user inputs are potentially malicious and perform data validation and sanitisation for all user-submitted input content before sending the queries to the server for execution. Here are some common good practices:

Validation Techniques

  • Identify allowable characters and white-list only valid characters;
  • Allow well-defined set of safe values via regular expression (e.g. [A-Z a-z 0-9]); and
  • Limit the length of each entry

Sanitisation Techniques

  • Analyze the user-supplied data looking for certain known patterns attacks, aided by different programming techniques, like regular expressions and MySQL's mysql_real_escape_string() function; and
  • Modify the received user input to adapt it into a harmless one which would reduce the false positive cases

Although validation may take place on the client side, hackers can modify or get around this, so it is essential that you also validate all data on the server side as well.

2. Appropriate / Least User Privileges

Web applications should never connect to your database using an account with admin-level privileges (e.g. "root" account). All application processes should be executed with the minimal privileges required. In addition, processes must release privileges as soon as they no longer require them. Best practice is to create an isolated account specifically for each application and deny access to all objects that are unnecessary to be used by the applications. 

3. Error Messages Handling

Hackers can learn a great deal about the system architecture from error messages, detailed error information can be used to refine the original attack and increase the chances of success for hacking. Therefore, it should ensure that they display as little information as possible. Besides, it is better to use the generic error messages on the local machine while ensuring that an external hacker gets nothing more than the fact that his/her actions resulted in an unhandled error.

Reference:

http://www.darkreading.com/database_security/security/app-security/showArticle.jhtml?articleID=227300073
http://www.enterprisenetworkingplanet.com/netsecur/article.php/3866756/10-Ways-to-Prevent-or-Mitigate-SQL-Injection-Attacks.htm
http://www.hkcert.org/english/sguide_faq/sguide/sql_injection_en.pdf

4. Escaping

Escaping is a technique used to ensure that characters are treated as data, not as characters that are relevant to the interpreter's parser. It is the primary means to make sure that untrusted data cannot be used to convey an injection attack.

For dynamically-generated query strings or commands, it should properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict white-list (such as everything that is not alphanumeric or white space).

5. Source Code Review / Scanning

To guard against the injection flaws, code writers should refer to their internal coding guideline or OWASP injection prevention cheat sheet during the development phase. In addition, code writers or reviewers can utilise source code scanning tools to review and look for injection flaws and then fix the vulnerabilities. Some useful scanning tools can be in marketplace included: UrlScan, WebInspect, Scrawlr, W3AF, LDAP Injector and JBroFuzz.

6. Web Application Firewall ("WAF")

A Web Application Firewall ("WAF") is an intermediary device that sits between a web-client and a web server. The WAF analyzes OSI Layer-7 messages (i.e. application layer) for violations in the pre-configured security policy. WAF applies a set of rules to the communication within the HTTP/HTTPS/SOAP/XML-RPC/Web Service layers and help to filter out malicious data and requests. In general, these rules cover common attacks such as cross-site Scripting ("XSS"), SQL Injection or session hijacking. In addition, WAF is particularly useful when using third party developed web applications as the modification of the application source code is not required.

7. Environment Patching and Hardening

The risks associated with code injections are escalated when the databases or operating system tied to the Web applications under attack are weak due to poor patching and configuration. In addition, the system administrator should be responsible for hardening the underlying database and the operating system by disabling unnecessary services and functionality.

Reference:

http://cwe.mitre.org/data/definitions/78.html
http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
http://www.enterprisenetworkingplanet.com/netsecur/article.php/3866756/10-Ways-to-Prevent-or-Mitigate-SQL-Injection-Attacks.htm

Summary

With the blooming of Web 2.0 over the past 5 years, most websites provide users with the choice to interact or collaborate with each other in a virtual community as creators of user-generated content such as Facebook, Blog, Wikipedia, in contrast to traditional websites where users are limited to the passive viewing of content that was created for them such as news pages. This kind of dynamic websites would bring code injection attack threat to the end-users since the user-supplied input is uncontrollable.
 
To safeguard universities websites and underlying databases and servers against code injection attacks, it is recommended to implement a series of security measure across different phases of the development and configuration processes. For example, inline with the coding guideline or hardening baseline, proper input validation and sanitisation, security scanning and environment hardening.
 
As a general conclusion, the fundamental principle to avoid code injection attacks is to mistrust all content submitted by users and always validate them before using to build a query or processing in the servers.