If you're working through a static scan in order to get your code base in tip-top shape for an upcoming deployment, you know that you want to focus in on the real issues that need to be addressed as quickly as possible. Narrowing down your issue report quickly gives you more time for real issues. This means being able to quickly and effectively spot false positives that have been flagged in your fortify scan. In the scans that I look through, Insecure Randomness is the #1 offender of false positives getting flagged.

What is Insecure Randomness?

Insecure Randomness is when a function in the code that produces predictable values is used to store, access, or send secure or private information. Those values are used as a source of randomness in a security-sensitive context to transport data when encryption really should be used instead. Examples of this include using Math.random() to assign authentication tokens or as not so secret urls to secure information. Since the output of these functions are predictable, it would make it extremely easy for them to be hacked - thus making personal or private information insecure. The most frequent way to spot an offender like this in javaScript is the finding a misused Math.random() function.

What is a false positive?

In the case of a static scan, is anything that appears from the scan's perspective to be potentially a security threat when it really is innocuous. Often times the scan is just pulling keywords from the repository which can cause false positives.

Types of Insecure Randomness False Positives

Cache Busting

Websites have a lot of files like CSS, HTML, images, etc. that the browser has to download for it to be displayed. If the browser had to get these files every time the site is refreshed, that would take up a lot of unneeded load time, so the browser saves or "caches" the files to your computer to avoid this.
Cache busting occurs when we need the computer to get an updated version of a web page. Cache Busting can also help solve some of the discrepancies between different browser. By appending the value of a Math.random() call to the url, when that page is reloaded it "tricks" the browser into thinking it is a webpage it hasn't visited before. The browser thinking it is visiting a brand new page will download all of the files once again - thus updating the cache to be more current.

config.url = config.url + 'cb=' + new Date().getTime() + Math.random();

Unique ID on an HTML Element

Math.random() is a quick and easy way to attempt to give all of your HTML elements unique IDs. (This is not foolproof since Math.random could potentially return the same value twice). If you want some really in depth reasons as to why you should have unique IDs for your HTML elements checkout this article. Since this is not using math.random() for encryption or secure transport of private information, it is a false positive.

// Generate a unique ID
vm.id = Math.floor(Math.random() * 10000);

or

$scope.uniqueId = = 'v' + Math.floor(Math.random() * 10000);

D3 & other Libraries

There are several libraries which always get flagged for Insecure Randomness for innocuous reasons. D3 and C3 are both libraries that constantly get flagged for this Fortify category, because math.random() is used in much of their functionality for drawing charts and graphs.

When you first find out that the flagged issue comes from an external library, ensure that the version of that library is acceptable by the tech standards of your team. Then do your own high level research as to how that library is utilized.

Here is an example from a flagged C3 library false positive:

(withTransition ? this.mainLine.transition(Math.random().toString()) : this.mainLine)

Spec Files or Test Files

If it is only occurring in a spec file or a test file for unit testing, there isn't much worry for it since it is used for the build process and only uses mock data. This isn't going to be production code and will not leak secure or private information. While this is a false positive, you should still go in and clean up the file, double check that the .js file that the spec file is unit testing is also secure.

Wrap up

When resolving issues that are potential false positives you will want to know exactly what the code is doing, and why, so you are confident in your assessment and not discounting what could be a true security threat. Being able to identify false positives is a great way to increase productivity and ensure that time and energy is focused in on the actual security issues that need to be resolved.