Purpose of Phobos

This slight web-page portal has for main focus - security in coding and design. This means - that very strict rules are applied in any operation that affects the security of data and access to the system.
As this is an ongoing project, and with time, every developer learns more about the required functions/functionality he might require, chances are that not all functions are using all subfunctions to simplify the process. However the plan is here to actually convert all functions to use the subfunctions. Reason for this is that these subfunctions are optimized for security, it will shorten the code - and if a Bug is detected, only one place needs to be fixed.

Short Feature List

• Secured design wherever possible. All data-submissions are type-checked, if only certain variables are accepted, these are also enforce.
• Dynamic Blacklisting. If some requests come in, the system detects URL manipulations, stores the originating IP with existing details, and on the third request blacklists actively that site.
• For migration from old websites, a redirection function can be activated to redirect with HTTP Code 301 all pages according to a mapping array
• ACL's can be enforced on user-base.
• Dynamically configurable list of many configurations, as the status options through a DropDown DB.
• A central security initialization is enforced
• Modules can be added easily by respecting several rules. Check the documentation DropDown for existing and installed modules
• Localization is doable, support is available on a per application base only though

If anyone wants to participate in development, send an E-Mail to the Webmaster, and he'll provide source-code access. Note that this code is written using the GPLv3 license, and as long as a certain set of functionality is not finished, will not be released.
The following does apply:

• By Default - global variables will be disabled
• Include files will not rely on the document-root of the web-server
• All files containing access specific information - as Database access etc. will not be in document root.
• The following base Directory Structure exists:

  # All include file, config files etc. are in here.
  # Note that access to this directory is restricted through web-server configuration.
  # Directory type: restricted.
  ./includes
  ./includes/theme
  ./includes/theme/default
  # Directory type: restricted.
  ./logs
  # Admin.User contributed Modules
  ./modules
  ./modules/user_access
  ./modules/user_access/documentation
  ./modules/user_access/images
  # Template Directory - all default to modules, apps etc. are stored in here.
  # eventually also coding templates
  ./templates
  # All variable data as generated by rrdcollector, mrtg etc. go in here.
  ./var
  ./var/rrd
  # Document Root - All Public accessible Files are here.
  ./site
  ./site/tmp
  ./site/theme
  ./site/theme/default
  ./site/webapps
  ./site/documentation
  ./site/harvester
  ./site/images
  ./site/var
  ./site/var/rrd
  

• All data coming from remote systems, or being sent to remote systems - will be filtered. All variables used for internal manipulations will be initialized clear - then only have a value assigned to them.
  html entities and mysql_real_escape_string will be used to handle all data to be entered into the system
• The system will be built as modular as possible. E.g. all functions will be in local classes that can be called upon request.
• all user action will be logged in a central Loggin repository - e.g. logger function.
• A default set of icons is to be used for core functions. All icons will reside in <DocumentRoot>/images
• For error handling and debugging - decent functions will be made available. The developer however will need to include these.
• Every function will require a decent explanation in front of it !!! explaining what it does - how to use it - and how the result is. This partly applies to all files.

   /**************************************************************************
   *
   * @function user_welcome
   * @description user.php Displays User Welcome message.
   *
   * @author Joerg Mertin <smurphy(-AT-)solsys(-DOT-)org>
   * @version $Id: maindoc.html,v 1.21 2014/06/18 16:15:52 smurphy Exp $
   * @param string - $msg - authentication message from login, default="Error"
   * @return returns a HTML-Formatted Welcome Message
   * @module core
   * @package phobos
   * @class user
   * @end user_welcome
   */
  
  

  This is actually used to send a parser script over the source code and generate a decent programmer library/function/class description. Of course - certain of these information don't make sense to be included everywhere. Example would be a parameter description in a main functionality file - which only handles the switch statements depending on the user's request. You also don't need a version information inside a function - as that one is usually handled by RCS on the beginning of the file.
  Please note that the @function/@end tags are mandatory. The parser script uses these to identify start and end of a function call.
