Software Security/Group 2/Wanted Documentation

Provided documentation

With the phpBB web application came a documentation consisting of several files. Those files are listed below:

phpBB2/docs/

• AUTHORS
• COPYING
• codingstandards.htm
• FAQ.html
• INSTALL.html
• README.html
• coding-guidelines.txt

Most of these file are not interesting for our project, because they mainly explain to a user of the phpBB web application how to operate it, rather than explaining how the application was built and/or which methods were used to program it.

Although AUTHORS consist just of a link to the credits web page instead of a list of authors, all the other files contain what you expect them to contain. However the INSTALL.html file is not updated since previous versions. According to this file the requirements for installing phpBB2 are:

• A web server or web hosting account running on any major Operating System
• A SQL database system, one of:
  • MySQL (3.22 or higher)
  • PostgreSQL 7.0.3 or higher (preferably 7.1.x or 7.2.x)
  • MS SQL Server (7 or 2000) directly or via ODBC
  • MS Access (2000 or XP) via ODBC
• PHP (3.0.9 and above or preferably 4.x running as a module) with support for the database you intend to use above

As you can see MySQL 3.22 or higher is required for the SQL database system (among others). However, when installing phpBB2, only MySQL 3 and 4 are being accepted, because, as group 9 found out, phpBB2 fails to work with MySQL 5.

The most interesting files for our project are codingstandards.htm and coding-guidelines.txt. The coding standards file is the only one in the documentation that actually contains some code. Although it is not an explanation of the phpBB code, but they show what kind of programming style is used by the creators. The coding guidelines file is mainly written for programmers who want to extend phpBB by themself. Although we do not need to know how to extend phpBB, the file shows some insights in how some things are implemented in phpBB and some possible security flaws if the guidelines are not met.

• The coding style is defined in the codingstandards.html file, all attempts should be made to follow it as closely as possible.
• All SQL should be cross-DB compatible, if DB specific SQL is used alternatives must be provided which work on all supported DB's (MySQL, MSSQL (7.0 and 2000), PostgreSQL (7.0+), Oracle8, ODBC (generalised if possible, otherwise MS Access, DB2)).
• All SQL commands should utilise the DataBase Abstraction Layer (DBAL).
• All URLs (and form actions) _must_ be wrapped in append_sid, this ensures the session_id is propagated when cookies aren't available.
• The minimum amount of data should be passed via GET or POST, checking should occur within individual scripts (to prevent spoofing of information).
• The auth function should be used for all authorisation checking.
• Sessions should be initiated on each page, as near the top as possible using the session_pagestart function (userdata should be obtained by calling the init_userprefs immediately after session initialisation).
• Login checks should be forwarded to the login page (supplying a page to forward onto once check is complete if required).
• All template variables should be named appropriately (using underscores for spaces), language entries should be prefixed with L_, system data with S_, urls with U_, all other variables should be presented 'as is'.
• Functions used by more than page should be placed in functions.php, functions specific to one page should be placed on that page (at the top to maintain compatibility with PHP3) surrounded by comments indicating the start and end of the function block.
• All messages/errors should be output by the message_die function using the appropriate message type (see function for details).
• No attempt should be made to remove any copyright information (either contained within the source or displayed interactively when the source is run/compiled), neither should the copyright information be altered in any way (it may be added to).

The README.html file however did report some concerns towards the application's security. The following is an excerpt of the aforementioned file.

6. Overview of current bug list

This list is not complete (see above link for full list) but does represent those bugs which may effect users on a wider scale. Other bugs listed in the tracker have typically been shown to be limited to certain setups or methods of installation/upgrade.

• Cannot post very large messages when using PostgreSQL 7.0.x (limitation of Postgresql 7.0.x)
• By default cannot post very large messages with MSSQL (this can be configured within MSSQL)
• Possible issues with gzip (note that these may be PHP related and not phpBB problems)
• Search may not work correctly with non-latin & multibyte charsets (somewhat a limitation of PHP3/4)
• Netscape may act strangely on some systems (proving hard to reproduce consistently)
• Upgrade may fail to complete on large boards under some hosts

7. PHP compatibility issues

Please remember that running any application on a developmental version of PHP can lead to strange/unexpected results which may appear to be bugs in the application (which may not be true). Therefore we recommend you upgrade to the newest stable version of PHP before running phpBB2 (the most recent stable release of PHP is 4.1.2). If you are running a developmental version of PHP please check any bugs you find on a system running a stable release before submitting.

This board has been developed and tested under Linux and Windows (amongst others) running IIS and Apache using MySQL 3.23 and 4.0.0, MSSQL Server 2000, MS Access 2000 and XP and PostgreSQL 7.x.

7.i. Notice on recent PHP security issues

At the end of February 2002 a [major security issue] was found with PHP 3 and 4 which has resulted in many hosting providers disabling file uploads (although patches fixing the security issues are available and a new version of PHP 4 has been released).

Because of this, and to cope with situations where hosts didn't allow such uploads anyway we have implemented various checks in phpBB2. These checks prevent you from enabling or making use of functions which will not operate correctly on PHP as installed on your server. At this time this includes locally uploaded avatars and DB restore.

Third party mods may also be effected but these are outside our control, you should contact the mod writer for more information.

Useful but missing documentation

In this section we will describe the documentation about the various aspects of the PHP programming language that we did not have, but would have wanted in order to better perform our security review using the SWAAT and Fortify 360 tools. In the following sections we will describe the documentation in detail divided into two parts: documentation useful for scanning with SWAAT and with Fortify respectively.

As group 3 already listed in their version of this section ... the following documents would likely have come in handy in one way or another while assessing phpBB2's security:

[Complete list of ESA Software Engineering Standard documents]

• User Requirements Document
• Software Requirements Document
• Architectural Design Document
• Detailed Design Document
• Software User Manual
• Software Transfer Document
• Project History Document

To us the most useful documents seem to be the Software User Manual, the Detailed Design Document and the Architectural Design Document. Since we're assessing the security of the phpBB2 web application it is trivial we require documentation about the source code and design choices, therefore the other documents seem somewhat obsolete as they're not tailored towards the implementation of software.