SoftwareSecurity2013/Group 8/Introduction

R1 Report Introduction

R1.1 Input verification of FluxBB

This report describes the security risks of fluxBB. There will only be searched for input validation. The report is written as suggested by the OWASP ASVS manual.

When PunBB was sold to a commercial company, it was also further developed in the open source world as FluxBB. FluxBB is forum software developed to be easy to use and with high performance. FluxBB is programmed in PHP and supports multiple types of databases. For example PostgreSQL and SQLite. It also has advanced features such as admin functions, support for multiple languages and email validation.

This report describes the security risks of fluxBB. There will only be searched for security risks within the input validation. The ASVS requirements (V5) will be checked with this project. For example there will be checked if all input failures are logged. This is necessary because if failures are not logged then we would not know there is a failure let alone where it would be if we suspected it and how to fix it.

R1.2 Confidence in the security of the application

The confidence in the application is sufficient to use it. Mostly because of the 5 years of experience of the developers with this program. The program is widely and long enough used to have it's security problems found. For example because of hackers trying to modify pages they are not allowed to. Their site also says: "It is easy to use and has a proven track record of stability and security making it an ideal choice of forum for your website.". As much as we would like to believe that it is completely secure, we cannot trust this. With this contradiction is meant that there most likely will be no security problems with this software and it will be save enough to use for non-confidential information. Business projects yes, military projects no.

The biggest problem with this project is that the source code is freely available, this could really help a hacker finding security leaks. So if the interest or amount of work is not affording enough to hack, you are pretty save. No-one is interested to hack a forum of a grocery store. An intern government forum would be more interesting. For example: For the newspapers getting the national-budget numbers of prinsjesdag, before any other newspaper has them.

Searching the code, finding strange pieces of code and comments the confidence in this project fades a bit away. After checking the security verification requirements of the ASVS we found all sorts of "security" risks. Nothing as a threat directly, but there might be some security issues indirectly or in the future.

So overall the confidence is high enough to use this software for low-risk applications. We would use it for storing/displaying information about a company and some projects. But absolutely not for projects containing company secrets.

Very strictly seen, if someone would ask whether or not to use it, not saying what for. The verdict would be not to trust it. Because it is reasonable to believe that there might be an indirectly possibility that data could be taken without signing in. Although this would need an experienced hacker willing to put enough time and effort into it. (So there really should be data worth breaking in for.)

updated 2013-06-12

R1.3 Key business risks

Using this program commercially we have the following key business risks:

• Protection of the privacy of the users. (Not only is it unwanted but there are also huge fines if it is discovered.)
• Protected pages with confidencial information should not be viewable by unregistered users.

R1.4 Rules of engagement

This report is limited to only the input validation. Further security risks are not checked for.

We have only two obvious constraints:

• Buffer overflows because the application is built in PHP and PHP does not suffer from buffer overflows.
• Time, because of the limited in available time this verification it is not possible to manually scan through code. Checking for every possible problem in every method.