Security Issues with JavaScript


Browsers such as Internet Explorer and Netscape Navigator put certain restrictions on what information scripts can access between frames and windows. For example, if window.close() method is implanted in a script page loaded into a browser that the user opened, then a message box will appear giving the user the option either to  cancel and engages the close() command or keeping the window open. Another example, if one window or frame hosted on one server tries to access the properties of a window or a frame that contains a page from a different server, then the policy of the browser comes into play and restricts that type of action from happening. The idea behind such restrictions is to prevent hackers from putting their pages inside the original page and extract unauthorized information where codes inside their pages are written for that purpose. For the above reason scripting across frames or windows are restricted by the security model implemented by the browsers. Such restrictions and other restrictions are implemented by a security model within the browser and within the JavaScript itself to eliminate any security gap (Wilton, 2000).

One of the solutions to secure the JavaScript from using it to write a malicious virus and run it on the client-side is to perform parsing of the code before execution. If the code can be parsed before execution i.e. having access to the stack, where control over the execution of the code can be achieved the malicious virus can be prevented. However, implementing such technique comes with a price which is the performance of the page and the website in general. By parsing JavaScript externally to determine whether the source code contains malicious code will ensue that the code is secure to be executed on the client. However, such process will impact performance of the web application. In trying to achieve such technique, another problem can be raised since the JavaScript is not confined code to a certain area of the XHTML document, it can be exist anywhere in the XHTML document. Other important point about JavaScript is that it is self-modify at run-time i.e. security threat might not be discovered in the actual code or the syntax that will be delivered to the client, but can be found in the script executed on the client. That put the parsing technique to another level where the execution of the script is required to secure it before deliver such code to the client (MacVittie, 2008).

JavaScript Hacking and Injection

With the above has been said, there’s no JavaScript proxy that can parse the script code and reject malicious script and solve the problem with malicious code. Malicious code hidden within the JavaScript can be only detected by certain pattern or signature. If parser for JavaScript exists as a security solution many of the malicious script can be prevented before it is delivered to the client. The only security solution that exists for the client is to allow or prevent the execution of the script and also the vendors for such browsers can do their best to tackle many security issues that can be written by hackers to prevent them from being executed on the client-side (MacVittie, 2008).

There is a case where hackers created an infected page on a legitimate website, that when it is visited by users it will run a JavaScript code that initiate a download of malicious code from another server that hold the malicious code. The users usually will be informed that the download is required in order to access the legitimate website where the software is actually harmful. Such attack can be used against fully patched computers. To prevent such attack a usage of browser with no-Script extension and proper security software can be a good solution of such attack (Kirk, 2008).

Another case where injected malicious JavaScript code was used to take advantage on several vulnerabilities exist on many e-commerce sites such as: ActiveX control remote code execution vulnerability, QuickTime file-handling remote command vulnerability, and memory corruption within Microsoft IE. With such malicious code it was too hard to determine within the JavaScript code the malicious code since the code where generating a random files that can be difficult to be searched. With such malicious attack, important steps should be taken toward securing such sites by following the software updates patches and being vigilant in doing business online (Carr, 2008).

Attackers adopted different techniques to hide the purpose of the malicious code by splitting the malicious code into different components and custom encoders to make the JavaScript code that was built for such purpose more confusing and obscure. Researchers warned about the future of implementing technology such as asynchronous JavaScript that allow interactivity to websites. With such technology any malicious software can be written by hackers in JavaScript and Ajax to compromise the security of users’ computers. The advanced techniques that were used to create a malicious code by JavaScript made the need for a solution of proper debuggers imperative to discover the problem before being spread around (Lemos, 2007).

TestingSecurity.Com (n.d.) explained that JavaScript injection commonly used by hackers to get information and changing information on the web page. Using JavaScript hackers can modify and change information within a form and read cookies currently set in the browser. For example, hackers can execute any JavaScript within a current session by entering JavaScript command with the browser’s URL bar without using the http:// part:

 i.e. JavaScript:alert(document.cookie);

The above command will view the current contents of the browser’s cookies. To change the values of the cookies, hackers can change the values of the cookies within the URL by executing the following command without the http:// part:


TestingSecurity.Com (n.d.) stated that attackers can test the changes by writing the command required to change the cookie and the command that display the changes in one command:


TestingSecurity.Com (n.d.) also explained that hackers also can use the JavaScript injection to change any value with an html form. All the hackers need is to view the source code, verify the form number and set any input tag. For example to set the input tag named “email” within a form the following code can be executed via URL:


