Let's hack Javascript

Well yes, most of the applications are HTML5/CSS/JS based and it’s quite easy to build them too with the kind of libraries/frameworks available in the market. When we talk about security testing of these kind of applications we majorly come across some common security breaches like SQL Injection, Cross-site Scripting and Cross-Site Request Forgery which could be detected using “Fiddler” a Progress Telerik tool, but a safe/secure application might have many layers of security where these major attacks are not the only good candidates to hack the system.

Something about JavaScript Obfuscation

It makes our job pretty easier to develop web application and mobile application at the same time with minimal changes using HTML5/CSS/JS.  As soon as the application is deployed and provided access to public, everyone out there can access your JavaScript code from the browser and look at the logic and try to understand(if they can) what it does. So how far is the code secure? 

That is where we have code obfuscation. Code obfuscation changes the code (but the functionality still runs) and makes it non-readable/understandable.

For example, here is a simple addition code in JavaScript

Before Obfuscation

 var z = 2 + 3;

document.write(z);

After Obfuscation

eval(function(p,a,c,k,e,d){e=function(c){return c};if(!''.replace(/^/,String)){while(c--){d[c]=k[c]||c}k=[function(e){return d[e]}];e=function(){return'\\w+'};c=1};while(c--){if(k[c]){p=p.replace(new RegExp('\\b'+e(c)+'\\b','g'),k[c])}}return p}('1 0=2+3;4.5(0);',6,6,'z|var|||document|write'.split('|'),0,{}))

So if a simple two line statement looks this complex, imagine how a 100 line JavaScript code would look like. Code Obfuscation simple follows a unique mechanism to encode and encrypt your code and make non-understandable.

Well, what was this whole write-up related to testing. The explanation for JavaScript obfuscation was explained to highlight the “malicious obfuscated JavaScript” attack which is considered to be the top internet security threats. Some smart hackers can send malicious obfuscated JavaScript which cannot be detected at our Presentation layer or any available anti-virus software. By doing this they can inject the data they want, access the UI elements and divert the traffic to their own domains.

Access/Policies/Controls inside JavaScript

The above section was about malicious data injection, but now let’s talks about how we can stop unwanted users to access our application.

Content-Security-Policy (CSP) – This policy will define set of rules on what kind of request with specific URL/domain/http type can access the application. If you are going to execute JavaScript inside the code then you can define the script source inside the CSP which will not allow hackers to execute their scripts. In addition to that we can also notify if any unwanted request (from an unwanted domain) was access the application. CPS really helps from stopping Cross-site Scripting attacks.

Accessing different origin resource safely using CORS - One important concept of Web application Security is “Same-origin policy”, which means the hosted web page can access the resources of the hosted domain but not the resources of another domain. If you try to access it then it will not allow you to do so. The Cloud world, access resources from different domains hence this policy has to be somehow bypassed securely. In-order to achieve this JSONP (JSON with padding) was introduced to call the services in other domain. In JavaScript users can invoke a HTTP Request and in return back the response from the domain to which the request was invoked. But JSONP has security vulnerability; it just passes the response to the requested server without doing any validation of data (which might inject malicious JavaScript). Hence using JSONP is security vulnerability and should be used for accessing resources from a different domain.

As a better alternative, Common-Object Resource Sharing(CORS) was introduced which could access resources from different domain for all HTTP verbs(JSONP could only do for GET) in addition to that it first passes the response from the other domain and allows it to get parsed and then on validating all the policies it accepts the response. In the terminology of CORS the first request is termed as “pre-flight” request which can perform validation and then based on the rules it accepts the requests. You can look have a look at Progress OpenEdge Mobile to know CORS has been used to access resources from other domain.

The above concepts will help us understand what are best practices that need to be followed while developing JavaScript applications to not save from Security attacks; hence while testing JavaScript applications we can look through these concepts and validate the level of vulnerability.