Stargate Logo  Secured by phpPhobos

Smurphtools   
  Login  - No Account?  Create One   
Search 
Monday, 23 April 2018  -
News FeedRSS Feed
rss rdf  
  Home 
  Authentication 
 Documentation 
    Site Documentation 
    About me 
  Legal Notice 
 Applications 
    Web Links 
 RC Models 
    RC Models 
    RC Batteries 
 Modules 
    Downloads 
    Weblinks 
 Blacklists 
    Blacklist 
    Blockout 
    DNS Blacklist 
 Registered Bloggers 
  Blog de Maiwenn 
  Blog de Morgane 
  Joerg's Blog 
 FAQ  [ Topics  ]
 Routerboard RBxxxAH 
 Common Linux problem... 
 Apple Mac-mini 
 PHP Phobos 
 Stargate's Backup sc... 
 eBook Reader / PRS-5... 
 RC Models 
 Server in SolLan 
 System Stats [ Index ]
 Router
  > Gateway 
  > AP 
 Server
  > Nas 
  > Stargate 
 Client
  > RemPi 
Documentation for
images/smurphtools.gif
phpPhobos V2.0-432
The phpPhobos web-site is the attempt to create a Web-site with security in mind (actually, in the design, structure and programming of the software). Everything is done using the pessimistic approach (Everything is denied by default, and specifically allowed to happen. This way, forgotten things cannot harm). Also, a way for the site to defend itself has been implemented into the very structure of it by the means of Harvester trap and dynamic blacklisting. Very fine grained ACL allow users to divulge their data, but they have to explicitly allow it. And in the end, everything is logged, even deleted data is kept through the logger function in the Database.
Author Joerg Mertin  smurphy(-AT-)solsys(-DOT-)org 
Website  http://www.solsys.org 
Documentation    Main   License   FAQ   Changelog   TODO 
Last change: February 05 2018 19:11:35.
phpPhobos Web-Portal

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

The file main.inc needs to be loaded by all code requiring authentication and using functions/classes provided by the phobos web-pages
 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

The following rules apply:
  • 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 $

 
Problems to  admin(-AT-)solsys(-DOT-)org  - best viewed @ 1920bpp
This site is powered by phpPhobos v2.0b432
© J. Mertin smurphy(-AT-)solsys(-DOT-)org 
Icons - Copyright Breeze artists GPL 2+