Fortify on Demand Remediation – Password Management: Hardcoded Password and Privacy Violation

These two vulnerabilities occur in the obvious case — you’ve hard coded a password or some sort of private info (e.g. SSN) and then printed it out to the browser. Don’t do that! But it also seems to occur quite frequently when Fortify on Demand doesn’t like your variable name. As an example, I have a string that provides a consistent error message when user authentication fails.

I then print the string to the screen when the user’s logon fails. Fortify says I am disclosing the user’s password. I’m obviously not. Simply renaming the variable sorts it. Now … yes, this is silly. But it’s a lot easier than trying to convince someone in Security to manually review the code, acknowledge that something about a bad password error is a totally reasonable (and descriptive) variable name, and add an exception for your code. Since bad password is error 49, I just used that in the now less descriptive variable name [ (1) Not too many people know the LDAP error codes off the top of their head, and (2) there are actually a handful of ldap bind return codes that will print this error].

Leave a Reply

Your email address will not be published. Required fields are marked *