JavaScript Injection Tutorial: Testing JS Injection Attack

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 them is Javascript Injection. The essence of JS Injection is to inject the Javascript code that will be run from the client-side.

JavaScript Injection Tutorial

In this tutorial, we will learn more about how to check if Javascript Injection is possible, how JS Injection can be performed and what are the consequences that JS Injection can bring.

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 damage, 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 a 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 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 the 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 the 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 the 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.

Comparison with other Attacks

It should be mentioned, that JS Injection is not as risky as SQL Injection, as it is performed on the client side and it does not reach the system’s database as it happens during SQL Injection attack. Also, it is not as risky as an XSS attack.

During this attack at times, only the website’s appearance can be changed, while the main purpose of XSS attack is to hack others’ login data.

However, JS Injection can also cause some serious website damage. It can not only destroy website’s appearance but also become a good basis for hacking other people’s login data.

Recommended Tools

#1) Acunetix

Acunetix is a web application security scanner that can identify 7000 vulnerabilities like exposed databases, out-of-bound vulnerabilities, weak passwords, etc.

All the web pages, web apps, and complex web applications including the application with multiple JavaScript and HTML5 can be scanned by Acunetix. It scans at a lightning-fast speed and verifies whether the vulnerabilities are real or not. This application security testing solution makes use of advanced macro recording technology.

Acunetix has automated functionalities such as scheduling and prioritizing the scans, managing identified issues, and scanning new builds automatically.

#2) Invicti (formerly Netsparker)

Invicti (formerly Netsparker) offers a web application security scanner that is automated as well as fully configurable. It can scan websites, web applications, web services, etc. It identifies security flaws.

It has functionalities for exploiting the identified vulnerabilities automatically in read-only and safe mode. It confirms the identified issue in this way and also gives proof of the vulnerability. It can identify all forms of SQL injection.

While scanning, Invicti can identify JavaScript files and provide a list of them through the Knowledge Base panel. This helps security professionals by ensuring that all JavaScripts on the target website are secure. Professionals can check them manually.

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 the 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 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 comment fields
• Guestbooks
• Any other form 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 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 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 riskier than design modification. Therefore, while testing more attention should be dedicated to the modification of the parameters.

It should also be kept in mind that the most vulnerable website parts for Javascript Injection are input fields where any type of data is saved.

Parameter Modification

As mentioned earlier, one possible Javascript Injection damage is parameter 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 a type of injection can be performed using some Javascript commands.

Please remember that the Javascript command returning the current session cookies is written accordingly:

javascript: alert (document.cookie);

Enter the browser’s URL bar and a pop-up window will return with the current session cookies.

If the website is using cookies, we can read information such 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 ids in the cookie parameter ‘session_id‘. Then we can write a function that changes the current session id:

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

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

For example, a malicious user wants to log in like other people. To perform a login, the malicious user will first change the authorization cookie settings to true. If cookie settings are not set as “true“, then the 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“);

As a result, the current cookies parameter authorization=false will be changed to authorization=true. This way a malicious user will be able to gain access to 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 developer isn’t cautious enough, it can also return username and password parameters, names and values. Then such information can be used for hacking the website or just changing the sensitive parameter’s value.

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

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

This way any other parameters value can also be modified.

Website 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 background.
• Website form’s appearance.
• Popup window appearance.
• Any other website element’s appearance.

To change the displayed email address on the website, the 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 the 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 the 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.

Changing the website’s design with Javascript Injection is less risky than parameters modification. However, if a website’s design is changed in a malicious way, then it can cost a company’s reputation.

How to Test against JavaScript Injection

You can test it in the following ways:

• Manually
• With testing tools
• Using browser plugins

Possible javascript vulnerabilities can be checked manually if you have good knowledge of how they should be performed. It can also be tested with various automation tools.

For example, if you have automated your tests at the API level with the 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 the 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 incorrect security testing results as well.

You can also find various browser plugins to check against possible attacks. 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 websites 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.

We highly recommend not relying on client-side validation. Also, it is recommended to perform an important logic on the server-side.

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

For Example, if you would write anything into the comment field 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 with double quotes is 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.

Conclusion

It should always be kept in mind, that Javascript Injection is one of the possible attacks against websites, as Javascript is one of the most widely used technologies for websites. Therefore, while testing websites or any other web technologies, it should not be forgotten to test against this attack.

When performing security testing, the JS Injection should not be forgotten. Some people consider this testing as a less risky attack as it is performed on the client-side.

However, it is the wrong approach and we should always remember that Javascript Injection can cause serious website damage like sensitive information leakage, parameters changing, or hacking the user accounts.

Therefore we should consider this as an important part of testing and it is a part of the investment for good products and company’s reputation.

Testing for JS Injection is not very difficult. Firstly you should have general knowledge about Javascript and must know how to check if this attack is possible for the current web solution or not.

Also while testing you should remember, that a website can have protection against this type of attack, but it may be too weak – it should also be checked. Another important thing to remember is that there are different types of Javascript Injection attacks and none of them should be forgotten to test.

Have you performed Javascript Injection Testing?? We would be glad to hear from you, feel free to share your experiences in the comments section below.