Test and Prevent JS Injection Attacks on Website

What is Javascript Injection?

Javascript is one of the most popular technologies and is most widely used for web pages and web applications.

It can be used for realizing different website functionalities. However, this technology can bring some security issues, which the developer and tester should be conscious about.

Javascript can be used not only for good purposes but for some malicious attacks too. One among that is Javascript Injection. The essence of JS Injection is to inject the Javascript code, that will be run from the client-side.

Risks of JavaScript Injection

JS Injection brings a lot of possibilities for a malicious user to modify the website’s design, gain website’s information, change the displayed website‘s information and manipulate with the parameters (for example, cookies). Therefore this can bring some serious website damages, information leakage and even hack.

The main purpose of JS Injection is to change the website’s appearance and manipulate the parameters. Consequences of JS Injection can be very different – from damaging website‘s design to accessing someone else’s account.

Why is it Important to Test JS Injection?

Many would ask if testing for JS Injection is really necessary.

Checking for JS Injection vulnerabilities is a part of security testing. Security testing is usually performed only if it was included in the project planning, as it requires time, a lot of attention and checking multiple details.

I have noticed, that during project’s realization it is quite common to skip testing against any possible attacks – including JS Injection. This way the teams try to save the project’s time. However, this practice very often ends with customer’s complaints.

It should be known, that security testing is highly recommended even if it is not included in the project plans. Checking for main possible attacks should be performed – at the same time must check for possible JS Injection vulnerabilities.

Leaving simple Javascript Injection vulnerabilities in the product may cost product’s quality and company’s reputation. Whenever I have learned to test against possible attacks and in general security testing, I never skip this part of testing. This way I am just more sure about the product’s quality.

Checking for JavaScript Injection

When you are starting to test against JS Injection, the first thing you should do is to check if JS Injection is possible or not. Checking for this type of Injection possibility is very easy – when navigated to the website, you have to type in the browser’s address bar code like this:

javascript:alert(‘Executed!’);

If a popup window with a message ‘Executed!’ appears, then the website is vulnerable to JS Injection.

Then in the website‘s address bar, you can try various Javascript commands.

It should be mentioned, that JS Injection is not only possible from the website’s address bar. There are various other website‘s elements, that may be vulnerable to JS Injection. The most important thing is to know exactly the parts of the website which can be affected by Javascript Injection and how to check it.

Typical JS Injection targets are:

• Various forums

• Article‘s comments fields

• Guestbooks

• Any other forms where text can be inserted.

To test if this attack is possible for the text saving form, despite providing normal text, type Javascript code as mentioned below and save the text in the form and refresh the page.

javascript:alert(‘Executed!’);

If in the newly opened page includes a text box with the message ‘Executed!’,  then this type of injection attack is possible for the tested form.

If in both the ways a text box with the message appears, you can try to break the website with more tricky JS Injection methods. Then you can try different injection types – parameters modification or design modification.

Of course, parameters modification is considered as a riskier one than design modification. Therefore, while testing more attention should be dedicated to the parameters modification.

Also, it should be kept in mind, that more vulnerable website‘s parts for Javascript Injection are input fields, where any type of data is saved.

Parameters  Modification

As mentioned earlier, one of the possible JavaScript Injection damages is parameters modification.

During this injection attack a malicious user can gain parameters information or change any parameters value (Example, cookie settings). This can cause quite serious risks as a malicious user can gain sensitive content. Such type of injection can be performed using some Javascript commands.

Let’s remember, that Javascript command returning current session cookie is written accordingly:

javascript: alert(document.cookie);

Entered in the browser‘s URL bar, it will return a popup window with current session cookies.

If the website is using cookies, we can read such information as server session id or other user data stored in the cookies.

It has to be mentioned, that instead of alert() any other Javascript function can be used.

For Example, if we have found a vulnerable website, that stores session id in the cookie parameter ‘session_id‘. Then we can write a function, that changes current session id:

