SoftwareSecurity2012/Group 4/Reflection

Overall this application security verification was a lot of work. Even though we only had to verify the code of the FluxBB extension, namely the Private Messaging System module. The code scanners didn't work very well. All we got was false positives. The scanners can't see if there are functions in between input and output that sanitize the values (Did you use the scanner output in any way in the later manual review?). PHPLint gave us so many results that we didn't even check them. Some of the PHPLint warnings looked very much like the Yasca core or RIPS results. We already checked the results of the latter scanners, so it was useless to go through all of PHPLint's results.

The next step was to manually sort through the code and check for security vulnerabilities. The OWASP document for manual code analysis was pretty useful. It does provide a nice checklist to make sure you check every aspect of the code. The document is structured in such a way that you can easily check only certain aspects. Because we analyzed a module for FluxBB, we had to check all the requirements in the OWASP document on level 1B and 2B. Some of the requirements did not apply to the module or were not very useful for us. The document also didn't specify how to check the requirements, i.e. what actions we should perform to make sure the requirement is checked completely. We mostly started looking at the test version of the software we had running locally and tried to find the functions on the webpage that corresponded with the requirements. Then we searched through the code of these functions to look for any vulnerabilities. We checked all dependencies and inherited code. So if there was a function that would process a filled out form, we also checked the sanitizing method that was called. This would give us the full perspective to answer the OWASP security requirements questions.

We mostly divided the work in two parts. Two of us would work together on the first part and the other two would work on the second part. For the code scanners, Bas and Kevin started on getting RIPS working and Willem and Christiaan tried Yasca. The results for RIPS were analyzed by Bas and Willem and the Yasca (with plugins) results were analyzed by Kevin and Christiaan. The manual code analysis was also divided in two parts. This worked really well and we could work on several things at the same time.

(Erik:It seems that in the review of the extension you also looked into many generic fluxbb issues. (It is not clear if you were inevitably dragged into looking at generic fluxbb issues, or you simply looked at them out of curiosty.) This raises the question if looking at an extension like PMS separately is really a useful approach.)