xtc ['ekstəsi]: The feeling when ICT succeeds

English

What is the GX Website Security plugin for CMSimple?

The GX Website Security plugin is a script designed to take on the burdon of dealing with certain common security problems in PHP scripts.

It is made to immediate, transparent security of varying types. Far, far too often you hear about scripts having some common vulnerability - people just aren't careful enough when writing scripts. This script is desiged to try to compensate for some of this carelessness.

Originally it was based on the Cafe CounterIntelligence PHP Website Security Script from Mike Parniak.

It is a plugin for the CMS CMSimple (XH).


What can the GX Website Security plugin defend against?

HTTP request floods

This was the type of problem that the script was originally designed to deal with.

Programs can be created to flood your website with GET or POST requests in order to bog down the CPU, generate thousands of emails, fill up databases, or whatever. Very few scripts are set up to deal with this type of attack, and commercial webhosts are prone to discontinuing your account if you are the victim of one (it's their machines that get bogged down). This script helps protect against this type of attack.

Script display vulnerabilities

By far the most common vulnerability in PHP scripts.

Users find a cgi variable that will be displayed verbatim, and pass through some HTML code (generally some javascript code) that will send a user's cookies or what-not, to their webserver. They use this information to steal their login or worse. The GX script has the ability to "sanitize" all GET, POST, and COOKIE data to convert the < > characters to their displayable but non-executable versions. This generally negates the danger of this type of vulnerability.

General flood protection

An additional ability of this script is to perform time-based checking for flooding of a particular function. This means you pass it a unique identifier, such as "messageposts" and a time value, such as 60 seconds... and optionally a threshold number (default 1), and the function will return TRUE if it has been called more than <threshold> times by the same user, without the time value number of seconds between the calls.

IP banning via .htaccess

As an option (that defaults to on) this script can modify your .htaccess file to ban the IPs of users who are abusing your website. This will drastically reduce CPU load due to their attempts, and prevent them from further trying to abuse your system.

For this to work, the script must have write access to your .htaccess file (if one exists).

HTML source viewing/stealing

The script can automatically wrap pages in a javascript function which either uses the commonly used "escape" obfuscating technique, or GXSecurity's own encryption method which makes it impossible to get the actual source just using the document data. It stores the key to the encryption in a cookie, which changes with each request - so unless a user captures the cookie data at the same time as the document, they cannot decrypt it properly after the fact!

Block blacklisted IP addresses (RBL)

The script can automatically identify blacklisted IP addresses and ban them to avoid that known spammers access your website and try to hack it.

Block visitors from user-defined countries

Your website is often visited from users that reside in countries from where hackers and/or bots operate with the main target to abuse your site.

This script gives you the possibilty to individually ban visitors who came from these countries.

Detect URL cracks and injections

The script can automatically detect attacks that are attempted using URL cracks and injections.


How do I use this plugin?

Installing GXSecurity

You just copy the plugin into the plugin folder from CMSimple - that's it!!!

Ok, since you want something to be edited and saved it will be required to chmod some folders and files. In the plugin folder you will have five folders - config, css, languages, log and lib - which you have to chmod 777. Same for the files in these folders.

Furthermore, you have to connect the plugin with your template. Simply add the following line to the very top of your template.htm:

<?php echo GXSecurity();?>

resp. if there are problems in admin mode:

<?php if (!$adm) echo GXSecurity();?>

Configuring GXSecurity

There are a set of variables in the configuration that you should look over and tweak to your liking.

Variable Value
usehtaccessbans 1 = modify .htaccess to ban IPs
0 = don't ban IPs
filterGETvars 1 = sterilize HTML tags in GET variables
0 = don't
filterCOOKIEvars 1 = sterilize HTML tags in COOKIE variables
0 = don't
filterPOSTvars 1 = sterilize HTML tags in POST variables
0 = don't
extraPOSTprotection 1 = use the extra POST protection
0 = don't
extraGETprotection 1 = use the extra GET protection
0 = don't (not recommended!)
checkmultiPOST 1 = only allow maxmultiPOST number of successive POSTs
0 = don't care
maxmultiPOST Maximum number of POST operations in a row, if checkmultipost is on
zipcompress 1 = Compress pages using GZIP library (lower bandwidth, higher CPU)
0 = don't
compresslevel Compression level for zipcompressing, from 1 (low) to 9 (maximum)
cpuloadmonitor 1 = block access if over a certain system load
0 = don't
cpumaxload Maximum 5 minute system load average before blocking access
gxsessionpath if not blank, sets a directory path to store session files
filterblacklistedIPs 1 = filter IPs that are blacklisted
0 = don't
dnsbl_lists DNS-based Blackhole List
filtercountries 1 = filter countries from countryfile
0 = don't
crackcheck 1 = check for cracks and injections
0 = don't
countryfile name of the file with the country codes to block
crackfile name of the file with the crack and injection expressions to detect
badattempts number of bad attempts before banning the ip in .htaccess or give a message that too many rapid accesses were done
logheader header of the logfiles
logcycle Cycle of logfiles: <D>aily (one file per day), <M>onthly (one file per month) or <Y>early (one file per year)
logdelimiter Delimiter between fields in the logfiles
httpBL_key Personal http:BL access key from the Project Honey Pot.
If the variable is empty, the test will be skiped.
httpBL_spamthreat Score of spamthreat (default = 1)
Detailed informations see http://www.projecthoneypot.org/httpbl_api.php
httpBL_otherthreat Score of other threats (default = 40)
Detailed informations see http://www.projecthoneypot.org/httpbl_api.php
checkbothost 1 = recheck host for robots (user agent)
0 = don't
checkhosttype 1 = Standard (gethostbyaddr())
2 = *nix (faster then 1)
3 = Win (faster then 1)
waitingtime Time in seconds to wait before a new access is allowed after a blocking

Any of the options that are more CPU intensive, or might cause problems, have been disabled by default. Trial and error will let you figure out which options are best for your site.

Possible Concerns: GZIP encoding / HTML encryption

If you want to use either of these options in conjunction with GXSecurity, you need to make sure your site does not already use gzip encoding. If it does turn it off in your script and enable it in GXSecurity instead. You cannot use HTML encryption if you use your script's own gzip buffer because the gzip buffer needs to be put into place before the encryption buffer. GXSecurity makes sure the user can accept gzip encoding before using it, so don't worry about using GXSecurity's gzip rather than your own script's.

Possible Concerns: POST variable sanitizing

Some script systems let you or other users post HTML codes in articles, messages, signatures, etc. If your script requires that, make sure to keep the POST sterilization off, or it will convert all the < > characters into ;lt ;gt instead. If you don't require any of that, turn it on - it should greatly reduce the chances of running into cross-site scripting problems (people stealing your users' cookies and such).

Possible Concerns: CPU Monitor

It just runs uptime and snags the CPU load from the result. It's probably smart to leave this off. It's absolutely unsure if this will ever help, or if it's just going to slow things down because it has to execute an external command... Use at own risk!


Known problems

To make work the internal editor from CMSimple (OEdit) correctly with GXSecurity, "session use_trans_sid" has to be "OFF" in PHP.INI or GXSecurity should be able to modify PHP variables. More informations about this should be find here: http://www.php.net/manual/en/ref.session.php.

Multi level forms are blocked by checkMultiPost blockiert, resp. maxmultiPost has to be configured on a high value. With checkMultiPost on OFF entries are relatively protected, because it is always tested if calls are done to quick in sequence.


Warranty

There is no warrenty using this plugin. It will be used on everybody's own risk. We will not assume any liability in case of data losses caused by GXSecurity usage.


Where to find GXSecurity?

The latest version of GXSecurity could be downloaded here.


Help and questions

Help and questions only in CMSimple forum and/or CMSimple wiki please.


See a way GXSecurity can be improved?

I am not an expert on website security or PHP, so if you see a way to improve on any aspect this plugin, just contact me over my website.

 

© 2007-2015 by Gerd Xhonneux, xtc