Countermeasures

According to some study, one of the main issues of still having code injection vulnerabilities despite the variety of protection tools and frameworks that are available is the lack of knowledge on developers’ about secure coding principles [2]. Yet another important concern is that organizations prioritize feature development before security fixes [2]. As a solution to this is suggested to provide training and increase awareness about security issues to both developers and organizations [1]. There are many projects designated to resolve this issue on lack of education and security experts. One of the very successful projects is OWASP WebGoat. This project is intended to train developers about many web security vulnerabilities and the ways on how to fix them. Lessons include real practicing attacks and code fixing countermeasures on a deliberately insecure web application.

The most effective way of Code Injection prevention and alleviation is by validating all the user input before processing it [3]. Likewise, the developer should also make sure that all the validations must be done in server side [4]. User input is entirely under users control and all the data sent from the browser can be tampered even when there are validations. Client-side (browser) validations will protect the application only from users’ mistakes and not from code injection [1]. Encoding the users’ data for escape characters is the first recommendation that developers should follow [5]. Besides encoding, another endorsed technique is to sanitize the input by removing potentially malicious code on input [6]. Moreover, defining strict rules for user input, like specifying input type and length can definitively minimize vulnerabilities or the impact of vulnerabilities [1]. This was emphasized even more by avoiding unnecessary input in the application will decrease the vulnerability surface [7].

There are many tools that implement the suggested protection mechanisms by the mentioned studies above. Particularly, one type of these tools is Web Application Firewalls. Past years Web Application Firewalls have grown significant demand [1]. These firewalls are constructed in a form of dedicated devices, server plugins, or filters that apply HTTP rules for protection against code injection [8]. Using such a tool has been proven that can mitigate over 70% of web vulnerabilities [1]. As the most recognized and used web application firewall is ModSecurity. This tool is developed to be used as an extension of web servers. ModSecurity gained a lot of popularity since it is free & open source, covers the majority of web server platforms and is very effective on protection against complex vulnerabilities [9].

Another relatively new protection mechanism is the introduction of HTTP headers against XSS. The most modern browser already have implemented this feature. Recalling the example of Reflected XSS attack on Job Portal website, the JavaScript was not being executed in Chrome browser, but it was on Internet Explorer. That is because Chrome’s XSS filter detected that the input in HTTP request was the same as the output on HTTP response. Therefore, it concluded that the code is being reflected, hence, it blocked the JavaScript execution. Anyway, this is a very proprietary mechanism and as we have seen we do not achieve the same results in different browsers. [10] [11]

OWASP AntiSamy

Considering the MySpace incident caused by Samy’s worm, discussed in the previous chapter (4.2), OWASP initiated and developed a project named AntiSamy. The projects intention is to protect applications against XSS vulnerability. This project, in fact, is actually a written code, served as a library. The idea behind this library is to properly encode HTML and CSS code on the user’s input. Encoding the input means that the escape characters in HTML and CSS code will be represented by some special characters. Browsers will recognize these characters and will treat them as a text value, thereby disabling XSS attacks. [12]

AntiSamy library technically is developed to be a ready-to-use API by any other application with the same technology specifics. Currently, it is available only for applications written in Java and .NET, and it is planned to be developed for Python and PHP. The goals for AntiSamy were to provide high assurance, be portable and give friendly feedback. In the same time, this library is very configurable in the context of allowing developers to add whitelists, policies and change the rules. This is very important since there are cases when applications want some user input to be a client-side code, but at the same time, they want to have some limitations as well to be secure. The initial versions were very stable except some issues to detect XSS with non-standard ASCII encoding. But in the later versions, these issues were fixed and currently there is not known any critical security issues. [12]

Web Application Frameworks (WAF) & Object-Relational Mapping Frameworks (ORM)

Developing and integrating applications with a Web Application Frameworks (WAF) properly will solve the majority of code injection issues. WAF instead of many features, also provide different ready-to-use and tested mechanisms for input sanitization and validation. Especially, they offer protection against vulnerabilities of SQL and XSS injections. [1]

Normally, WAF has some kind of Object-Relational Mapping (ORM) features included. If they do not include it as an out-of-the-box feature, they allow the developers to integrate it themselves with one of their choices. ORM’s intention is to focus the developer on application business logic, and not deal with database queries. Therefore, ORM’s automatically generate and execute SQL queries to represent the database data as programming objects. So the developer will use ORM programming methods to do data manipulation. All the executed queries from ORM are properly sanitized by encoding the escape characters unless it is explicitly configured by the developer to not do so. Besides that, all parameterized queries are executed as prepared statements in the database. This is a performance feature of the database which in itself also has the ability to differentiate the actual query and parameters. This will enable the database to clearly realize which part to treat as query code and which not. Moreover, by using ORM the developer most of the time does not need to write SQL queries itself, thus minimizing the risk of doing mistakes on input sanitization. In the table below, find some of the well-known WAF, their related ORM’s and the technology which were built upon.

Table 1 – Web Application Frameworks with their related Object-Relational Mapping

Usually, WAF’s including the ones mentioned above, besides SQL injection provide XSS protection as well. Depending on their configuration, they can disable XSS attacks by following different approaches. One approach is to sanitize user input by stripping off all the escape characters before storing them in the database. A similar approach is to encode the escape characters, instead of stripping them off. Both of these approaches may alter the user input before saving it, either by removing or encoding parts of it. Seeing that XSS attacks are successful only when output exists, there is another way to be protected from them. This solution differs from the first two by storing the input as it is, but encoding it only on output.

The first two solutions may take more time to process each request, but it will end up with less junk data in the database. While, with the last method, you may have junk data but you will also have the opportunity to do forensics investigation on the attacks.

Figure 7 – XSS Protection solutions on Web Application Frameworks

Wrap-Up

Defensive Techniques:

• Educate Programmers for Secure Coding Principles
• Company training to raise awareness
• Validate user input (on server side) strictly before processing it Limiting value length & type will help to minimize the attack impact
• Encode or remove the escape characters
• Try to use White-Listing over Black-Listing
• Use available Tools & Frameworks

Tools & Frameworks:

• Web Application Firewalls (e.g. ModSecurity, a web server extension)Proven to mitigate over 70% of web vulnerabilities
• Web Application Frameworks for any code injection
• Object-Relational Mapping (ORM) for SQL Injection
• Database (DB) Prepared Statements for SQL Injection
• OWASP AntiSamy for XSS Attacks
• New HTTP Headers defined for Web Security

References