Test and Prevent JS Injection Attacks on Website
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.
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.
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:
If a popup window with a message ‘Executed!’ appears, then the website is vulnerable to JS Injection.
Typical JS Injection targets are:
Article‘s comments fields
Any other forms where text can be inserted.
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.
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.
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:
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“.
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.
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:
This way any other parameters value can also be modified.
Website’s Design Modification
Website form’s appearance.
Popup window’s appearance.
Any other website element’s appearance.
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:
Then every time when a page is opened, a text box with the message “Hello!“ will appear.
It can be tested in the following ways:
With testing tools
With browser plugins
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.
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.
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.