Knightnet Site Design - Site Security
General Security Background and Issues
The Knightnet web site has very simple security requirements.
- "Hackers" should not be able to easily alter the web content or structure
Actually, even if they did, the master is stored offline as can easily be written back to the live web site. - Some content should be further protected from viewing and/or editing
This is mainly for dynamic content such as the worship resources area which contains some copyright material. The security requirements for this are still pretty basic and are well served by a simple security system based on mySQL and browser cookies. - No email addresses should be visible
Harvesting of email addresses by unscrupulous spammers is a real problem, to prevent this, no user email addresses are stored anywhere on the web site and all contact is via a form which can never deliver the destination address to the client.
Choice of Web Server
Having worked with Microsoft's Internet Information Server (IIS), I know how appallingly insecure it has been over the years and so never recommend it as a tool.
On the other hand, although Apache has had its share of issues, they are typically fixed very quickly. Also, Apache does not tend to suffer from some of the security design issues IIS does.
Along with being multi-platform (allowing me to develop on a Windows laptop but host on Linux), its very wide ranging support from web hosting providers and its high level of configurability even when run as a web hosting service, Apache really is the web server of choice.
It is interesting to note that Apache runs over 50% of the globes web servers and, at the present time (Jan 2003) at least, is still gaining market share on IIS.
Oh, of course, it is also FREE!
Securing Sections of the Site
Apache, by default, allows users to use a file called .htaccess
This file is able to contain a good range of security and other settings as can be seen from the example provided here.
In particular, through the use of
This example file also demonstrates use of Apache's "mod_rewite" which gives very good control over what URLs are delivered to users and the specification of customer error pages.
The final main security element the example shows is the overriding of the PHP include path. This is where PHP will look for files it cannot find in the current folder. It is useful for hiding away codes such as database access passwords, email addresses and code that you do not want people to have access to.
Example .htaccess
# --- PHP FLAG OVERRRIDES --- # Override PHP include path to include std folder outside html doc path # NOTE: Change the include to match your requirements php_value include_path ".:/somewhere/outsite/the/www/folders:/usr/local/lib/php" # Ensure register globals is OFF for security php_flag register_globals off # Ensure max compression on sent http php_flag zlib.output_compression on php_value zlib.output_compression_level 9 # --- --- # Add .htm files to php processed list to fool search engines # use .php & .htm for php processed, .html for static AddType application/x-httpd-php .php .htm # --- SECURITY --- # Ensure that .htaccess files cannot be accessed by web browser <Files .htaccess> order allow,deny deny from all </Files> # Ensure that PHP Include (*.inc) files cannot be accessed by web browser <Files ~ "^\.inc"> Order allow,deny Deny from all Satisfy All </Files> # --- ERROR HANDLING --- # Redirect errors to site index: 404=No found, 500=Server error, 403=Forbidden, # 410=Gone, 302=Temp moved # Means that visitors will ALWAYS get a good page with links ErrorDocument 403 /common/403.php ErrorDocument 404 /common/404.php ErrorDocument 500 /common/500.php # --- REWRITES, PAGE MOVES, ETC --- RewriteEngine on RewriteBase / # Ensures that requests for index.html files are redirected to .htm - NOT REQUIRED? #RewriteRule index\.html$ index.htm # Strip ?KNIGHTNET_LOGIN=... for msn referals and robots, etc. (Temp?) # -- NOT WORKING on remote site - WHY? -- #RewriteCond %{QUERY_STRING} ^(.*)KNIGHTNET_LOGIN #RewriteRule ^(.*)$ $1? [NC,R=permanent] # Fix & problems for rogues (Temp?) RewriteCond %{REMOTE_ADDR} ^217\.33\.119\.113$ [OR] RewriteCond %{REMOTE_ADDR} ^66\.244\.207\.138$ [OR] RewriteCond %{REMOTE_ADDR} ^24\.56\.140\.240$ [OR] RewriteCond %{REMOTE_ADDR} ^65\.102\.23\.161$ [OR] RewriteCond %{REMOTE_ADDR} ^63\.148\.99\.253$ RewriteRule ^(.*)&(.*)$ /common/ampproblem.htm [R,NS] # Page Move redirections RewriteRule ^Copywrite(\ |_)&(\ |_)Privacy\.htm /Copyright_&_Privacy.htm [NC,R=permanent,L] RewriteRule ^IT/Anti_Spam.htm /IT/Anti_Spam/index.htm [NC,R=permanent,L] RewriteRule ^IT/SpamAssassin.htm /IT/Anti_Spam/SpamAssassin.htm [NC,R=permanent,L] # TEMP for those trying to access music sub folders ##RewriteRule ^Worship(\ |_)Resources/Music/ /Worship_Resources/ [NC,L] # --- Should be able to remove these after a few months --- # Handle broken browsers (that stop at spaces) RewriteRule ^travel(\/*)$ /Travel_&_Outdoors$1 [NC,R=permanent,L] RewriteRule ^worship(\/*)$ /Worship_Resources$1 [NC,R=permanent,L] # Fix mistake in link in opalfaq for SLURP RewriteRule ^IT/Contacting.htm /Contacting.htm [NC,R=permanent,L] # Fix broken Scooter RewriteRule ^Copyrite%20 /Copyright_&_Privacy.htm [NC,R=permanent,L] RewriteRule ^Copyrite_ /Copyright_&_Privacy.htm [NC,R=permanent,L] # rewite spaces to underscores RewriteRule ^(.*)\ (.*)$ /$1\_$2 [R=permanent,L]
General Security Background and Issues
The Knightnet web site has very simple security requirements.
- "Hackers" should not be able to easily alter the web content or structure
Actually, even if they did, the master is stored offline as can easily be written back to the live web site. - Some content should be further protected from viewing and/or editing
This is mainly for dynamic content such as the worship resources area which contains some copyright material. The security requirements for this are still pretty basic and are well served by a simple security system based on mySQL and browser cookies. - No email addresses should be visible
Harvesting of email addresses by unscrupulous spammers is a real problem, to prevent this, no user email addresses are stored anywhere on the web site and all contact is via a form which can never deliver the destination address to the client.
Choice of Web Server
Having worked with Microsoft's Internet Information Server (IIS), I know how appallingly insecure it has been over the years and so never recommend it as a tool.
On the other hand, although Apache has had its share of issues, they are typically fixed very quickly. Also, Apache does not tend to suffer from some of the security design issues IIS does.
Along with being multi-platform (allowing me to develop on a Windows laptop but host on Linux), its very wide ranging support from web hosting providers and its high level of configurability even when run as a web hosting service, Apache really is the web server of choice.
It is interesting to note that Apache runs over 50% of the globes web servers and, at the present time (Jan 2003) at least, is still gaining market share on IIS.
Oh, of course, it is also FREE!
Securing Sections of the Site
Apache, by default, allows users to use a file called .htaccess
This file is able to contain a good range of security and other settings as can be seen from the example provided here.
In particular, through the use of
This example file also demonstrates use of Apache's "mod_rewite" which gives very good control over what URLs are delivered to users and the specification of customer error pages.
The final main security element the example shows is the overriding of the PHP include path. This is where PHP will look for files it cannot find in the current folder. It is useful for hiding away codes such as database access passwords, email addresses and code that you do not want people to have access to.
