SoftwareSecurity2014/Group 13/Code Scanning Reflection

Tools

Fortify

Fortify is a good tool for finding security vulnerabilities with output encoding, because it gives a trace from variable initialization to the use in output. It checks for encoding along the way, although the function urlencode() was somehow not considered enough. (Erik: I guess the (interesting) question here whether Fortify simply does not recognize this function, and hence missing it as a good encoding step, or whether it does recognize it but it somehow considers that urlencode is not a secure encoding. Does the feedback of Fortify give any hint as to which of these two is the cause that it produces a warning?) There were some false positives. Command injection complained about the use of function exec(), but it was only called with constant 'uptime' and therefore not a vulnerability. Some vulnerabilities were listed under multiple categories, for example the use of an unencoded variable in the function header() was listed under Header manipulation and Open redirect. (Erik: Do you have a rough impression of how many false positives there are? eg are we talking 5%, 50% or 95%?)

Pfff, PHPLint, RATS

We found that these tools were not helpful at all, at least from a security perspective. While they do help to get a good coding style, they don't really add anything to security. RATS is similar to grep, by searching for possible incorrect uses of functions. RATS contains a database with functions, and parses the code so that it doesn't warn for something that is not actually an function call. RATS is a handy tool during manual verification. For example it can find all exec calls in the program, which can then be checked. (Erik: But are any of these warnings relevant for V6? I'd say not, right?)

Pfff is style checker. It reports issues like weird use of the ternary if operator and undefined variables. A good programming style is important in making secure code, but Pfff does not help to find insecure code itself.

PHPLint just complains about types. There could be actual bugs or security vulnerabilities there, but that requires manual inspection. Also if the code wasn't made with PHPLint in mind, the tool spits out a lot of issues. We think that the PHPLint is nice to code security critical functionality, the tool can then find vulnerabilities due to the weakly typed PHP. To find issues in an existing code base, PHPLint is pretty useless due to high false positives. (Erik: I guess a tool like PHPLint only makes sense if you use it throughout development, so that you fix warnings as you go along, not after the fact on a large existing codebase)