In a programmer’s mind

Javascript is a wonderful language. My first opinion of it was quite bad. It seems like it was a language to perform simple client-side operations within browsers.

Today, it is powering web 2.0 applications, it is a core component of firefox and it is use to power flex/air applications. Most commercial websites use at least one bit of Javascript on their pages. They are often using at least Google Analytics which is based on Javascript. It is becoming a de facto standard for web programming.

What is wrong with it? Nothing to be honest but there are some pitfalls. Some browsers have different implementations and have more a less a permissive view of how it can be used within a web page.

To this day, many web developers are falling into the Cross-site scripting (XSS) trap. It can be defined as:

[...] a type of computer security vulnerability typically found in web applications which allow code injection by malicious web users into the web pages viewed by other users.

It might seems quite broad but it is a good definition. Injecting code into web pages viewed by others users. Most of the time, it is Javascript code that is injected. Many popular web applications have had some kind of holes related to this security issue. My guess is that we are just seeing the beginning of it.

How does it work? First a all, a malicious user must be able to inject code into a page. For example, a web developer created a login page for his application. On his login page, there are two input boxes: the login name field and the password field. When a user enter an invalid login, the page display the following information: “The login name {login} is invalid. Please try again.” where {login} is replace by the text that was entered in the login name field. Here is a visual representation.

If no filter is applied to the login name field content that is inserted in the error message, there is a potential code injection. If you enters the following content in the login name field, you might see a message box.

<script>alert("test");</script>

This is a simple example of how a malicious user might be able to inject code into a web page. But how can this be seen by others? For the purpose of this example, let’s assume that on the server side, post and querystring values are mixed and are used that way. It is impossible to determine if a value is from a querystring or from a form using the method post. This is similar to the use of the mixed collection $_REQUEST in PHP or similar concepts in other server-side languages or frameworks. In this case, a malicious user could craft a URL and pass code into the querystring. Something like http://vunerable.website.com/login-form.dhtml?login=%3Cscript%3Ealert(%22test%22);%3C/script%3E . All that is left is to make an other user open the link either by sending it by email or pasting it on a forum or a blog.

This example is quite simple and assume that the developer is not careful about how he is adding user content into his web pages. Cross-site scripting security examples are numerous. Even for developers that are careful, it is easy to fall in the trap. Even if your web application is not using Javascript, you might be a target for a potential malicious user. Other examples involve storing some data in a database to be later seen by an administrator user, hijacking the session cookie on a remote server with ajax and forging a session.

It is quite easy to prevent text injection by using a function that html encode every characters. The problem is that text injection is not the only vector for script execution. There are many more available on different browsers depending on how is was implemented.

Be careful, very careful.