Web Security: How to use third-party javascript securely

In Security of WebApps, we often think of securing our database, application server security & other frameworks security like Structs, Spring etc. Generally, Frameworks are the first point of target for the hackers because it provides straight entry into the target application. But, the situation has been changed a little bit. These frameworks are getting more secure day by day. And hackers are targeting low hanging fruits.

The more vulnerable piece of software in any web application could be your fancy third-party javascript. Javascript is actually bad for security but very powerful language. And, one of the core issue & feature with Javascript is that it is flexible & does not require whole programming stuff like Java or Python. It executes within the browser, easy minimum code & easily injectable in many ways: Through Forms, Review comments, Web service response etc.

Hackers do not need to hack your server & network to steal your information. One or two lines of javascript could be good enough.

Hacking through Javascript

Following problems may happen using third-party libraries:

  • Third-party javascript will have access to the application as your own javascript.
  • Malicious javascript code. Third-party libraries has been compromised.
  • Confidentiality, Integrity etc are other security risks.

Most of the applications use third parties, open source javascript libraries to implement some functionalities. And, hardly anybody knows who maintain, fix bugs in these open source libraries. Even if we buy javascript libraries, Hardly there is any security testing done on those frameworks. Hackers use third-party & integrated services to break the target application. The recent example is here.

The British Airways Hack: JavaScript Weakness Pin-pointed Through Time-lining

How to secure our application when you have used third-party javascript?

About Open Source Libraries: Open source libraries are great & provide so much fancy javascript stuff. However, the major concern is that we never know what changes have been updated & how those are affected to your application. Someone can add malicious code & will wait for you to get the latest changes loaded in your application.

Solution-1

General practice is that keep them in the source code & use them. Do not depend on patch & updates regularly from the owner of these libraries. It is one way to add security to our application. Let’s assume you want to upgrade these libraries to get some latest features or bug fixes then plan just like you plan for any software update. Do not just copy paste minified version.

Not every third-party javascript can be party of your source code. For those situation try solution-2.

Solution-2

Another way is to keep relying on libraries hosted by third-party. In the case of analytics, DTM scripts are generally loaded from third-parties. However, the point is that make sure security testing do the diligent work. Use some JavaScript specific security tools like Javascript security analyzers. These tools perform code analysis on client-side applications.

Final Thought

This seems very small step & do not get much attention. We all try to solve big problems first. But, In my opinion, these small issues solve the bigger problem & control much more damage than building a new rocket. For suggestion or inputs, leave your comments. Thanks.

Advertisements


Categories: AEM Security, AEM Solutions, Cyber Security, secure development

Tags: , , , , , , ,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.