Website Security Strategies

Resource: http://www.netshinesoftware.com/security/website-security-strategies.html

The following strategies should be considered by anybody who is responsible for a website which contains potentially sensitive data or who is concerned about vandalism and hacking. These strategies apply equally well to Joomla and non-Joomla sites.

* Fully managed servers in secure data centres with latest software patches. A fully managed server in a data centre will automatically be kept up-to-date with the latest service packs, security releases, and patches. This is the most fundamental way of protecting the system and databases.

* Hardware and software firewalls. Firewalls monitor network activity and can be configured to allow or block operations on the server, and to monitor suspicious activity. A combination of high quality hardware and software firewalls provides a strong level of protection against most types of attack and hacking attempts.

* Anti spam/virus software. Servers must be configured in such a way as to provide the ability to trace the source of e-mails in order to protect against spam relaying. Software is also available to help identify spam and of course anti-virus software should always be kept up-to-date on the server. There are also tools that will automatically block IP addresses of known spammers and trouble-makers, and that can help to prevent or control the effects of other types of attack (eg. DDOS).

* Disable directory browsing. Many web servers allow file directory structures to be browsed over HTTP. This reveals vital clues to the configuration of the system and the software it uses, and is an open invitation for a hacker to explore parts of the site that were never meant to be publicly available. Directory browsing can easily be disabled, and just enabled on the specific directories where it is required.

* Configuration files held securely and read-only where possible. Many web server software packages make use of plain text configuration files which are used to specify the basic settings for the program. If these configuration files are publicly readable, again they can give vital information to a hacker (such as the credentials needed to connect directly to the database). Worse still, configuration files are sometimes publicly writable – meaning a hacker can change your application settings and do serious damage to the website.

Wherever possible then, configuration files should be hidden from public view, and read-only. If a configuration setting needs to be amended, the file can be made writable temporarily whilst the change is carried out, and then set back to read-only again afterwards.

Your Ad Here

* Turn off error reporting in PHP – use error logs instead. By default, when PHP is installed on a server, it is configured to display all levels of error and warning messages to the user. This is fine and useful when developing a system, but error messages can contain alarmingly important information about the inner workings of an application and configuration of the server.

Instead of displaying errors to the user, PHP can be configured to log errors in a file on the server. This is by far the best option for a production website! Make sure the error log file is stored securely and is not publicly readable.

* Basic validation of requests to run scripts. A script file on a web server may be necessary to perform a legitimate function, but often it is wise to check that the user has followed a valid path through the website before being allowed to run the script. There are simple checks that can be made by a script before it runs any critical processes to check that the request is legitimate (eg. to verify that the user is logged in and has sufficient permission to perform the action). Although not fool-proof (clever hackers might be able to find ways to impersonate a legitimate request), such validation provides another line of defence against malicious attack.

* Release notes, install logs, etc. deleted. Installation of server applications often results in various sundry files being left lying around unnecessarily – for example, release notes which detail all of the changes that have been made to the software since the last release, or log files which list all of the operations performed by the installation program.

These files may contain clues that will help a hacker identify weaknesses in the server configuration. Any such files should therefore be identified, and if they are not absolutely necessary, they should be deleted. Care must also be taken by server administrators to avoid leaving files lying around on the server where others can see them unless they are meant for public consumption.

* Form and URL input always validated (especially where SQL commands are involved or the data entered will be displayed on a dynamic web page). The data that is processed by online form submissions can wreak havoc if it is not properly validated. This is especially true when the data needs to be used in an SQL command, or if the value entered will be displayed in the browser, as the possibility of a malicious SQL injection or cross site scripting becomes a real threat.

Your Ad Here

Basic validation of the data submitted should therefore be routinely performed on all user input, paying special attention to preventing the evaluation of injected code or cross site scripting.

* Server side processing wherever possible. It is always safer to process data on the server rather than the client, because once the script has been handed over to the client for processing, it is open to abuse by hackers: they can amend validation scripts to allow input that is not valid, effectively bypassing any processing that they don’t want to run.

Having said that, there are times when it is useful to make use of client-side scripting technology such as javascript and flash – but it must be used with caution, and only for non-critical purposes. For example, javascript could be used to display a popup calendar, making it easier for a user to enter a date – but even so, the date entered also needs to be validated on the server side.

* Cookies only used to hold session IDs or tokens – no personal data. Cookies can be a useful way of maintaining state in a web application, but it makes sense to restrict their use to information that will be meaningless to an outside observer. Rather than storing user name and password information in a cookie, with the possibility of interception and discovery, store this information on the server, associate it with a session id, and store the session id in the cookie. The session id will then mean nothing to anyone else, but the server will be able to identify to which user it belongs.

* Disable the HTTP TRACE option (using mod_rewrite if necessary – eg. on shared server). This is another case of an application’s default setting being insecure. The very popular Apache web server comes with a standard feature to enable debugging of applications over HTTP. This feature can be used maliciously to compromise server credentials and even to gain root level access to the system – giving a hacker free reign to do as he pleases.

It is not always possible to ensure that the TRACE option is turned off in apache – especially if using a shared server which is managed by a third-party hosting company. However, the feature can be effectively turned off for a specific domain name by using the ‘mod_rewrite’ function of apache – anybody who tries to access the TRACE function will then be redirected harmlessly.

* Use vulnerability scanners and static analysis tools to check for known hacker exploits. There are tools available, some of which are open source, that can scan a server or website for the most common weaknesses and exploits, and provide corrective advice. Usually, these tools are regularly updated with the latest discoveries by ‘white hat’ hackers, so the site can be regularly tested and corrective action taken if needed. Naturally, ‘black hat’ hackers also use these tools to probe web servers for weaknesses.

* SSL wherever necessary/advantageous. ‘Secure Socket Layer’ (SSL) technology is used to provide encryption of HTTP packets for use over HTTPS. In order to encrypt, a security certificate is needed from a trusted certificate authority.

There are various levels of encryption, the strongest being 256-bit. A lot of browsers still do not support 256-bit encryption though, so most 256-bit SSL certificates will downgrade themselves to 128-bit on such browsers. 128-bit is still considered very secure, but it is feared that within a few years (as computer processing power increases) it may be possible to crack them.

Processing performed over HTTPS is of necessity slower than HTTP because the data has to be encrypted, signed, and packaged at one end, transmitted, and then unpackaged, checked, and decrypted at the other end. For this reason, HTTPS should only be used when necessary – the delay is noticeable enough to make it undesirable for processing non-sensitive data such as normal website page requests.

* One way encryption of passwords. All passwords held in databases should be one-way encrypted - this means that it is impossible to decrypt them. In order to check whether a user has access to a part of the system, the password they type in is also one-way encrypted, and compared to the stored encrypted password - if the two encrypted passwords match, access is granted, but at no point can the passwords actually be decrypted.

* Audit trail. Any actions that involve updates to important information in the databases should be logged in an audit trail, with the date/time, nature of the amendment, and the identity of the user who made the change.

* Use mod_security. If using the Apache web server, installing the mod_security module can provide additional protection against many common forms of attack over HTTP (ie. using exploits in web applications).

Your Ad Here