Finally TestingSecurity.Com (n.d.) stated that to avoid JavaScript injection many action can be taken toward securing the website, some of these actions are:

  • Ensure validating any input that required user actions.
  • Avoid relying on the client side validation only, since such validation can be bypassed by hackers and JavaScript validation used to ensure the correction of the user input, and it can’t be considered a security fix.
  • Validation if inputs required by user should be done every time the input values are required.
  • Ensure that the cookies have the same value and the correct value every time it is request.

Finally, JavaScript not only manipulate cookies and parameters, but also, JavaScript can be injected to change the way the page is render. Another major problem can be created by malicious code of JavaScript, is when the actual malicious code can infect the web server. Seltzer (2004) explained that when IIS (Internet Information Services) infected by malicious code that can attack its vulnerability, any visitor to that site will be infected by the same malicious code once any of the site’s pages will be requested and downloaded to the client machine. Some of these malicious codes can install keystroke logger and other malicious code that can collect information about users, and the information stored on the client’s machine. In this case, users don’t have to click on any links or images to download such malicious code.


With the flexibility and the capability that exist within the JavaScript as an object oriented scripting language, hackers can use such tool to write their code that can run inside browsers on the client-side and cause harm to the users’ machines and their information stored in their machines. One of many concerns around JavaScript security issues are its capability of running code provided by the servers on the client’s machine. With such capability, hackers can bypass barriers exist between cross-site scripting. The problem with JavaScript malicious code is that it is difficult to detect security breaches since it happen usually behind the scene without any warning or noticeable effect. Perrin (2008) explained that some prevention measures have to be considered to avoid such attack, and some of these measures are:

  • Data that can represent any threats must be encoded (also called escaping or quoting) before being rendered on the client machine.
  • Deploying web programs that can enable users to be able to disable client-side scripting.
  • Users can disable running client-scripting for certain sites by using browsers setting. However, it’s difficult to assign such profile for certain sites.
  • Implementing the required validation system when users are submitting scripts.
  • Closing the vulnerabilities holes around cross-site scripting.


Carr, J. (2008) Attack injects malicious JavaScript into e-commerce sites [Online]. Available from: (Accessed: 27 February 2010).

Evers, J. (2007) Malicious code getting harder to spot [Online]. Available from: (Accessed: 27 February 2010).

Kirk J. (2008) Hackers place JavaScript attack code on Govt Website [Online]. Available from: (Accessed: 27 February 2010).

Lemos, R. (2007) Attackers improve on JavaScript Trickery [Online]. Available from: (Accessed: 27 February 2010).

MacVittie, L. (2008) Why it’s so hard to secure JavaScript [Online]. Available from: (Accessed: 27 February 2010).

Perrin, C. (2008) What is Cross-Site Scripting [Online]. Available from: (Accessed: 27 February 2010).

Seltzer, L. (2004) Attack on IIS Web Sites Infects Browsers With Malicious Code [Online]. Available from: (Accessed: 27 February 2010).

TestingSecurity.Com (n.d.) JavaScript Injection [Online]. Available from: (Accessed: 27 February 2010).

Wilton, P. (2000) Beginning JavaScript. 2nd ed. Birmingham: Wrox Press.



  1. 1
    Hout Bay properties Hout Bay properties Says:

    I’ve been browsing online more than 2 hours today, yet I never found any interesting article like yours. It’s pretty worth enough for me.
    In my opinion, if all website owners and bloggers made good content as you did, the internet will be much more useful than ever before.

  2. This is a topic that is close to my heart.
    .. Take care! Where are your contact details though?

  3. great post 🙂 I am so looking forward to seeing more posts!

  4. My teacher suggested this website and she is right.
    keep up your terrific work.

  5. First of all I want to say fantastic blog! I had a quick question which I’d like to ask if you don’t mind.
    I was curious to know how you center yourself and clear your thoughts prior to writing.
    I have had a tough time clearing my thoughts in getting my ideas out.
    I do take pleasure in writing but it just seems like the first 10 to 15 minutes
    tend to be wasted simply just trying to figure out how to begin.
    Any ideas or tips? Kudos!

  6. 6

    Sweet blog! I found it while searching on Yahoo News. Do you have any
    tips on how to get listed in Yahoo News? I’ve been trying for a while but I never seem to get there! Cheers

RSS Feed for this entry

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: