DAST Vulnerabilities - Unintended information being shared in cache.js files

Products

• CA Workload Automation AE

Issue/Introduction

The infrastructure vulnerability team identified the following -

URL
https://hostname:8443/wcc/ui/login/7D936E914DBB34D1A81BB32A9DBDD1B0.cache.js
 
Description
Revealing system data or debugging information helps an adversary learn about the system and form a plan of attack. An information leak occurs when system data or debugging information leaves the program through an output stream or logging function.
Recommendation
Depending upon the system configuration, this information can be dumped to a console, written to a log file, or exposed to a remote user. In some cases the error message tells the attacker precisely what sort of an attack the system will be vulnerable to.
For example, a database error message can reveal that the application is vulnerable to a SQL injection attack. Other error messages can reveal more oblique clues about the system.
In the example above, the search path could imply information about the type of operating system, the applications installed on the system, and the amount of care that the administrators have put into configuring the program.

 
Proof
java.lang.ClassCastException/702295179',aMb='java.lang.Error/1331973429',bMb='java.lang.Exception/1920171873',cMb='java.lang.Ill

Environment

Release : 11.3.6

Component : CA Workload Automation AE (AutoSys)

Resolution

We reviewed the defect related to Unintended information shared by *cache.js file

https://hostname:8443/wcc/ui/login/7D936E914DBB34D1A81BB32A9DBDD1B0.cache.js

*.cache.js file is generated by GWT framework. Each application has 6 different *.cache.js for each browser. Basically *.cache.js file is an index/login.html file converted into *cache.js file by GWT. Ideally *cache.js file is nothing but a login page in obfuscated javascript.
It is almost impossible to figure out what the code does inspecting the javascript stuff because of the big obfuscation. You need the original .java files to understand the code or make modifications (By the GWT team)


We wanted to inform you that you can proceed further as this issue is not vulnerable.

More explanation from GWT framework:
----------------------------------------------------------------
By default, GWT obfuscates the JavaScript it produces. This is partly done to protect the intellectual property of the application you develop, but also because obfuscation reduces the size of the generated JavaScript files, making them faster to download and parse.

GWT compiler does a lot of the work you would have to do manually when coding JS by hand, and some other tasks which are almost impossible in a normal JS project: obfuscate, compress, death-code removal, different optimization per browser, renaming of the scripts, code splitting, etc.

First, you should have a unique index.html file, because GWT is used to produce RIA (Rich Internet Applications) also known as SPI (Single Page Interface).

The unique HTML file should have a reference to a javascript file named application_name.nocache.js. Note the .nocache. part, meaning that the web server should set the appropriate headers so that it is neither cached by proxies nor browsers. This file is very small because it just has the code to identify the browser and ask for the next javascript file.

This first script knows which NNNN.cache.js have to load each browser. The NNNN prefix is a unique number that is generated when the app is compiled, and it is different for each browser. GWT supports 6 different browser platforms, so normally you would have 6 files like this. Note the .cache. part of the name, meaning that these files could be cached forever.

So the normal workflow of your app is that the browser asks for the index.html file which can be cached. This file has the script tag to get the small start script applicaton.nocache.js which should be always requested by the server. It has just the code for loading the most recent permutation for your browser NNNN.cache.js which will be downloaded cached in your browser forever.

The goals of this naming convention are that the next time the user goes to the app, it will be in cache the index.html and NNNN.cache.js files, asking only for the application.nocache.js which is really small. It guarantees that the user loads always the most recent version of the app, that the browser will download just once the code of your app, that proxies or cache devices do not break your app when releasing a new version, etc.