Services such as Google Analytics allow site and service providers to see at a glance where users come from, what users do while on their site, and how much time they spend at a particular location. This can be invaluable information when trying to figure out what your visitors are interested in and should therefore invest in more readily. For the most part, JavaScript is what makes this possible. If you’ve ever been on a site that updates the current temperature, for instance, JavaScript is most likely what allows that particular section to update while the rest of the page remains static. JavaScript plugins can provide this sort of dynamic functionality extremely quickly, through the use of dedicated services such as the aforementioned Google Analytics. The site owner signs up for an account, throws on a bit of extra code onto their pages and BOOM — data starts coming in. Unfortunately JavaScript can also allow for malicious actions. For example, if someone sent an email to a user saying “there is something weird going on with your bank account, please click here to check your current status”, a page could then be crafted that loads up every single element of the legitimate bank page except for the login and password fields. Once the user enters this information, it could then be sent off to a malicious third party while also submitting it through a man-in-the-middle attack to the actual bank site. The user would never be able to tell the difference, except for being rather confused when they log into the bank and everything is fine. So what sorts of risks do we run into when using various JavaScript plugins? Let’s go over a list of six JavaScript plugin security risks and some possible ways to mitigate them.
1. XSS — Cross-site scripting
As we described earlier, cross-site scripting (XSS) is a way of mixing legitimate and malicious content together in a way that the browser and the user may have no idea that something wrong is happening. XSS sends scripts to a user that either can change the way a site behaves entirely, or is able to hijack traffic or data in the form of cookies, tokens or other session-specific information.
How do we protect against it?
OWASP, the Open Web Application Security Project, has a number of cheat sheets available for crafting websites in such a way that they are more hardened against such attacks which can be found here. From the user side, however, we can use add-ons such as NoScript that selectively allow JavaScript on a domain-by-domain basis. In this way, we only ever have scripts running on sites that we specifically authorize and as such, it is not nearly as disruptive as disabling JavaScript entirely. However this is still an option for browsers without the ability to use add-ons. Finally, we need to be sure that we only ever use known good links to travel to websites. Those included in emails, for example, can be easily compromised and should be avoided whenever possible.
2. CSRF — Cross-site request forgery
If XSS can be thought of as taking information out of a particular session that a user has, cross-site request forgery (CSRF) can be thought of as forcing a session to do things that a user doesn’t necessarily want to do. For example, say that a user was looking up a price for an item on a shopping website. A CSRF attack could force that session to actually buy the item without the user’s authorization. First, the user needs to have an open session to the legitimate site that the attacker is targeting. Next, they must get the user to click on a malicious link which has the attack code in it — essentially, a URL with particular arguments targeting the legitimate site in question. If the site cannot tell the difference between what a user initiates and what is created by a URL, the consequences could be extremely expensive.
How do we protect against it?
On the web developer side, the use of one-time tokens stored in the HTML code of the site can help a great deal. If the data isn’t in cookies, then an attack like this does not have access to that information. On the user side of things, this one is a bit trickier than not clicking on links in suspicious emails as images can be crafted in such a way to launch the attack directly. Rather, it is important to not open the suspicious emails in the first place. We can also make sure to only have sessions open to websites as they are needed, and to automatically clear out cookies when our session closes.
3. Outdated/vulnerable libraries
Frameworks such as Node.js have made development of web applications significantly easier, as it is an extremely powerful platform with a wealth of available tools. Unfortunately like most things, there can be vulnerabilities that need to be addressed as updates. If developers download the latest available copy locally and then reference that exclusively on their site, it means that everything is self-contained true, but it also means that any discovered issues will not be resolved unless they update it.
How do we protect against it?
Using a package manager can help to make sure that our local copies are always up to date, while our production code can address remotely held official versions so that users are always using the latest available copies. On the user side, blocking JavaScript again is a safe way to protect against vulnerabilities like this.
4. SQL injection
Databases power most web applications available right now, and SQL injection is incredibly harmful to this sort of system. By modifying parts of database queries that are implemented in JavaScript, they are able to attempt to retrieve sensitive data, alter data stored on the server itself or delete data entirely.
How do we protect against it?
Input sterilization is far and away the best defense for developers when it comes to this sort of attack — not trusting anything submitted by users, and stripping out anything that even remotely looks like it could be part of a command, particularly specific symbols.
5. SSI — Server-side includes JavaScript injection
SSIs, or server-side includes, help to power certain types of websites — running commands and preparing data before the site itself is presented to the user. If a malicious user is able to inject JavaScript in this way, they will be able to not only compromise the page but gain access to secure data or worse the ability to run shell commands on the server itself.
How do we protect against it?
It’s not enough in this case to just not use SSI elements in your pages, as they still may be allowed at the server level. Making sure that the server itself is protected against unauthorized SSI scripts is critical. Input sterilization is also extremely helpful in protecting against this sort of attack as it has been before.
6. Tracking
Cookies have been a staple of website functionality for decades now, and the amount of data they can store in an incredibly tiny space is considerable. Malicious scripts can also be used to access this data without being authorized to do so, and as a result, can examine where a user has gone to begin with but also potentially much more depending on how clear the data in the cookies are.
How do we protect against it?
Deleting cookies after every session may be annoying as you have to login to any sessions again, but it is worth it considering the potential risks. Most browsers are now capable of scheduling this automatically upon browser shutdown, so it may not require going into the security settings every single time.
Conclusion
JavaScript powers so much of the web that the average user runs into on a daily basis that it’s all but invisible most of the time. With the ability to hide in plain sight, though, come risks that most may never see. Adding on additional security for this technology can be difficult sometimes, but the cost for not doing so is far greater.
Sources
JavaScript Overview and Vulnerabilities, Checkmarx Cross Site Scripting (XSS), OWASP OWASP Top 10 Security Risks & Vulnerabilities, Sucuri How Companies Are Hacked via Malicious Javascript Code?, itnext.io JavaScript Security, WP Engine Most common JavaScript vulnerabilities and how to fix them, Gitconnected JavaScript Security Risks, NSA.gov Cross-Site Request Forgery, Synopsys About Node.js®, nodejs.org Server-Side Includes (SSI) Injection, OWASP
