Do you find that your ip address occasionally gets banned by web servers? or maybe you experience your browser hanging when viewing particular websites. These could be caused by certain settings in your network card’s configuration.

Some network cards have a function called “Jumbo Frames” which is often enabled by default. We have experienced, and seen others referring to, this setting as a possible cause of connectivity issues. If you are experiencing the issues previously mentioned, you could try disabling this setting in your network card to see if that alleviates the problem.

For more detailed information regarding your specific network card, including instructions on adjusting this setting, you will need to consult your hardware manufacturer.

What is ModSecurity?

ModSecurity is a web application firewall module designed for use with Apache web servers. It provides an increased level of server security by protecting the server from vulnerabilities present in web application code. This increased security is achieved by detecting and preventing possible attack fronts before they reach the actual application. It is now estimated that over 70% of all attacks on web servers are carried out at web application level, hence the need for more secure web hosting environment.

VERSION-NEXT deploys ModSecurity on all of our shared Linux hosting solutions to ensure we are able to provide the most secure shared hosting environment possible for our clients. Whilst it is not a guaranteed solution to protect against all web vulnerabilities, it reduces the attack surface of our hosting environments and therefore reduces the chances of a security breach.

From time to time, having ModSecurity installed will mean clients may experience ip blocks if code on a client website is deemed insecure. These blocks can also occur when using applications that are attempting to communicate with the server in an insecure manner, which can be caused by trojans/viruses on your pc or other software programs or their plugins.

What attacks do the Core Rules protect against?

In order to provide generic web applications protection, the Core Rules use the following techniques:

• HTTP protection – detecting violations of the HTTP protocol and a locally defined usage policy.
• Common Web Attacks Protection – detecting common web application security attack.
• Automation detection – Detecting bots, crawlers, scanners and other surface malicious activity.
• Trojan Protection – Detecting access to trojan horses.
• Errors Hiding – Disguising error messages sent by the server

Troubleshooting ModSecurity Alerts

Though there are many things that can trigger ModSecurity when working on or accessing your site, the first things you should check are the following:

• When a server block occurs, a log file is created which highlights which files were being accessed at the time the block occurred. This needs to be thoroughly checked to ascertain what the problem is. There are many forums that discuss ModSecurity and these are the best place to go to for help working out what the problem might be.
• Are you using a good, dedicated FTP program such as FileZilla? Web browser based FTP clients have been known to cause issues with ModSecurity and are not programs we recommend using.
• Have you performed a thorough virus scan to ensure you have no vulnerabilities on your pc? You may want to also check all pc’s on your network just in case there is nothing lurking in the background.
• Do you have any plugins installed into your web browser that may be trying to scan the server or web pages you are visiting? Browser plugins can be very useful but have often been the cause of ModSecurity issues. An example of this is the Firebug plugin for Firefox which we have found to be the culprit of a number of ModSecurity alerts.

For more detailed information on ModSecurity and how it helps with server security, you can visit their website by following the link below. http://www.modsecurity.org/index.html

In addition to understanding the threats, and implementing general defensive strategies, it is important to know more specific details about security in Joomla, as well some specific examples of how to implement security strategies.

The developers of Joomla are constantly striving to improve the overall security of the system by employing good programming techniques and addressing security issues as they arise. It is therefore important to try to keep up with the latest version of Joomla – ‘patches’ (collections of replacement files) are released periodically to address bugs and security holes as they are discovered (click here to subscribe to the official Joomla announcements forum)

Input boxes
There are various input boxes that can appear in a ‘vanilla’ Joomla website – for example, search boxes, filters, etc., and the data entered in such features is always validated to ensure it does not contain quote marks – thus protecting against SQL injection attacks.

HTML Editors
It is also possible with Joomla to allow your website’s end users to submit news articles etc., and this opens up the possibility of cross-site-scripting injection where the data is allowed to be entered as HTML. Most HTML editors will not allow javascript or certain other tags to be entered though – for this very reason.

A problem arises here, because with Joomla, the same HTML editor is used both in the back end administrator and in the front end website. So if you, as an administrator, want to add some javascript or other ‘forbidden’ tag, you’re stuck. Some editors (eg. JCE) will allow you to specify which tags are allowed, and therefore give you the flexibility to add javascript etc., if you need to do so – but if you use these options, you must ensure that you don’t allow end users to use that HTML editor.

