I received a security scan from Fortify on a webapp (using SSL/HTTPS) written in Angular that I am working on and I have two questions (high risk issues) that I'm seeking help on.

  1. Access Control: Unprotected File - GET /fonts/fontawesome-webfont.ttf?4.3.0. So the webapp uses fontawesome icons and I'm guessing that the webfont files being accessible is the problem? I'd first like clarification that my understanding is correct. Then, is there anything I can do? If I change the permissions, I can stop the access to the file, but then the icons don't display! Is it really a high security risk that the webfont files are unprotected?
  2. Password Management: Insecure Submission - GET /templates/some_file.html?user=12345&pwd=12345. The webapp at a certain point will pop up a modal that requests a username and password. 'user' and 'pwd' are from the name field and I don't know if simply removing the name fields from the inputs would solve this problem? The other thing that I've already done is take all the html files that are not index.html and built them (using grunt) into a javascript file, so now you can't just access /templates/some_file.html and I don't know if that solves this problem as well?

Finally, I see CWE numbers which I'm unclear as to if these correspond to CVE numbers that I've seen mentioned on sites? When I receive a report like this, is there a site I can go to that explains these issues in detail so that I may learn about them?

Best Regards, Julie

  • The first one is a false positive, the second one is because sending passwords as GET parameters isn't a best practice, though it's safe as long as HTTPS is used. Sep 23 '15 at 18:10
  • Thanks @AndréBorie. So if I understand you correctly, this first isn't really a concern and if I don't send user or pwd in GET, then I should be okay?
    – JulieMarie
    Sep 23 '15 at 18:16
  • Yes. Though as long as you're using HTTPS, even the passwords in GET requests aren't really security issues, more like best practices. To get the passwords you'd still need to breach the HTTPS security, and if you do, you may as well intercept POST requests. Sep 23 '15 at 18:21
  • 1
    @AndréBorie I think Fortify complains because URLs frequently get logged so putting confidential information in them is inadvisable. Sep 23 '15 at 18:25
  • Thank you to both Neil and André. I thought they weren't a concern, but since they show up as high issues, I've been asked to address them and it sounds like the fact that we are using HTTPS covers them both anyway.
    – JulieMarie
    Sep 23 '15 at 18:32

First, as strong as Fortify is for static analysis, it still doesn't understand your application or deployment model so it has to make guesses sometimes. And when in doubt, Fortify says something is a problem. So you will have many false positives that you simply need to ignore. You can do this by setting the Analysis field to Not an issue in Audit Workbench or the SSC. Fortify will carry this forward to future scans so that you never need to pay attention to this issue again.

  • Unprotected File - It's hard to be certain without seeing the code but, based on your description, it sounds like this isn't a problem. Fortify is correct, these files are unprotected, but they're supposed to be that way. So mark it Not an issue and move on.
  • Password Management: Insecure Submission - The problem here is your use of GET instead of POST to do the login request. GET parameters are passed through as part of the URL after a ? character. URLs have the nasty tendency of getting recorded in logs and such. So passing a password, or any other confidential data, via a GET request is considered a privacy exposure. You should change the request to a POST on the client and/or the server, depending on your webapp framework.

CWEs are entries in the Common Weakness Enumeration. They are a list of common programming and deployment mistakes that lead to security flaws. Fortify displays them to help you understand the problem it found. For example, the unprotected file issue might show up as CWE-306: Missing Authentication for Critical Function. You can just google them to find specific ones. If you've not already read the CWE-25, it is probably worth your time to do so. Those issues tend to come up often in application security.

  • Thanks Neil. With respect to the Insecure Submission, I don't do a GET to submit any data on this particular form (or any form for that matter...I always use POST). I'm guessing like you stated in the first paragraph, that Fortify has made a guess and it's wrong. I appreciate all your help!!
    – JulieMarie
    Sep 23 '15 at 18:37
  • That sounds like a Fortify bug. The description for the issue says Submitting a password as part of an HTTP GET request will cause the password to be displayed, logged, or stored in a cache. So if you're not using GET, it's a bug. Sep 23 '15 at 18:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.