javascript:void(document.cookie=“session_id=<<other session id>>“);

This way the session id value will be changed. Also, any other ways of changing parameters are also possible.

For Example, a malicious user wants to log in as other people. To perform login, the malicious user firstly will change authorization cookie settings to true. If cookie settings are not set as “true“, then cookie value can be returned as “undefined“.

To change those cookie values, a malicious user will perform according to the Javascript command from the URL bar within the browser:

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

In the result, current cookies parameter authorization=false will be changed to authorization=true. This way a malicious user will be able to gain access to the sensitive content.

Also, it has to be mentioned, that sometimes Javascript code returns quite sensitive information.

javascript:alert(document.cookie);

For Example, if a website‘s developer wasn‘t cautious enough, it can return username and password parameters names and values also. Then such information can be used for hacking the website or just changing the sensitive parameter’s value.

For Example, with the below code we can change username value:

javascript:void(document.cookie=”username=otherUser”);

This way any other parameters value can also be modified.

Website’s Design Modification

Javascript can also be used to modify any website‘s form and in general the website’s design.

For Example, with Javascript you can change any information displayed on the website:

• Displayed text.

• Website’s background.

• Website form’s appearance.

• Popup window’s appearance.

• Any other website element’s appearance.

For Example, to change the displayed email address on the website, appropriate Javascript command should be used:

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

Few other complicated manipulations with the website’s design are also possible. With this attack we can access and change website’s CSS class also.

For Example, if we would like to change the website’s background image with JS Injection, then the command should be run accordingly:

javascript:void(document.background-image: url(“other-image.jpg“);

Also, a malicious user may write Javascript Injection code which is mentioned below in the text inserting form and save it.

javascript: void (alert („Hello!“));

Then every time when a page is opened, a text box with the message “Hello!“ will appear.

Changed website‘s design with Javascript Injection is less risky than parameters modification. However if website‘s design will be changed in a malicious way, then it can cost company‘s reputation.

How to Test against JavaScript Injection

It can be tested in the following ways:

• Manually

• With testing tools

• With browser plugins

Possible Javascript vulnerabilities can be checked manually if you have good knowledge of how it should be performed. Also, it can be tested with various automation tools.

For Example, if you have automated your tests at the API level with SOAP UI tool, then it is also possible to run Javascript Injection tests with SOAP UI.

However, I can only comment from my own experience, that you should have really had good knowledge about SOAP UI tool to test with it for JS Injection, as all the test steps should be written without mistakes. If any test step is written incorrectly, it can cause wrong security testing results as well.

Also, you can find various browser’s plugins for checking against possible attack. However, it is recommended not to forget to check against this attack manually, as it usually returns more accurate results.

I would like to say, that testing manually against Javascript Injection makes me feel more confident and assured about the website’s security. This way you can be sure, that no form was missed while testing and all the results are visible to you.

To test against Javascript Injection you should have general knowledge about Javascript and must know which parts of the website are more vulnerable. Also, you should remember that website may be protected against JS Injection and while testing you should try to break this protection.

This way you will be sure if protection against this attack is strong enough or not.

Possible Protection against this attack

Firstly, in order to prevent this attack, every received input should be validated. Input should be validated every time, and not just when the data is initially accepted.

It is highly recommended not to rely on the client side validation. Also, it is recommended to perform an important logic in the server side.

Many try to protect against Javascript Injection by changing the quotes to double and Javascript code should not be performed in that way.

For Example, if you would write into the comment field anything with quotes <script>…<script/>, those quotes will be replaced with double – <<script>>…<</script>>. This way the entered Javascript code will not be executed.

I have noticed, that replacing quotes by double quotes is a quite common practice to avoid possible JS Injection attacks. However, there are a few ways to encode the quotes to make JS Injection code performed. Therefore changing quotes to double is not a perfect way to protect against this attack.