You can do this either by just not allowing user-submissions at all (which is the safest option), or by using 2 different HTML editors – the default one being restrictive, and an extra one which is assigned to your user record only (definable in Joomla’s User Manager) which can be less restrictive.

User Login
The login features of Joomla – both for the back end administrator and the front end website – make use of one-way password encryption. When you type in your password, Joomla applies an ‘md5 hash algorithm’ to turn your password into a 40-character jumble of unintelligible text – the same 40-character jumble every time. It never actually decrypts this, it just compares the jumbled up version of what you type in with the jumbled up version that is stored in the database against your user record to see if they match.

In order to determine whether or not you are logged in at any given time, Joomla uses a ‘cookie’ – a small text file which is stored on your computer. This cookie does not contain your user name and password – it just contains a session id (or reference number), which Joomla can look up to find out who you are and whether you are logged in. So even if someone could steal the cookie from your computer, all they would get is a reference number – they couldn’t do much with it.

Release Notes
The text files that ship with a standard Joomla installation include release notes such as a ‘change log’ – a list of changes made to the program since the last release. Such information can give away valuable clues about possible weaknesses that hackers can exploit. However, the text files are protected from casual viewing by being named as PHP files and by programatically preventing browsing over HTTP. Even so, it is quite safe to delete such files from your server – that way you can be absolutely sure that nobody can see them. At the time of writing, the release note files that can be safely deleted are: CHANGELOG.php, COPYRIGHT.php, INSTALL.php, and LICENSE.php.

.htaccess File
There is a file which is supplied with Joomla called htaccess.txt. As long as the file is called htaccess.txt, it has absolutely no effect on your site. Once you rename the file to .htaccess (“dot htaccess” instead of “htaccess dot txt”), it influences every request that is made of your site (note: this applies to sites running on an Apache web server, not IIS – if you’re not sure whether your site is running on Apache or IIS, it is probably running on Apache! 99.99% of Joomla sites run on Apache web servers. Apache is the name of the web server software, not the operating system – Apache can be run on Windows or Unix or Linux or FreeBSD, etc. etc. IIS only runs on Windows).

Typically, you would only rename the file to .htaccess if you wanted to use search engine friendly URLs (or SEF URLs) – the instructions in that file allow meaningful page names to be translated internally (or ‘rewritten’) into a format that Joomla can understand. There are many other uses for an .htaccess file though, including setting password protection on a directory, to block users based on their IP address, and various other things. This little file can be very powerful! It is therefore important to ensure no unauthorised person can view it, or worse still, edit it.

In addition to setting the file permissions (see below), you can add the following directive to the top of your .htaccess file to prevent others from being able to read it:

order allow,deny
deny from all

Version 1.0.8 of Joomla introduced significant changes to the supplied htaccess file, but even so it does not include the above directive for some reason. Maybe a future version will. In the meantime, adding the above at the very top of the file will provide an additional layer of protection against abuse.

It is also a good idea to protect your site against HTTP tracking and tracing, and if you use a shared server, the easiest way to do this is to add the following to your .htaccess file (somewhere after the “RewriteEngine On” command):

RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
RewriteRule .* – [F]

Please note, that making these changes to your .htaccess file is not supported by all server configurations. Always backup your .htaccess file before making changes to it, and if your website starts reporting errors, you may have to undo your changes.

Server Settings
Joomla specifies certain settings that are recommended for proper functioning of the system. A list of the recommended and actual settings is displayed when you install Joomla. One of the recommended settings is to have ‘Display Errors’ switched on. This is not safe for a production website. It is very useful when developing and debugging a site, but there is a security vulnerability in PHP (not Joomla, but the language in which Joomla was written) which allows cross-site-scripting attacks when the display errors option is enabled.

Thankfully, as of Joomla 1.0.8, you can suppress error messages by going to Site->Global Configuration, and clicking on the ‘Server’ tab. Set the ‘Error Reporting’ option to ‘None’. If you are not using the very latest version of Joomla, it would be a very good idea to upgrade!

Otherwise, to turn off display of errors, you need to change some settings in a file called php.ini – you might not have access to this file if you use shared hosting, but it might be possible to add your own php.ini file to the root folder of your website which will only affect your site and nobody elses (or you might need to add it to every folder that contains php files). Alternatively, depending on the configuration settings on your server, you might be able to override individual php.ini settings in your .htaccess file.

The settings that need to be specified in php.ini are:

display_errors = Off
html_errors = Off
display_startup_errors = Off
log_errors = On

