DAST scan detects Browser Cache directive as a vulnerability
search cancel

DAST scan detects Browser Cache directive as a vulnerability

book

Article ID: 210154

calendar_today

Updated On:

Products

CA Workload Automation AE - Scheduler (AutoSys) Autosys Workload Automation

Issue/Introduction

Industry standard vulnerability scanner Dynamic Application Security Testing (DAST) reported Browser Cache directive as a vulnerability in Autosys WebUI.

URL: https://hostname:8443/wcc/ui/
 
Description:
The response browser cache headers allow response caching. If the response contains sensitive information then it may be leaked into the browser cache.

By default, a response is cacheable if the requirements of the request method, request header fields, and the response status indicate that it is cacheable. Finally, unless specifically constrained by a cache-control directive, a caching system MAY always store a successful response as a cache entry, MAY return it without validation if it is fresh, and MAY return it after successful validation. If there is neither a cache validator nor an explicit expiration time associated with a response, we do not expect it to be cached, but certain caches MAY violate this expectation (for example, when little or no network connectivity is available). A client can usually detect that such a response was taken from a cache by comparing the Date header to the current time. Therefore, the browser has a capability to temporarily store some of the pages browsed. These cached files are stored in a folder. When we ask for these pages again, the browser displays them from its cache. Logging out from an application obviously does not clear the browser cache of any sensitive information that might have been stored.
Recommendation
Update Cache-Control http header to include no-store directive. The purpose of this directive is to prevent the inadvertent release or retention of sensitive information. The suggested HTTP response headers are:
Cache-Control: no-cache, no-store
Expires: 0
Pragma: no-cache

 
Proof:
HTTP/1.1 200 Connection: close Date: Thu, 05 Nov 2020 11:11:20 GMT Transfer-Encoding: chunked Content-Type: text/html;charset=UTF-8 Content-Encoding: gzip Last-Modified: Wed, 03 Jun 2020 20:01:30 GMT Accept-Ranges: bytes ETag: W/"9168-1591214490000" P3P: CP="CAO PSA OUR" Server: WCC Vary: accept-encoding Content-Security-Policy: default-src 'self'; img-src 'self' data:; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; font-src 'self' https://fonts.gstatic.com; frame-src 'self' blob:; X-Frame-Options: DENY X-UA-Compatible: IE=9 Strict-Transport-Security: max-age=31536000 X-Content-Type-Options: nosniff X-XSS-Protection: 1; mode=block
 
Proof Description:
Cache-control is missing the no-store directive. Unless specifically constrained by a cache-control directive, a caching system MAY always store a successful response as a cache entry.

Environment

Release : 12 and higher

Component : Autosys WebUI

Resolution

This is a false positive. The sensitive information is not accessible after user is logged out from the WCC. The User cannot access any information such as viewing/editing jobs once logged out. The attempt would return access forbidden rather than loading data from the cache.