• Database table names have 2 prefixes:
  * One standard prefix - giving a user the possibility to host 2 different web pages in the same database (as found on some hosters configurations) - default phobos
  * _core_ or _mod_.
  core: Identifier for core-table - provided by the system
  mod: module tables - used by modular extensions. Note that it is possible that a module/extension uses core functions - thus does not require own tables (this is specially true for the content-DB

Programming/Structural Guidelines

Every module/core functionality needs it's own include file. First step in this include file - is a function with the name of this functionality which will contain switch statements for all kind of functionality - passed through a GET requests. This function will then decide of the following functionality.
Please note that this behavior is mandatory, especially for modules or addons to certain functions (such as the admin function).

• op defines the functionality to call, e.g. reporting
• action the function called within the functionality. Always define a fallback default for this function

Example. The reporting function will have the following files: report.inc, report.php (or admin.php - this depends on where this file will be called from).
reports.inc will have one function called handler() taking care of all action switches. The Actions could be: write, list, edit etc.. For every action, one function report_write, report_list, report_edit has to exist. This way - the functionality is well defined into functions - and easy to be worked on after by another developer.
A 1st authentication step is to be performed in the main php-file calling the functionality, but all other security related functions are to be done in the switch, e.g. here handler() function.
NOTE: This separation is security related - as the standard switch relies in the main php-file located in DOCUMENT_ROOT, as this function is outside of DOCUMENT_ROOT...

Technical Details

 Mainfile  - main.inc - Loads all files below, class declarations, db-connect and session-initialization
               |- config.inc - General site configuration
               |- basic_functions.inc
               |- authentication.inc
               |- <theme_used>/theme_function.inc (header/footer functions defined here).
               |- session.inc - session and token class/functions
               |- init_site.inc - General site initialization, error and session handler declarations.
               < Page code >

Login behavior varies upon situation

• In case a failed login is detected on a valid user - a 15seconds timeout is activated - preventing this user to login again during this time. This is to slow down robot-targeted attacks.
• For certain forms - a token identifier and timeout is set - to invalidate this request. This to prevent from spoofed/remote manipulated forms
• A re-authentication is forced all 7(default, can be configured) days - for the persistent login functionality to not be copied over to other systems
• If a user logs in from another computer - a previously existing session will be disabled, e.g. force a re-authentication from another computer.
• All critical change requests need to be authenticated
• All credentials - are encoded. User-Cookies even encrypted, and on every page request - verified
• No user-data identifiable data is actually stored on the user-system - as random-generated identifiers are used for re-identification. In short - for a authenticated user, random generated tokens will be used in the cookies for persistent login identification. This excludes the possibility to gain access through cookie-theft.
• All user-transactions (be. login) are ssl encrypted using https
• An authentication class has been generated to handle all authentication operations - and it is not allowed to use any other function
• Session data is not kept on the file system. All Session Data is held in a data base - handled by an own session manipulation function. Also - the encryption vector used to encrypt the random generated user identifier is stored in this session DB. This encryption vector combined with the user password will provide a random token stored on the user-side as a cookie. If any of the required information to decrypt the user-cookie fails - the session will be invalidated and the user will have to re-authenticate.
• An error-handler has been written to enable better debugging - dumping the error messages to an own location - and better displaying errors
• A blacklisting system is active. This means that certain actions - which are typical manipulation attempts, will trigger the site blacklisting system which will lock out the remote IP for a certain period of time.

Harvester Trap

The harvester-trap puts a Link on the home-page - to make sure the Bots do find this page. The configuration of this setup makes sure - that if a robot does not go into this directory - it is not affected, e.g. honors the RFC's. However - some Bot/Spammers don't care about the Robot/Disallow tag - thus go into everything just to find E-Mail Addresses. This security function will just give the bot what he wants - one page every 20Seconds with random links pointing to itself, Infinite. If a Bot is catched - it won't get out of this page for a very long time. That's the aim. Note that the version running on these pages also has a blacklisting included. E.g. after the 3rd page all - the requesting IP will be denied access.

To activate this Harvester trap - enable it in the config.inc file and make sure the following applies:

• Make sure the php extensions sysvsem and sysvshm are installed
• Verify that the .htaccess file in the harvester directory of your phobos installation has shows the right path.

  ErrorDocument 404 http://www.solsys.org/harvester/index.php 

  We use the Error_Document handler to redirect the bot to that page again. However - we will fake a good return code later in the script to give the bot a valid 200 Ok ;) Make sure your Web-Server allows the Override option for this specific directory. E.g. in your apache.conf file, you should have something like:

  # Allow special override on Harvester Directory
  <Directory /srv/www/htdocs/site/harvester>
  Options None
  AllowOverride All
  Order allow,deny
  Allow from all
  </Directory>

• In your DocumentRoot - put a file: robots.txt with the follwing content:

  User-agent: *
  Disallow: /harvester/

  if the harvester script is located in the harvester Directory.
  Modify your php.ini file to disable expose_php.

  # Make sure your php.ini file disables expose_php ...
  expose_php = off

  If you use phobos-website - this should be handled by the built-in init functions.

Requirements

• PHP 4.3 or later, however development is done under php 5.x

$Id: maindoc.html,v 1.21 2014/06/18 16:15:52 smurphy Exp $