For additional security it may be worthwhile disabling certain PHP functions. The following 2 lines, when added to php.ini will prevent the listed functions from working. If you have a third party script that relies on one or more of these functions, it will break when you turn them off like this. Joomla does not use these functions, but some third party components might do. Disabling these functions will help to protect your site from hackers though.

allow_url_fopen = Off
disable_functions = show_source, system, shell_exec, passthru, exec, phpinfo, popen, proc_open, tempnam

If you don’t have access to the global php.ini file, you might be able to add your own. More information about doing this can be found here: http://www.washington.edu/computing/web/publishing/php-ini.html. You might need to ask your host to restart the Apache web server before your overridden settings will take effect (this does not mean rebooting the server, just restarting Apache – which only takes a few seconds). Note: If you encode your PHP files with Zend Optimizer, adding your own local php.ini file can cause PHP to think that Zend Optimizer is not installed even if it is.

If your server configuration allows it, you may be able to just add the following lines to your .htaccess file to override the settings without needing your own php.ini file. Try adding the following to the end of your .htaccess file (if your server does not recognise the directives, you will get an error message when you try to access your site):

php_flag display_errors “0″
php_flag html_errors “0″
php_flag display_startup_errors “0″
php_flag log_errors “1″
php_flag_allow_url_fopen “0″

These settings will cause any PHP errors to be logged in a text file instead of being displayed in the user’s browser window. You could also write a custom error handler in PHP to display a user-friendly message when an error occurs, but that is a task for a developer and is beyond the scope of this article.

File Permissions
Every folder and every file that your website contains has a set of properties called ‘permissions’. These properties define who is allowed to do what with the file or folder. On Unix-based operating systems (including Linux, FreeBSD, etc.), there are 3 actions that can be performed on a file: read, write, and execute; and there are 3 types of user that can perform these actions: owner, group, and other (things are a bit different on Windows, but most production Joomla sites are hosted on servers running a Unix-based operating system).

Typically, the permissions for a file are set using a 3-digit number: 000 being the most restrictive (nobody can do anything with the file – pretty pointless having a file with that level of restriction!), and 777 being the most liberal (anybody can read, write, or execute the file – that is, execute as in run a program, not execute as in chop someone’s head off). The first digit represents what the ‘owner’ of the file is allowed to do (that is, the specific ‘user’ who created the file); the second specifies what other authorised users are allowed to do, and the third says what the world at large is allowed to do. The command used by the operating system to set the permissions of a file is called ‘chmod’ which means ‘change mode’.

To get the balance between security and usability, all folders should be set to 755, and all files should be set to 644 unless a folder or file specifically requires a different setting in order to function properly. Joomla has the ability to set these permissions for you (you can tell it to do this while installing, and through the Site->Global Configuration option in Joomla administrator) when it creates new files. Using 755 and 644 for folders and files respectively generally means that the files cannot be edited – not even by Joomla (unless your server has PHP configured to use SUExec – highly recommended!).

So if you want to install a new component, module, template, or whatever, you are going to need to make sure the relevant folders are writeable (775 and 774 for folders/files respectively, or if that doesn’t work on your server, 777 for both) – otherwise Joomla will not be able to create the necessary files. To see which folders need to be writeable, go into Joomla Administrator, click on the ‘Help’ menu item, then click on the ‘System Info’ link at the top right, then click on the ‘Permissions’ tab. There is a list there of folders that need to be writeable for Joomla to function, as well as an indication of whether or not they are currently writeable on your server.

It is safest to keep files and folders unwriteable most of the time and only make them writeable when you need to – especially with reference to the configuration.php file, which stores your settings from Site->Global Configuration (keep that unwriteable [ie. 644] except when you need to make configuration changes – and make it unwriteable again as soon as you’ve finished making changes). If your website allows for users to upload files though, you will need to make the relevant folders writeable all the time, otherwise the uploads will fail.

You can change the permissions of files and folders using an FTP client, or a hosting control panel such as cPanel or Plesk.

Backing up your website is an important task to perform on a regular basis as a precautionary measure, just in case your files are somehow lost or become corrupted. Luckily this is a fairly simple process which can be done in a few clicks through cPanel.

Backup

Log in to cPanel and click on the Backup link. You will be presented with this screen:

