Spot False Positives in Static Scans: Password Management

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. You might be using Fortify or some other program to help flag and identify these potential issues in your code base.

Static scan reports that have issues flagged in the Password Management category can be lengthy. This is especially so if your site has authentication capability done internally (vs doing authentication through another site like having users log in with their github account or gmail account).

Ensuring password security is of utmost importance - but since many static scans issues are flagged from keywords - internal authentication will likely mean that you have a good handful of false positives along with real potential threats.

Types of Password Management Sub-Category Issues

There are a few different subcategories of Password Management issues that fortify can outline. It is very convenient that they are broken down this way in the scan results, as it make navigating and addressing these potential issues quicker and easier.

Password Management: Empty Password

What this Means

This means the scan believes a password that can be used to login & authenticate has been hard coded to be empty. The security issue Empty Password is a threat for a few reasons. One, once it is in the production site, authentication can easily guessed compared to a complex password. Also if the account that is "protected" by the empty password is compromised, the users of that account won't be able to update or change that password without the release of new code to the production site because the empty password is hardcoded. Passwords for authentication should not be empty, and they should generally be obfuscated/encrypted and managed in an external source.

Examples of False Positives

One example of a way Empty Password could be a false positive is if the input form is being cleared out. In the below code, from the scan's perspective the variable vm.userPassword is getting assigned an empty string to be able to authenticate. What is really happening is this function is just being used to reset the form.

function resetFormInputErrors() {
    vm.inputFormZip  = vm.inputFormUsername = vm.touched = [];
    vm.user.postalZip = vm.accUsername = vm.userPassword = '';
  }

Password Management: Hard coded Password

What this Means

Similar to the empty password security threat, hard coding passwords is a problem because this password can't be changed without releasing updated code. This means that if there is a password leak (or someone just forgets it) it will take additional time to resolve and reset the password. With this additional time, hackers would be able to access more of the account's information, potentially stealing important private or secure information. Passwords should be obfuscated/encrypted and managed in an external source.

Examples of False Positives

Since the scan is picking up keywords, any variable that has strings like vm.password, this.p_word, vm.Pwd, or $scope.pass_w will be under extra scrutiny. That extra scrutiny means that anything involved in the create password, reset password, or resend password user flow for your application will likely get flagged in some capacity.

The below code is just setting the medium in which the forget reset link will be sent to the user:

vm.passwordRecovery.medium = 'email';
vm.passwordRecovery.sendEmail = 'true';

Here is an example of a route.js file getting flagged as a security threat for the password keyword:

"App.resetPassword.invalid": "/invalidPassword",

or maybe the false positive is that the keyword is assigning the password strength requirements:

vm.passwordPattern = "^[a-zA-Z0-9]+$";

Password Management: Insecure Submission

What this Means

This category means that the scan believes there is an issue with the way the authentication/account creation/password reset is being submitted. The scan believes that the submission is being done over an HTTP get request as a parameter where web servers can log them and proxies can cache them. Using a HTTP GET to send a password or other sensitive information can cause the data to be mishandled or discovered by an attacker. To send sensitive data it is recommended to use a HTTP Post.

Examples of False Positives

In the below example the controller ID "CurrentPassword" for the input had gotten flagged as an insecure submission. But since this is just adding an ID for the html to be referenced in the controller and there is not a GET request being used with this password submission, it is a false positive.

 <input id="CurrentPassword"
        name="passwordConfirm"              
        type="password"
        maxlength="32"
        data-ng-pattern="Pattern"
        required
        ng-blur="selected = false" />

While there are lots of ways that the Password Management category of a static scan could be a false positive, double & triple checking to ensure there isn't a security threat is always recommended. Especially when it comes to passwords because that can lead to additional security leaks.