JavaScript Injection Overview

JavaScript is a widely used technology within websites and web based applications. JavaScript can be used for all sorts of useful things and functions. But along with this comes some additional security issues that need to be thought of and tested for. JavaScript can be used not only for good purposes, but also for malicious purposes.

Using JavaScript an individual can modify and change existing information within a form. It can be used not only to change form input tags, but also the cookie’s that are currently set in the browser, and any other value within a website or web application. Any type of parameter manipulation that you want to perform can typically be done with Javascript injection.

To execute any javascript within a current session, a user would enter the specific javascript commands within the browser’s url bar minus the http://. All javascript commands must start with the javascript: tag followed by any javascript command that will be executed. All javascript is ended with a ; so a user could enter multiple javascript commands, as long as each command ended with the ;

JavaScript cookie modification

Using JavaScript a user can modify the current cookie settings. This can be performed with some basic JavaScript commands. To view the current contents of your current cookie/s, use the following JavaScript command. Put this in your browser’s URL bar.

javascript:alert(document.cookie);

This command will popup a box which lists your current cookies. A malicious user could use javascript to change values in the cookie. For example lets say a web application you are testing sets an authorization cookie to true when a user has successfully logged in and passed the authorization test. To change the values within the cookie, a malicious user would execute javascript like the following from the url bar within the browser.

javascript:void(document.cookie=”authorization=true”);

This would cause the current cookie parameter authorization=false to be changed to authorization=true. Which the malicious user might not have passed the original authorization test. The malicious user has just bypassed the authorization test and gained access to the sensitive content. As you could imagine, this could cause severe problems in privilege escalation, if the malicious user could use JavaScript injection to bypass the correct authorization process.

If you are testing for JavaScript injection and wish to see if the cookie has been altered you would execute a command similar to the following, except you would want to replace the cookie name and value with the cookie you desire to test. Start with the javascript command to alter the cookie and then tack on the javascript alert function to view what the cookie was changed to. For example

javascript:void(document.cookie=”authorization=true”);javascript:alert(document.cookie);

You should now be able to see the new cookie parameter in the popup box.

JavaScript HTML Form modification

You can also use javascript to modify any value with an html form, including hidden forms, and disabled forms. The following is an example of how you would set an input tag named email within form number 0 (or the first form on the page)

javascript:void(document.forms[0].email.value=”[email protected]”);

You will need to view the source code of the html page to determine what needs to be changed and how to change it. Verify the form number and set the correct number. The first form is always 0. Next look for the html tag you wish to change. Finally add the new value you want the html tag to be. This will allow you to modify the information within the html form.
How to protect against Javascript Injection

Always validate the input received against a whitelist. If you use a blacklist you could and probably will come up against encoding issues. Always use a whitelist when validating input.

Do not rely on client side validation to validate the user input. Client side validation is great for helping the user input correct data. But a malicious user will not use this and could bypass the client side validation. Client side validate is should never be considered as a security fix. Using javascript to validate input should not be used. As you can see javascript is very easy to change and modify on any html page.

Additionally validate the input every time, not just when the data is initially accepted. For example if you set a cookie, make sure that cookie is the same value and it is correct on each and every request. A malicious user could modify and change the value anytime during the session.

Injecting javascript into existing pages

Not only can you use javascript to manipulate parameters, cookies, but you can also inject javascript into dynamic pages to cause the page to render differently, do something else, or some other malicious thing. Think of a XSS attack.

Come back soon and we will post some examples of this.

Using JavaScript is difficult. Isn’t there an easier way?

Actually there is an easier way to test for any type of parameter manipulation you can do with javascript injection. Using some type of proxy that allows you to manipulate parameters on the fly is much easier. You can do this with a number of different applications. I’ve included a list of some of the proxy applications that allow you to do this.

* Paros Proxy
* TamperData

There are many, many more security testing proxy tools, this is just a short list of a few of the quick, easy, and nice tools to use.

Explore More

Chinese schools deny Google cyber-attack links

Two Chinese schools have denied the New York Times inform which they were involved in the much-discussed cyber attacks upon Google as good as during slightest 33 alternative outfits sometime

How to Hack a Window XP Admins Password

This is a cool little computertrick for Microsoft Windows trick I’ve picked up in my travels and decided to share it with you fine and ethical individuals =). Log in

How does the form-based authentication scheme work?

The form-based authentication scheme works in the following manner: * A client generates a request for a protected resource (e.g. a transaction details page). * The Internet Information Server (IIS)