One of the useful features of cPanel backups if that you can restore them; for this reason we will only be generating partial backups, for full backups cannot be restored. Firstly, click on the “Home Directory” button to download your home directory, and then click on the MySQL databases you want to download. You can also download Email Forwarders or Filters if you want.

Note: The downloads will be contained within a .tar.gz file, a common Linux compression type. The zip extractor built in to Windows cannot extract these files; a good free program that can is 7zip.

Restore

To restore a backup that you have downloaded, simply browse to the backup in the relevant restore field on the backup page and click on “Restore”.

An update to the osCommerce 2.2 Milestone 2 version has been released that addresses security related issues and bug reports that exist in the released version.

It is recommended for osCommerce 2.2 Milestone 2 store owners to apply the changes to their installations due to the security issues and bug reports that have been fixed. The changes involved are minimal, do not break compatibility with contributions, and further strengthens the security of the shop installation.

This update release focuses solely on security related issues and bug reports, and does not introduce any new features that have been made for the next development milestone release.

This release is a full release package containing updated source files (including the updates from the 051113 Update release), documentation, and information on what changes have been made to easily apply to existing installations.

This update release includes the following changes:

* Magic Quotes Compatibility Layer Fix
* Parse GET Variables In Cache Functions
* PHP 3 Session ID XSS Issue
* Product Attributes SQL Injection
* Resize Images To Round Numbers
* Use The Correct Country Name Value When Formatting Addresses
* Prevent The Session ID Being Passed In Tell-A-Friend E-Mails
* Properly Remove Deleted Products That Exist In Shopping Carts

SSL Security Protection Tips
Without applying extra efforts to your connection on the internet you are wandering around an unsecured environment. Before you make administrative modifications to secure Zen cart and its database, you need to equip yourself with secure ways to make these modifications. Otherwise if someone is watching / listing to the information you transmit, it might not be long before your private business information becomes public. The bare minimum tools you should have are a shared SSL and FTP over SSL/TLS. These tools will encrypt the information you transmit and receive.

The following is a list of several steps you can take to secure your Zen Cart™ site:

1. Delete the /zc_install folder
Once installation is complete, delete the /zc_install folder from the server. Don’t simply rename the folder, as this leaves you vulnerable if someone were to discover this renamed folder.

2. Rename your “/admin” folder
It is recommended for additional security that you rename your admin directory after installation. This way, it will be significantly harder for hackers to find your admin area or attempt any attack on breaking into it.

(Before making the following changes, make sure to have a current backup of your files and your database.)

A – Open your admin/includes/configure.php, using a simple text editor like notepad. Change all instances of admin to your chosen new admin folder-name. For maximum security, you may want to consider that new folder name should include numbers and a combination of upper and lower case letters. The longer you make this folder’s name the more secure it will be. Make sure you leave all the / intact.

Change this section:

define(‘DIR_WS_ADMIN’, ‘/admin/’);
define(‘DIR_WS_CATALOG’, ‘/’);
define(‘DIR_WS_HTTPS_ADMIN’, ‘/admin/’);
define(‘DIR_WS_HTTPS_CATALOG’, ‘/’);
And this section:
define(‘DIR_FS_ADMIN’, ‘/home/mystore.com/www/public/admin/’);
define(‘DIR_FS_CATALOG’, ‘/home/mystore.com/www/public/’);

B – Find your Zen Cart /admin/ directory, using your FTP software or your webhost File Manager. Rename the directory to match the settings you just made in step A.

C – To login to your admin system you will now have to visit a new URL that matches the new name used in steps A and B above. For example instead of visiting http://www.example.com/admin/ visit http://www.example.com/NeW_NamE4u/ Use of SSL is highly recommonded to protect your and your customers information. To protect the new admin folder name from packet sniffers, use https in the example link above (this of course depends on your server having an SSL certificate installed).

D – You should also protect your admin area by using a .htaccess file similar to the one shown below, and placing it into /admin/includes. (This should already exist in Zen Cart versions 1.2.7 and greater.)

3. Set configure.php files read-only
It’s important that you CHMOD (set permissions) on the two configure.php files as read-only. Typically this means setting them to “644″, or in some cases “444″.

If you cannot do this with your FTP software, try using the File Manager supplied with your webhosting account.

If you’re using a Windows server, simply set the file as “Read-Only” for “Everyone” and especially the IUSR_xxxxx (Internet Guest Account) user if running IIS, or the “System” account or “apache user” if running Apache.

4. Delete any unused Admin accounts
Admin->Tools->Admin Settings

