Javascript - Bad parts

When you know what is the right thing to, you cannot do the other way.

Well, the above quote fits very well for what I’m going to write here. After reading through Douglas Crockford’s Javascript - The Good part, it was so evident that how much of bad javascript we coding in the projects. Learing the bad parts is as equlally important as to learn the good parts.

I’m trying to summarize the javascript semantics used in bad way due to misunderstanding. Some of them has been learnt from Doug’s book and some from my experience.

Make educated decision on using eval()

Most of them who uses javascript argues eval() is evil but not everyone has an understanding of why it is evil and how much evil it is and there is another school of thought that eval() is required. So it is very important to make a learned decission to use or not-use eval() function.

Why is it so?

Consider this example.

var Namespace = ... //create a namespace Namespace.module.class
Namespace.module.class.x = 1;

Now if you want to set a value to new variable y to the class object

eval('Namespace.module.class.y = 2')

So what is wrong in this?

First and foremost issue is security and correctness of your application.

Let us look how it affects the security.

Say you have a webpage which uses the url param values in it. eg:

and in your webpage you are using the params like this

var paramName = "page"
eval("Namespace.module.class" + paramName + "=" + value)

Now, if instead of page=2, if someone passes alert(1), then the script will get executed. No harm in simple script, but think of a malicious code gets injected. This is a good example eval() bug in firefox

some ways to avoid is to use () while executing to keep the scope limited to the (). Curry the javascript function.

Your script execution becomes slow

Browser has to instantiate a new Javascript interpreter environment to compile the string program you have just passed in.

debugging of scripts executed via eval is difficult.

You cannot expect browser to provide debug mechanism for scripts executed via eval. Incase

thought eval() based attacks are old fashioned, but it still exploitable. So make sure to use appropriate measures to stop exploiting.

cautious usage of equality == , === & inequality !=, !==

== operator works in different ways based on the type.

> x = undefined
> x == null
> x === null

Another common issue everyone knows is how javascript works while comparing string to numbers. > 1 == ‘1’ true > 1 === ‘1’ false

> 0 == '0' //quite interesting

So, what do you think when you use

> 0 ? "true" : "false"
> "0" ? "true" : "false"

Isnt it quite messy? we just observed above that 0 == '0', but the ternary operator says other wise. Hence while using the == operator be cautious of what you are comparing.

> [ ] == [ ]
	false //correct as two instance of array objects are created
>[].toString() == [].toString()
	true //because value of the arrays are converted into comma seperated value and compared

Unary + & -

Unary operator helps in converting a string to number( integer or float ). But this is not a good choice to convert it.

> +'0'
> +"123.123"


First of all it is not a good standard to use. Secondly, consider this scenario which gives inconsistent behaviour. A function (in this case to convert string to number) should be used only if it is consistent in providing output. hence unary + & unary - cannot be used as function to convert string to number.

> a="-123.123"
> -a
> +a

scope of this

this should be used with caution. Why? Because in the scrpting language, the reference of this may go wierd. This like.

function f()
    var val = 10;

If you think it is 10, then I would recommend you to read about this

Also I recommend reading what Nils Jünemann findings on Gmail XSS bugs. This is an eye opener for anyone who doesn’t want to write bad javascripts.

Let me know what was the bad part of javascript that you have used and how did you fix it?

Published on: