Reviewing vulnerability scanner results for an APM protected Virtual Server - part two
This article is part two of the article series "Reviewing vulnerability scanner results for an Access Policy Manager (APM) protected Virtual Server" from your F5 SIRT.
Here is part one: https://community.f5.com/t5/technical-articles/reviewing-vulnerability-scanner-results-for-an-access-policy/ta-p/321112
Recap of part one
In part one, we reviewed the disclaimer/"Get Out of Jail Free Card", the lab APM virtual server setup, and APM Access policy, the ZAP web app scanner, and the sample web app scan result. We looked at the findings and resolutions for HTTP Cookie attributes and HTTP Security headers such as the CSP policy.
In this part-two article, we will review a Time stamp disclosure finding and then the Conclusion.
Timestamp Disclosure - Unix
There was also a finding from the ZAP web app scan about 'Timestamp Disclosure'
Details: A timestamp was disclosed by the application/web server—Unix
1684411196, which evaluates to: 2023-05-18 04:59:56
1684411196, which evaluates to: 2023-05-18 04:59:56
Looking at the response body, the following lines include the timestamp '1684411196'
href="/public/include/css/modern/framework.css?q=1684411196" />
<script type="text/javascript" src="/public/include/js/modern/loader.js?q=1684411196"></script> <script type="text/javascript" src="/public/include/js/modern/main.js?q=1684411196"></script>ZAP's recommendation is, "Manually confirm that the timestamp data is not sensitive, and that the data cannot be aggregated to disclose exploitable patterns."
The format of these lines includes a query string "?q=1684411196" and the files are JS and CSS files. The query string value is a timestamp of the related files and is used in a technique called Cache Busting. This will cause the browser/client to use the newer version of the JS and CSS files from the webserver. In this case, it’s the APM presenting these JS and CSS files.
Here are some details about Cache Busting:
Cache-busting solves browser caching issues by using a unique file version identifier to tell the browser that a new version of the file is available. Therefore, the browser doesn't retrieve the old file from the cache but rather makes a request to the origin server for the new file.
Using Query Strings
Another cache-busting technique is to add a query string parameter to the URL of a file. For example, a CSS file with the URL https[:]//example[.]com/styles[.]css can be modified to https[:]//example[.]com/styles[.]css?v=2. The ?v=2 query string parameter tells the browser that this is a new version of the file, and it should be downloaded from the server.
The value of the query string parameter can be any string, such as a timestamp or a version number. As long as the value changes each time the file is updated, the browser will treat it as a new file and download it from the server.
https://www.keycdn.com/support/what-is-cache-busting
Cache-busting solves browser caching issues by using a unique file version identifier to tell the browser that a new version of the file is available. Therefore, the browser doesn't retrieve the old file from the cache but rather makes a request to the origin server for the new file.
Using Query Strings
Another cache-busting technique is to add a query string parameter to the URL of a file. For example, a CSS file with the URL https[:]//example[.]com/styles[.]css can be modified to https[:]//example[.]com/styles[.]css?v=2. The ?v=2 query string parameter tells the browser that this is a new version of the file, and it should be downloaded from the server.
The value of the query string parameter can be any string, such as a timestamp or a version number. As long as the value changes each time the file is updated, the browser will treat it as a new file and download it from the server.
https://www.keycdn.com/support/what-is-cache-busting
So, is there a problem with this? Based on what we know of what this timestamp is used for, it has a valid use in APM logon page and simply instructs clients to use the CSS and JS files with the certain timestamp.
Conclusion
Vulnerability / web scanner reports will contain many findings. The web app scanning excercise results in this article are just a small subset of potential findings. In this case, we ran through resolving some of the findings by applying necessary configurations — such as an iRule or an Access profile change — to be compliant and some, analyzing the purpose of an entity (timestamp used in CSS query string for cache busting) and determine it has valid use. Implementing these resolutions and understanding of the findings improves the application's security, and as security analysts, we become familiar with the security gaps and functionalities of the application. Our counterparts in network and system administration and application teams will look to us for guidance on keeping our organizations assets secure. Running regular vulnerability scans is an industry norm. We should review the findings and evaluate the risk on the assets that we protect. Keeping networks and systems up to date with security fixes and review of access - allowing only trusted users and networks - to these assets is bare minimum. Implementing additional controls such as BIG-IP APM or BIG-IP ASM/Adv WAF to protect networks and web applications are a great counter to unexpected web scans or even malicious attempts to your web applications.
I hope you find this article educational and the concepts and learnings can be added to your security mindset and arsenal. Till next time.
Published Oct 10, 2023
Version 1.0
No CommentsBe the first to comment