In your admin area, open the Tools menu, and choose Admin Settings – Check for any unused admin accounts, and delete them. Especially the “Demo” account, if it exists.

5. Admin Password Security
It is wise to use complicated passwords so that a would-be hacker cannot easily guess them.

You can change your admin password in Admin->Tools->Admin Settings, and click on the “Reset Password” button, or click on the icon that looks like a recycle symbol.

We recommend that you use passwords that are at least 8 characters long.

Making them alpha-numeric (including letters, numbers, upper-and-lower-case, etc) helps too.

If you are going to use normal words it is a good idea to join together two normal words that don’t normally go together.

6. Protect your “define pages” content in “html_includes”
After you have finished editing your define pages (Admin->Tools->Define Pages Editor), you should protect them:

A. Download a copy of them to your PC using your FTP software. They are located in the /includes/languages/english/html_includes area.

B. Make them CHMOD 644 (or “read-only” for Windows hosts). See notes above on CHMOD. /includes/languages/english/html_includes – and all files/folders underneath

If you make them read-only, then a would-be hacker cannot edit them if they gain access to your system, unless they can get permissions to change the read-only status, which is more complicated.

NOTE: Of course, once you set them read-only, then you’ll have to go and set them read-write before making additional changes using the define-pages editor.

7. Use .htaccess files to protect against unwanted snooping
In several folders, there are .htaccess files to prevent users from being able to browse through the files on your site unless they know exact filenames. Some also prevent access to “any” .PHP scripts, since it’s expected that all PHP files in those folders will be accessed by other PHP files, and not by a browser directly. This is good for security. If you delete these files, you run the risk of leaving yourself open to people snooping around.

There are also some semi-”blank” index.html files in several folders. These files are there to protect you in case your FTP software won’t upload .htaccess files, or your server won’t accept them. These only prevent directory browsing, and do not stop execution of .PHP files. It’s a good “alternative”, although using .htaccess files in ALL of these folders is the better choice, for servers that accept them.

Suggested content for .htaccess files in folders where there is an index.html file but NOT yet an .htaccess file would be something like the following (depends on your server configuration):

#.htaccess to prevent unauthorized directory browsing or access to .php files IndexIgnore */*

Order Deny,Allow
Deny from all

If your webhost configuration doesn’t allow you to create/use your own .htaccess files, sometimes they provide an interface in your hosting admin control panel where you can set the desired .htaccess settings.

It is recommended that you work with your host to configure these settings if this is the method they require. You need to choose — and use — the appropriate method for your server. As mentioned above, it’s best to work with your web hosting company to select and implement the best method for your specific server. We can’t tell you what to use for your specific server, but we offer these guidelines as a starting point.

8. Disable “Allow Guest To Tell A Friend” feature
You may wish to go to Admin->Email Options->Allow Guest To Tell A Friend and set the option to ‘false’. This will prevent non-logged-in customers from using your server to send unwanted email messages.

9. Protect your “images” and other folders
During initial installation, you are advised to set your images folder to read/write, so that you can use the Admin interface to upload product/category images without having to use FTP for each one. Similar recommendations are made to other files for various reasons.

However, leaving the images (or ANY other) folder in read/write mode means that hackers “might” be able to put malicious files in this (or other) folder and thus create access points from which to attempt nasty exploits.

Thus, once your site is built and your images have been created/loaded, you should drop the security down from read/write to read. ie: change from CHMOD 777 down to 644.

File/Folder permissions settings
On Linux/Unix hosts, GENERALLY, permission-setting recommendations for basic security are: – folders/directories: 755 – files: 644

On Windows hosts, setting files read-only is usually sufficient. Should double-check that the Internet Guest Account has limited (read-only) access.

Folder Purposes
The folders for which installation suggests read-write access for setup are these. If your site supports .htaccess protection, then you should use it for these folders.

/cache
This is used to cache session and database information. The BEST security protection for this is to move it to a folder “above” the public_html/htdocs/www area, so that it’s not accessible via a browser. (Requires changes to DIR_FS_SQL_CACHE setting in configure.php files as well as Admin->Configuration->Sessions->Session Write Directory)
/images
See other suggestions earlier.
/includes/languages/english/html_includes
See other suggestions earlier.
/media
This is only suggested read-write for the sake of being able to upload music-product media files via the admin. Could be done by FTP as an alternative. /pub
This is used on Linux/Unix hosts to have downloadable products made available to customers via a secure delivery method which doesn’t disclose the ‘real’ location of files/data on your server (so that people can’t share a URL and have their friends steal downloads from your site) /admin/backups
This is used by automated backup routines to store database-backups. Optional. /admin/images/graphs
This is used by the Admin->Tools->Banner Manager for updating/displaying bar-graphs related to banner usage. If not writable, feature is ignored.
Retrieved from “http://www.zen-cart.com/wiki/index.php/Important_Site_Security_Recommendations”

Vandals often use hacking techniques to deface a website or destroy data and files, but there are also those who just want to steal resources (make use of other peoples’ servers without their knowledge or permission) or to cover their tracks by stealthily making use of hardware owned by legitimate businesses to carry out processing for illegal operations or to relay spam and viruses to others.

The best defence against the majority of these types of attacks comes through installing and maintaining the latest versions of anti-virus and firewall software. As new threats are identified, updates are issued which can identify and neutralize most harmful operations before they have a chance to do any damage. Having a server fully managed by a reputable hosting company ensures that these defences are always in place.

Perhaps a more sinister threat is that of ‘black hat’ hackers, or ‘crackers’. As a general definition, ‘white hat’ hackers are enthusiasts who enjoy learning the intricacies (including weaknesses) of computer systems with no malicious intent, whereas ‘black hat’ hackers are those whose sole purpose is to break into systems and gain access to information and functions to which they are not entitled. The word ‘hacker’ was originally used to refer to the ‘white hat’ variety, whereas ‘cracker’ was used to identify ‘black hats’. The media have since latched onto the word ‘hacker’ almost exclusively in connection with ‘black hat’ hacking, and this is usually what is understood by the term ‘hacking’ today.

SQL Injection

One popular and potentially devastating method of attack is SQL injection. Any web application that makes use of a database usually communicates with the database for necessary functions using a special language known as ‘Structured Query Language’, or SQL. By issuing an SQL command to a database server, the web application can control virtually any aspect of the database – adding, editing, or deleting records or tables of data. Although a powerful tool in the hands of a software developer, SQL can become a lethal weapon in the hands of a hacker.

Of course, the web server would need to be configured in such a way that prevents third parties from issuing SQL commands to the database, whilst allowing legitimate requests from the web application to be processed. The problem arises though where a programmer incorporates user input directly into an SQL command – quite a common practise.

For example, a program might want to issue an SQL command such as this:

“SELECT * FROM users WHERE first_name = ‘John’”

This SQL command would request all of the records from the ‘users’ table in the database where the first name matches the value supplied (in this case ‘John’). In many instances, the value to be matched against will need to come from the text that is entered into a form on the website, so instead of the program explicitly using the value ‘John’, it would need to insert the text that was entered by the user – perhaps like this (using PHP as the programming language):

“SELECT * FROM users WHERE first_name = ‘” . $_POST['first_name'] . “’”

In this case, the value from the form (the $_POST['first_name'] bit) is inserted directly into the command. This would work fine for normal use, but if a hacker realised how this SQL command was constructed, he could ‘inject’ his own SQL command and perform any operation he likes on the database.

For example, instead of entering a value like ‘John’ in the website’s form, he could type something like this:

‘; DROP users;

The single quote mark and semi-colon will cause the original SQL command to end, and then the hacker can type any SQL command he likes to be run afterwards – in this case, the command ‘DROP users;’ would delete the users table from the database completely.

All user input must therefore be carefully validated by the programmer, especially before use in an SQL command, and in particular single quote marks should be either removed or ‘escaped’ – which means they are tagged with a special symbol (or ‘escape character’ – usually a forward slash ‘/’) that lets the database server know that the quote mark is part of the data and not part of the SQL command.

Cross Site Scripting (XSS)

Cross Site Scripting is a hacking technique whereby malicious scripting code (usually javascript) is injected into user input forms (in a similar way to SQL injection attacks) or incorporated in a URL query string. The threat is greatest when the user input is then output in a dynamically generated web page, and especially if the data is displayed as HTML code.

A malicious entry could include a piece of javascript which performs virtually any action on an innocent end-user’s browser (typically a hacker would try to get users to visit the infected page, often by posting links in forums etc), including cookie theft (enabling the hacker to then log in as the other user and access their account), or logging the user’s activity – for example recording keystrokes so as to intercept passwords etc.

The methods of counteracting cross site scripting are similar to those of SQL injection – all data entry (whether posted in a form or passed in a URL) must be carefully validated to ensure that it does not contain ‘special characters’ (such as greater than or less than symbols) which could allow scripting code to be embedded in the data. These special characters can be represented in hexadecimal notation as well as plain text, so both need to be checked for by the script. Where special characters are to be legitimately allowed, they must be converted to HTML character codes before being displayed in a web page – this prevents them from being interpreted as script by the browser.

Directory Traversal

A website is stored within a file system on a server. Some of the server’s file system is therefore exposed to the outside world and can be accessed by an end-user’s web browser. The part of the file system (or directory structure) that is visible to the outside world is limited to a specific root folder and its contents. Any folders higher up the hierarchy (ie. before you get to the root folder) are theoretically unreachable by the world at large – only authorised users who are logged in on the web server itself can access such folders.

For example, on the actual web server, you might have a directory structure similar to this:

home
username
public_html
images
downloads
private
documents
passwords

In the above example, the public_html folder is the root folder for the website. Anything underneath that folder in the hierarchy can be accessed by a web browser. All of the other folders are not accessible to the world at large because they are not located under the public_html folder.

In a directory traversal attack though, a poorly written script can allow a hacker to access those other folders and read their contents – just using a web browser. This is because a server-side scripting language, such as PHP, runs on the server as though it were a logged-in user – the scripting language has access to all of the folders and files, not just those underneath the root. If a script reads (or outputs the contents of) files on the server as part of its legitimate processing, it must be written in such a way that the files that are used cannot be specified arbitrarily by the end user.

Taking the above directory structure as an example, suppose there was a script on the server that reads the contents of a text file in the public_html folder and outputs it to the screen. If the end user were able to specify the name of the text file to be displayed, the script would need to make sure that the name they entered was still within the public_html folder. If they entered a file name like ‘..\private\passwords\passwordlist.txt’, the two dots at the start would tell the script to move up in the directory structure – effectively breaking out of the website’s root folder – and then the hacker can specify any file path he likes whether within the website’s root or not.

Therefore, where user input is used as the basis of files that are to be read (or more importantly, output) by a dynamic web page, the script must include a validation routine that ensures that the value entered by the user is legitimate and does not allow the directory structure to be traversed.

Denial of Service Attacks (DOS, DDOS)

A denial of service attack takes place when a hacker overloads a system with large or repeated requests for a service. For example, where a script requires some intensive processing on the server, if lots of requests are received at the same time, this can cause the server to slow down to such an extent that legitimate requests from others cannot be processed. In some instances, a denial of service attack can cause the server to crash completely.

In an effort to prevent denial of service attacks, many scripts which require intensive processing will only allow a single request from any one user (for example, by checking the IP address of the source of the request, and only allowing one request from that IP address within a certain time period). However, distributed denial of service attacks (DDOS) involve a hacker impersonating hundreds or even thousands of different users in such a way that the script cannot tell whether the requests are legitimate or not.

DDOS attacks are very difficult to prevent, but they can also be very difficult to carry out – the effort involved in executing such an attack without being traced means that in most cases it is not a worthwhile excercise from the hackers point of view; they would prefer to use easier methods of attack. If a server has strong defences in other areas though, and an attacker has a strong grudge against a company, a DDOS attack becomes more likely. For this reason, it is usually large corporations and financial institutions who suffer from these attacks.

HTTP Sniffing

HTTP stands for ‘HyperText Transfer Protocol’, and it is the mechanism used to transfer data from one computer to another across the internet. You can use HTTP to request information from a server, or to send information to a client by wrapping the request or data in a ‘packet’.

An HTTP packet consists of a header section which identifies the purpose of the packet (eg. to request a file), the destination (eg. the address of the website the file is being requested from), the format of the request (eg. what type of encoding is used in the main text of the packet), and whether the packet is in one part or has been split up and sent as separate parts (so the server can collect all of the parts it needs before dealing with the request), among other things.

Usually, HTTP packets wing their way across the internet from one machine to another without any human intervention, and without anyone seeing what the packets contain. However, the data in an HTTP packet is usually just plain text – it is not encrypted in any way and can easily be intercepted, read, and even changed en-route by anybody with the appropriate software and technical skill.

The programs used to intercept HTTP requests are known as ‘HTTP sniffers’ – and they are often used to ‘sniff out’ important information that can be used maliciously (there are also legitimate uses for HTTP sniffers – for example, they can be useful in debugging applications that rely on the transfer of HTTP packets). Any data sent over plain HTTP is therefore susceptible to interception, and must be presumed insecure.

For this reason, any sensitive data that must be transferred from one machine to another on the internet should not be sent as a plain HTTP packet. This includes login screens, and forms that collect sensitive personal information such as credit card details. In these instances it is usually best to use HTTPS.

HTTPS is very similar to HTTP; it’s just that the data in the packet is encrypted. So even if someone uses as HTTP sniffer, they will not be able to read any of the data without a special ‘key’ – and that key is held securely on the receiving computer. If a hacker tries to change the data, this will be detected by the receiving machine, because it will no longer be able to decrypt the package.

Other Tactics

There are numerous other tactics that can be used to break into a computer system, and these usually involve discovering weaknesses or loopholes in the server software’s defences. When a programmer writes software that runs on a web server, he tries to make sure that the software cannot be abused – but it can be very difficult to foresee every eventuality; vandals and hackers are always pushing software to the limit and trying out operations which the software was not designed to handle, in an attempt to discover a way in.

Usually, hackers practise using a copy of the software on their own server so that they can try out different tactics without getting caught – when they find something that works, they can then use it on other peoples’ servers. For this reason, it is often well-established server software that is the focus of the attack, rather than proprietary scripts written for a specific site.

Manufacturers and vendors of software packages for web servers often advise on configuration recommendations which will negate common attack tactics, but sometimes even the manufacturers are unaware of, or don’t bother warning about a loophole which can easily be exploited. For example, sometimes the default configuration options are geared towards making the software easy to use and powerful – rather than secure.

Installation log files, release notes, welcome screens, and various other files which are generally just ignored by server administrators can be the source of valuable information for a hacker. For example, just knowing which version of operating system your server runs can allow a hacker to exploit a known weakness in that particular version. If he cannot find out what version you are using, he risks being caught if he just tries out an exploit on the off-chance that it will be successful. It is therefore important to make the hacker’s job as difficult as possible by obscuring any information that could be used to identify what software and versions the server is using.

VERSION-NEXT’s new server security policies require PHP safe-mode ON and register global OFF
Below you can find some guidelines regarding fixing your shopping cart software

osCommerce

osCommerce will run with safe_mode on but you may get errors displaying on the screen, if you do, you need to make the following change

In includes/application_top.php change:

error_reporting(E_ALL & ~E_NOTICE);
to
error_reporting(E_ALL & ~E_NOTICE & ~E_WARNING);

Having register globals enabled is a very serious security issue; it allows an attacker to inject variables into the running PHP code. Just in case you don’t realise, this is a VERY BAD THING.

The patch for oscommerce to run with register_globals off can be downloaded from http://www.oscommerce.com/community/contributions,2097

Please make sure you carefully read the README file as it contains important information about the 2 ways the patch can be applied.

The ‘patch’ consists of the following:

1/ A set of instructions (rather than a ‘patch’ file) that you may use to manually apply the changes to an existing code tree. This is useful if you already have modififications made to the OSC source code and you want to apply this patch on top.

2/ A set or pre-patched files. These files are EXACTLY the same as you would get if you applied the patch instructions to a clean copy of OSC. This is useful if you are performing a clean installation of OSC and therefore have no worries about just copying over existing files with new versions.

>>> You only need to use either the manual instructions or the pre-patched files; NOT both <<<

Cubecart

Cubecart will run with safe_mode on and register_globals off, but you will need to upgrade to the current version 3.0.12 [Security-Patched-1]

Zencart

Zencart will run with safe_mode on but you may get errors displaying on the screen, if you do, you need to make the following change

In includes/application_top.php change:

error_reporting(E_ALL & ~E_NOTICE);
to
error_reporting(E_ALL & ~E_NOTICE & ~E_WARNING);

The company issued a warning Wednesday stating there had been limited, targeted zero-day attacks exploiting a vulnerability that could allow code to be remotely inserted into a computer. The announcement came 24 hours after Microsoft released patches for 20 other flaws in its products, including six for Word.

The attack targets Office 2000 and Office XP. According to Microsoft, a user must first open a malicious Office file sent by an attacker via e-mail or some other method for the attack to launch. The company urged users to be cautious when opening unsolicited attachments, and has added detection capabilities to the Windows Live OneCare safety scanner to thwart the attacks.