Composr Tutorial: Security

This tutorial details and explains Composr's security features and provides a lot of general advice for maintaining security.

The developers have put a lot of effort into making Composr very secure. We:

• perform the practices of producing secure and robust code
• scan and scrutinise security hot-spots (such as database queries)
• design the Composr architecture to abstract away common security hot-spots wherever possible
• have designed Composr to actively detect and log possible security issues via defining and enforcing tight interfaces into Composr, and consistency rules
• develop on our own version of PHP that can detect XSS security holes and potential errors via automatic type-conversion problems

If you find a flaw in Composr's security please contact us so that we may have time to fix the problem before hackers get a chance to exploit it on innocent users.

Overview of security features in Composr

Here is a list of the main security features in Composr…

Passwords:

• Visual representation of password quality
• Password complexity rules
• Password expiry and prevention of re-use
• Password hashing with configurable ratchet (even if hackers steal the database they won't have actual passwords; controlled via "Cryptographic ratchet" option)
• Configurable cryptographic complexity ratchet to protect against brute-force techniques to convert hashes back into passwords
• Temporary passwords, so that staff may set up accounts without needing to know the final password that will be used

Login restrictions:

• Approval process when a member accesses via a new IP address (a form of two-factor authentication) [optional, per-usergroup]
• IP address banning, including wildcard banning
• Integrated blocks/escalation-process for IP addresses identified as malicious, using various third party services
• Login sessions are locked to IP address, so that if a hacker steals a session ID they cannot normally use it
• Configurable session expiry time (shorter = reduced potential for a hacker using a stolen session ID, longer = more convenience)
• Ability to prevent privileged actions being performed by users who were automatically logged in via cookies (it forces them to confirm their login); ability to reverse ("concede") a confirmed login to help improve security around insecure workstations that are kept logged in
• Approval of new members (optional)

Auditing systems:

• Audit logging of almost all administrative actions
• Logging of all user actions and IP address history
• Sophisticated tools to analyse the above
• Logging of failed logins
• Hack attack detection / logging / banning (described in further detail in this tutorial)

Framework security:

• CSRF-attack prevention (Cross-Site-Request-Forgery) via referrer checking and form security tokens
• Click-jacking prevention via CSP implementation
• Documented policies for meeting secure programming standards (in our Code Book and our standards checklist spreadsheet)
• Scanning techniques to automatically enforce most of our security standards, such as:
  • automatic monitoring and scanning of database queries to confirm they were composed in a secure way
  • disabling of common attack vectors by default such as 'UNION' database queries (only enabling them when necessary)
  • automatic input sanitisation in standardised input-access APIs
• Configurable levels of HTML filtering, to prevent XSS attacks (Cross-Site-Scripting attacks)
• Our own version of PHP used during development – featuring strict types and a detector for XSS security holes
• Our Code Quality Checker tool has the ability to scan for security hotspots in the code (areas that need careful quality reviews)
• "Kid-gloves modes" that automatically impose restrictions and filters on third-party code unless the programmers of them explicitly declare that they understand key security issues
• Prevention of attacks carried out by the upload of malicious files, via various forms of automatic filtering. Per-directory disabling of PHP code as an extra level of security (Apache-only)
• Prevention of access-control-bypass via manually downloading privileged files via URL via automatic filename obfuscation
• Prevention of directory listing attacks in deep directories, via empty index.html files
• Disabling of common insecure PHP features such as "register globals" and "allow URL fopen"
• Automatic enabling of a number of Suhosin features designed to improve security, and coding standards that allow our code to work with them. Suhosin is an unofficial extension to PHP that adds extra security constraints
• Prevention of "jumping-in" attacks against deep framework code via a secure code modularisation standard
• Automatic imposition of limits, to prevent exploitation of bugs leading to the draining of computational resources
• Following of many other security best practices, such as those espoused by WASP (for example, we protect against session fixation)

Other features:

• Privileges and access permissions to restrict privileged functionality
• Validation process for content submission
• Rootkit detector system (manually generate security signatures representing the state of the website, to compare to previous ones)
• Many spam-prevention systems (outside the scope of this tutorial)
• Automatic download of new web application firewall rules (for emergency patching)
• Many moderation systems such as warnings, probations, and bans (outside the scope of this tutorial)

We are always coming up with new ideas for security. If you want us to keep going further then you can consider sponsoring new ideas posted on our development tracker.

Advice for webhosting

Your ideal webhost should:

• Have the PHP OpenSSL extension
• Ensure the server is configured well for SSL (it should not allow degrading of encryption ciphers that are known as insecure). There are tools to help you scan.
• Keep the server patched with secure versions of software
• Have suEXEC or equivalent (if it is shared hosting), and PHP open_basedir. This is described below under "Optimum server environment for shared hosting". It is much better to actually have a VPS, Cloud IaaS hosting, or a dedicated server.
• Not install unnecessary server services (as this increases the likelihood of an attack – it just takes one system-level vulnerability to take a server down)

You should consider:

• Enabling SSL for the whole site (soon web browsers are going to be giving out warnings when you browse a website that is not fully running SSL)
• Using CloudFlare for the free DDOS protection, or a more advanced service such as SiteLock or Sucuri

You should be wary about:

• PHP "Safe Mode" (the name is very misleading, at best this introduces bugs and mitigates the problems on shared hosting environments that are already fundamentally insecure)
• PHP "disable_functions" (this increases security by disabling arbitrary parts of PHP – this should only be done by consent with a programmer, to confirm those parts that were decided to be disabled are not actually necessary for functionality)
• PHP "magic quotes" (this does not add any actual security due to fundamental design problems, but does have the potential to create lots of bugs)
• ModSecurity (Composr does have inbuilt features, as described above – and ModSecurity rules have a tendency to block legitimate administrative requests, such as use of Commandr or theme editing)
• Suhosin/SuPHP (actually Suhosin/SuPHP is okay if you have control over its settings or know for sure that nobody is going to set anything that is too restrictive)

The best way to ensure your hosting is secure is to choose a webhost that you're confident in and/or a server management team who will carry out their system administration tasks diligently. There are a thousand ways a bad host or a bad team could make things insecure, but if they stick to default/careful software configurations and industry-standard practices then usually things will be in decent shape.

Optimum server environment for shared hosting (advanced)

It is an unfortunate fact that shared webhosting environments are almost always very insecure, as different users with hosting accounts on the web server may interfere with your files on a number of levels. In addition, by extension, if one of the other accounts on the server becomes compromised, your files could also be.

This section is highly complex, the summary to it all is that if you care about security a lot, don't use shared webhosting. The risk of the host, or you, getting it wrong, is very high.

If you run a website with particularly privileged information, or security is critical for other reasons, we highly advise you operate your web server from a dedicated server(s).

The main issue with shared hosting, is that, unless either:

1. the environment for hosting accounts is restricted to being PHP-only, with open_basedir (which we advise) enabled
2. or, the server is set to run web scripts on different hosting accounts using the account holder usernames (suEXEC)

then every web-server-created/writable file, and your database, is fully writable to by any other account holder.

suEXEC means that PHP scripts load up under the user of your own hosting account, and are constrained as such too. open_basedir restricts PHP to only operate within the directory of the hosting account, although it has performance problems.

If you are fortunate enough to be in situation 2 (suEXEC), but not fortunate enough to be in situation 1 (open_basedir), then Composr needs special configuration to make best use of it. You need to make it so that no files are 'world writable' (which is the case unless you have suddenly switched to this environment) and so that _config.php and any _config.php.bak.* files are not world writable or world readable (to protect your database password). So, preferably you'd have both suEXEC and open_basedir. Composr is clever enough to detect your situation, and hence will not chmod any PHP-created-files to a world-writable state as it normal does (it normally does this so that both the account holder user and the web server user have write access to this file – and making them world writable is the only way to achieve this in a hosting environment).

Webhosts may use "jail shell" and ensure home directories are not world-readable. These are further mitigations against account-vs-account tampering. So actually ideally you would have suEXEC, open_basedir, jail shell, and well configured home directory security.

More information about suEXEC is provided in the Webhosting for Composr tutorial.

Is suEXEC really safe?

You may find claims that suEXEC is a security concern.
The fact that suEXEC is now extremely common-place, without disaster having unfolded, disputes this quite well.

However, here's my more serious rebuttal…

He makes 3 points:

1. The web server has to run with root permissions if it is to initiate web requests under the appropriate permissions. That's a risk in any event.
2. You could set it up wrong and cause terrible problems. The suEXEC authors themselves warn of that.
3. With suEXEC, scripts on an account have full control of the files on that account.

Regarding point 1, that's true, but only if there's a vulnerability found in Apache. Lots of things already run under a server with root privileges, so could have vulnerabilities also. i.e. this doesn't change the state of affairs that much. If there's a vulnerability, Apache will be patched and hosts will update.

Regarding point 2, I disagree. Hosting control panels come with a whole configuration for the services on the server. This isn't a case of every host manually configuring suEXEC, it's a case of the control panels knowing how to do it right and automatically rolling it out correctly for all users of those hosting control panels.

Regarding point 3, I agree and disagree. He is correct to say there's a risk, but it's one of these "you can't avoid crossing the street" kind of scenarios. Modern web systems should be able to have deep control over their own files. For example, if you're installing or uninstalling addons in Composr, you don't want to have to manually handle everything, you want Composr to be able to self manage itself. Sometimes we just have to accept that to have good progressive functionality, we need to take certain risks, and then mitigate those risks.

Testing the security of a webhost

If you don't have a well-configured server, anybody with an account on the server can mess with anybody else with your account. In other words, if someone wants to hack your site, they just need to sign up with the same webhost (assuming they only have one server, and many unfortunately do), or they just need to find any one single site on the server that is hackable (it's easy to find sites on the same server, and people are often running stuff that is very easy to hack).

There's a simple way you can test the security without needing a full understanding of LAMP (Linux/Apache/MySQL/PHP) configurations. Here's a very simple script that you can upload (just save it as filesystem_browser.php):

Load up the script by URL, and see if it lets you browse up the filesystem and then into other hosting accounts.

The script just tests read access. Depending on the server configuration, you might have access to write any file in another user's directory that has been given '666' permission or was originally created by the web server itself. Even if you don't have write permission though, you can probe into the configuration file for the PHP software they have installed and find MySQL access details, and then you can easily install phpMyAdmin on your hosting account and give yourself full read/write access to their database.

It's scary stuff: you probably never imagined security for a website could be so poor. So, please make sure you check your host is competent before putting too much faith in them.

I am not exposing any security holes in LAMP software here, but what I am exposing is how inept many webhosts are. Hosting is cheap, they often cannot afford to hire people who have a good understanding of security for a website, so be wary.

Advice for website maintenance

Advice for website maintenance:

• Never connect using FTP (passwords are sent in plain text, so anyone with administrative infrastructure access between you and the server can read them)
• Never use IMAP or POP3 e-mail unless you have SSL turned on for it (again, passwords are sent in plain text)
• Use secure passwords, according to best practices
• Don't re-use passwords across different services (if one is found you don't want everything to tumble like a house of cards)
• Keep your own computers secure and patched (if your own machine becomes infected and you are being targeted actively by a hacker then anything you do becomes exploitable)
• Remove the master password from the _config.php, only put it back when you need access to Composr's low-level configuration/upgrade system

Some philosophy

There's always a trade-off between security and convenience. Before inconveniencing yourself too much bear in mind that for very high-grade security you need:

• Regular user training
• Regular audits of user behaviour
• Regular monitoring
• Regular reading of logs
• Immediate system patching whenever security updates come out
• High-availability of system administrators to solve any problems rushed security updates could cause
• Secure storage of all backups
• High-quality processes for all system management tasks

Any weak point can and will be exploited by a persistent hacker who has a strong motivation. For example, even if your software security is perfect, they can likely use a confidence trick ("social engineering") to persuade one of your users to give up their passwords. Or, anyone with the resources can do a DDOS attack against you, which is similar to a sit-in protest at a real-world organisation.

Also bear in mind there is basically no protection from government agencies who have a reason to target you or one of your users. Secret court orders may result in system implants that you have no way of detecting.

The point I am trying to convey is that you should decide on an appropriate level of security for your particular organisational needs, and ensure that everything necessary for that level is maintained. If you or your users are touching on anything that security services could be interested in, you'll be exposed regardless of what you do.

Security logs

Composr defines a large number of 'hack attack' situations, and in case of any of these situations occurring it will: stop the execution; send out an e-mail detailing the attack; and log the attack in the security log. These situations are varied, but the most common is when input is found that does not match input constraints (for example, a script parameter which should be a number is not).

Security logs can be reached from:
Admin Zone > Audit > Security logging

If you get alerts that suggest someone is actively trying to hack into your website, it is advisable to ban their IP address at the web server level as soon as humanely possible (unless they have already been automatically banned). This is just a precaution, but it is possible (although unlikely) that a skilled hacker who is referring to Composr source code has only accidentally triggered an alert, and may have found an alternative vulnerability in your site already, or may find one soon. Of course we know of no such vulnerabilities, and we do in fact consider it unlikely that a direct vulnerability will be found in Composr, but it is always best to be cautious with regards security. You should also be aware that a hacker may change their IP address, simply by changing their Internet connection, or working through proxies: you may decide in this case of a serious attack, to consult authorities, passing them the IP address of the offender and the hack-attack e-mail.

Most security logs are accidental (caused by mistyped URLs, or buggy software) or are caused by bots. The screen-shot shows a typical hack-attack by a bot that crawls the web looking for vulnerable scripts: in this case, the bot is trying to use a parameter of the Composr poll voting form to send an e-mail, on the basis that by trying to abuse every form it finds, it will eventually find one that does work as a spam relay: it would then latch on to this and use the victim website as a mass spam relay, for as long as it can. In this case it hit a Composr site, so was logged.

Alert types

The following types of alert are defined:

• DODGY_GET_HACK, A suspicious URL was given that includes characters looking like they may be there to do dodgy things. As URLs are generally clean of symbols, it is safe for Composr to detect dangerous looking ones, such as file system paths, new line characters, and HTML symbols
• REFERRER_IFRAME_HACK, It looks like someone tried to abuse an iframe in Composr, where the iframe URL was given by the main page URL. By doing this, social engineering, or referrer faking, might be achievable – not currently in use, we now use alternative and more reliable CSRF-prevention methods
• EVIL_POSTED_FORM_HACK, This may be due to a social engineering attack, where a logged in administrator has been tricked into filling in a form targeted to delete something from the website (CSRF)
• VOTE_CHEAT, The user tried to vote outside the allowed range of options (e.g. 11 or -2). I can think of no way this could be done accidentally
• SCRIPT_UPLOAD_HACK, The user tried to upload a PHP script. This may well be innocent (if they are uploading a saved web-page with .php in the URL for example, or if they are uploading a script they expect people to be able to download in raw form)
• ASCII_ENTITY_URL_HACK, The user introduced HTML into a Comcode HTML tag that used ASCII-encoded entities. This is likely to be innocent, but is blocked because it can be used to trick JavaScript filtration
• SCRIPT_URL_HACK / SCRIPT_URL_HACK_2, This is highly likely to be a hack attempt, as a user explicitly specified a URL which was code and not a real URL
• LAME_SPAM_HACK, This is a blocked spam attempt, where a Guest user posted with the terms [link and <a within a single post, almost certainly a common kind of "try everything" attempt to get spam links posted (Composr does not even support a link bbcode tag)
• TRY_TO_DOWNLOAD_SCRIPT, The user tried to add a download with a manual URL that links to private files that are not meant to be downloadable. This may be an honest mistake – but if it is _config.php, then it is very likely to be a hack attempt. A more detailed explanation follows further in this tutorial
• TICKET_OTHERS_HACK, The user tried to access support tickets from another user. This is either a bug (we know of no way it would happen normally), or a hack attempt
• TICKET_SYSTEM_WEIRD, The user tried to access a support ticket with an non-standard name. This is either a bug, or a hack attempt; if it is a hack attempt, it is probably not one that would get anywhere even if it was not blocked
• ORDERBY_HACK, Tried to change the SQL ordering attribute, perhaps for SQL injection
• BYPASS_VALIDATION_HACK, The user tried to specify that their content be validated even though they had no form option to specify it as such. The user is therefore very likely to be trying to hack the site by specifying options that don't exist for them in the hope they will go unfiltered
• HEADER_SPLIT_HACK, A URL was submitted that contains a blank line. The submitter of the content with this URL is very likely to be a hacker, as there is no conventional way this situation could be come by
• EVAL_HACK, The EVAL command would have executed arbitrary code if it was not blocked. This is extremely likely to be a hack attempt and should be taken seriously
• PATH_HACK, Tried to use a file path redirection to get outside intended directory
• PHP_DOWNLOAD_INNOCENT, Somehow a PHP file got referenced in the download system. This should have been filtered by 'TRY_TO_DOWNLOAD_SCRIPT', but was not. This is a serious security breach if it happens
• BRUTEFORCE_LOGIN_HACK, Someone gave incorrect login details 30 times over a 15 minute period (brute-force attack)

After a number ("Hack-attack ban threshold" option) of hack-attack attempts an IP address will be banned, if the "Enable auto-banning" option is enabled.
Similarly and more specifically there are a number of options specifically attached to the brute force login detection for automatic bans.

The "TRY_TO_DOWNLOAD_SCRIPT" error in detail

The full error is:

Tried to add a downloaded file that points to a script: so they could get the script contents (e.g. passwords)

The error is saying that the server tried to check the URL was valid but that it found the downloaded file was different to what there was on disk. That suggests to Composr that there's a security issue, that some kind of script is behind the URL, and therefore to not allow a 'trusted' relative URL to it because direct access could bypass security layers. If you really do want to link to a script you can via an absolute URL – Composr never trusts absolute URLs.

This error could also be caused by some server configuration issue too. For example:

1. If the server cannot download files from itself properly to check, and whatever it does manage to access is returning HTTP '200' (file found) messages. This seems unlikely but it can be surprising what weird situations happen "in the wild".
2. If something on the server is interfering with downloads. Something like the new Apache mod_spdy module could cause something like this. That might alter images during transfer and Composr would not receive the file it expected to be checking.

Input filtering

The "Avoid broad input filtering security layer" privilege turns off filtering that may result in some data loss. Without the privilege it adds an additional level of security in case we have an actual security hole at another layer.
This generally protects against:

• Request parameters that look like the file paths of particularly sensitive files
• Request parameters that look like particularly dangerous HTML, or miscellaneous vectors for injecting CSS or JavaScript code

It is generally a good idea to not given untrusted users this privilege, as the need for such users to be able to post text that looks like file paths, dangerous HTML, or JavaScript, is not very high.

There are many privileges relating to Comcode filtering. These are detailed in the Advanced Comcode tutorial.

We also have of internal checks that always run, many related to "Alert types" (see above), including:

1. Constraining of input parameters for filename-only scenarios (filter_naughty, PATH_HACK)
2. Constraining of input parameters for codename-only scenarios (filter_naughty_harsh, EVAL_HACK)
3. Checks for URL fields, e.g. making sure "data:" URLs are not submitted, or special characters that could allow interference with HTTP headers (DODGY_GET_HACK)
4. Checks for posted JavaScript URLs ("javascript:"), anywhere (SCRIPT_URL_HACK_2)
5. Referrer checks, to make sure POST requests aren't being made from non-trusted sites (i.e. CSRF-prevention, EVIL_POSTED_FORM_HACK)
6. Input field length, so that strangely long parameter inputs are not accepted in most cases (this was removed, it didn't raise security, and created bugs)
7. External redirections, so that hackers can't create URLs linking to your site that immediately redirect you to an unsafe third-party site (this kind of thing can trick users into thinking they have clicked onto your site, when they're not there anymore). This isn't logged as a hack-attack, as it can happen too innocently, but it is filtered out.
8. Obvious spamming (some common spam patterns are so obvious, we can just route them direct to LAME_SPAM_HACK)
9. Click-jacking frame protection, using standard X-Frame-Options functionality
10. Generally making sure things are filled in when required, and expected numbers really are numbers

We also have standard output escaping mechanisms so that attempts to inject bad data do not lead to bad outcomes.

In summary, we have defense across a number of layers, and code without making poor assumptions. This is called "defense in depth" – programmers are fallible, so it's best to have multiple lines of defense.

Anti-spam measures

Failed logins

robots.txt

To remove the possibility of search engines indexing the login screens of your Admin Zone you can create a robots.txt file on the root of your domain name:

I also added a line there to say where your XML Sitemap is.

File-type white-list

In the security configuration, Composr defines a list of file types that may be uploaded to the website, via the various upload mechanisms that exist in Composr, such as that of the download module and the attachment system. By default, this white-list is roughly (this is not kept up-to-date):

• sql,odt,ods,ps,pdf,doc,txt,psd,tga,tif,gif,png,bmp,jpg,jpeg,avi,mov,mpg,mpeg,asf,wmv,ram,ra,rm,qt,mov,zip,tar,rar,gz,wav,mp3,ogg,torrent,php

It is important to understand that there are two sides to the security of file uploads:

1. on the server-side, it must be impossible for a file to be uploaded that might execute on the server, instead of download (such as a php file). You may have noticed that php is an allowed file extension in the list: this is because php uploads are explicitly blocked internally, but only in the situation where the file would be stored on disk with its original extension (which the attachment system does not do)
2. on the client-side, it must be impossible for a file to be uploaded that might get downloaded and automatically execute a malicious action on a client computer. One example of such a file type is, to the surprise of most, 'html'. .html files can contain JavaScript, which could be used, if the file was downloaded from the main website domain, to transmit the user's login cookies to any arbitrary hacker. Therefore it is crucial that html files, and other files (swf,fla,svg,xml are suspected to be dangerous at this time) are not added to the list

Protect your domain name

It is important that you don't use a public domain name, or give people access to upload their own sites to your domain. If you do, basic web browser security walls will be broken down, and someone malicious could use techniques to extract your access from you. Giving other's access to subdomains is generally okay, so long as you are careful to configure your cookies so that only the main domain can read them.

Protect your session security

We recommend the 'Enforce IP addresses for sessions' option is left enabled. If you are on some kind of network such as TOR where your IP address may randomly change, we advise to not use this when administering Composr – it will greatly reduce your security. If you have an ISP where your IP address changes very frequently, you may want to consider a more reliable ISP.

For a break-down of the risk of disabling this option, see this tracker discussion.

Client-side measures

Referrers

All users with privileged access should have referrers enabled in their web browser. Without this, Composr can't prevent malicious requests being redirected through to your own website's forms from other (malicious) websites.
By default browsers do have referrers enabled, but some firewall products may disable them for very minor privacy reasons (to stop a website knowing what link you followed to get to it, which most people would agree is not really a privacy issue to them at all).

To check you have referrers enabled, go to Commandr (Admin Zone > Tools > Commandr) and type:
You should get a URL back that is a URL under your own website.

If you get a blank result, or something like 'unset' or 'hidden', you need to find out why referrers are disabled and re-enable them.

Techniques for increasing security further

This section details some techniques to increase the security of your site. Most of these techniques are either advanced, or unattractive for most Composr users, which is why they are not included in the default Composr configuration.

Guest access

In order to reduce the risk of hackers gaining unauthorised access to areas of your website, you could close down access to all possible areas except to vetted members. These options are located in Admin Zone > Setup > Configuration > User/usergroup options. By default, Composr is set up to deny guest access to almost all of the site; however, security can be improved further by only allowing members to become fully joined after a manual vetting process.
To force members to be vetted, you need to enable the 'Require member validation' option, as shown in the screen-shot.

SSL

If you have a dedicated server which is configured with an SSL/TLS certificate, tied into your domain, and if the server is configured to use the same file system for HTTPS as for HTTP, then you may choose to make certain pages work via HTTPS.

SSL certificates vary in price immensely, but the price generally depends on the strength of encryption, the prominence of the root certificate authority (a more respected authority may charge more because it carries out more checks, and thus experienced users feel more confident with it), the distance from the root certificate authority the certificate is, and the validity length.

You may decide to do this if the pages transmit confidential information; obvious targets are the login and join pages.

Assuming you have already installed the SSL certificate on the server, you can set up SSL in Composr as follows:
Go to the Admin Zone > Security > SSL/TLS (HTTPS) configuration, and tick (check) the boxes for the following pages… :join, :login, site:purchase, site:shopping, site:members. (These are the pages that purchases or passwords happen on – but you can enable for other pages too if you like)
(this assumes that you have the ssl addon installed)

If you are not able to use SSL, don't think that your site is very insecure: it probably is possible for a hacker to gather the password during transit, but it would not be easy. Sometimes when we consider computer security we lose sight of the insecurities we face every day: it is possible a death cult could take over your office for a week while fighting off the military with heavy rocket propelled grenades: likelihoods need to be kept within proportion. This said, if you have very sensitive information, or run an eCommerce site, SSL is essential, as the stakes are high enough for criminal interest to be stimulated. There may also be concerns with government surveillance.

Note that a page viewed under HTTPS must use HTTPS for all images and other embedded files. The banner will be disabled on any page set to use HTTPS via the ssl addon to make sure this requirement is enforced (if your whole base URL is https then banners will display and it is up to the webmaster to make sure they are HTTPS-compliant). The reason for this is that users should not get mixed environment messages that warn them about potential security problems, or in some browsers lock out the whole page. Template makers and coders should be careful to use the proper Composr mechanisms for referencing resources.

Under HTTPS user provided media that is not linked under HTTPS will either be automatically upgraded or proxied.

You can set HTTPS for a whole site via changing the base URL. In this situation the banners restriction will not be applied, as the webmasters are assumed to have set up HTTPS-compatible banners for everything.

Migrating HTTP websites

If you are on Apache then you can add this to your .htaccess file:

On IIS you can add another rewrite rule to web.config:

Don't just redirect HTTP traffic to the root of the domain because that could hurt your SEO.

Secured zones

Composr has "confirmed" and "non-confirmed" sessions.
When you login to the Composr site you have a "confirmed" session. If you then come back to the site and automatically are logged in via cookies then that session is "non-confirmed". This distinction is common on many sites as a security feature.

It is possible to configure zones so that they require a confirmed session to access them. This means that a user can only access the zone if they have actively chosen, in the specific web browser window that is currently being used, to login: login cookies alone cannot gain them access.

This might seem like a very strange thing to enforce, but there is a very good reason: it is very easy for someone to create a malicious website that contains a form with a target of your website, such that that form directs a malicious action when you are tricked to fill it in and click 'submit'. If a barrier of a required session was not imposed, this action could go unabated with your access level direct to perform some malicious action by proxy through you. These kinds of attacks are called CSRF ("Cross-Site-Request-Forgery").

Additionally, if someone else accesses your computer you don't necessarily want the cookie login to let them have complete website control.

The Admin Zone is configured to require confirmed-sessions by-default because it has lots of very dangerous features. You may choose to also secure the site zone in the similar fashion.

Essentially the idea of confirmed vs non-confirmed sessions is a trade-off. You can maintain cookie-based logins, but to do the higher level of actions you need to confirm yourself.

Composr does provide a secondary defence against this scenario, by checking referrers, but we do not consider referrers secure based on two facts:

1. this seems an area where there may be web browser vulnerabilities, or unfortunate situations, that lead to inaccuracy of this data
2. user firewalls, ironically, often block this data (for privacy reasons), preventing us from using it to add to security

We also have security tokens on forms as a third defence.

Conceded mode

Conceded mode is a link to turn a confirmed session into a non-confirmed session if you worry someone else might use your computer while you're away (for example).

It is a bit like a partial log out.

Restricting logins

_config.php (when suEXEC is not enabled)

By default, _config.php is left 'world-writable' by the installer if suEXEC is not enabled. This allows the Installation Options editor to work with it, and allowed the file to be initially filled, but does represent a potential security risk on a shared server.

While many files are world writable, this file is a particular target, because it may be executed. Therefore if someone on a shared server can write to the file, perhaps via shell access, then they can execute code on your site, possibly unnoticed. It is worth noting that if they had shell access, they could trash your database and uploads anyway, but not so easily execute code on your domain.

To solve this problem, simply remove execute permission for the _config.php file.

It may seem an obvious solution, to not use an executable file to store configuration information. However this file contains critical data, and therefore if it was a file that would be downloaded if accessed instead of executed, this critical data would be exposed; the usual advice is to put the file outside of a downloadable location, or to restrict download, but this is tenuous due to differing web environments Composr must on: in trying to increase security, there would be a big likelihood we could incidentally decrease it.

_config.php.bak.*

When you install Composr in a directory that already contains a _config.php file (e.g. overwriting an existing installation), the installer will create a _config.php.bak.* file (ending in the current timestamp). This is to preserve the previous configuration especially in the event it was modified to run different configurations for different git branches or sub-domains.

You should take extra care after installing Composr to immediately move the backup off-site, to delete it, or to merge it into the new _config.php file. Leaving these backup files on the server can be a security risk if someone gets access to them.

Master password

For added security you can remove the:
line from _config.php.

It is best to remove it completely, not comment it out. This prevents master password based logins to tools such as the code editor and upgrader.

It means:

1. If someone found a vulnerability that allowed them to read the hashed master password out of _config.php, they could not use Composr-specific rainbow tables to get the original password and therefore login.
2. Bruce force login attempts cannot work.

Maintenance scripts

To provide additional protection beyond the master password you may want to set IP-based restrictions (or temporary access blocks) to the following scripts:

• rootkit_detection.php
• upgrader.php
• uninstall.php
• data/upgrader2.php
• config_editor.php
• code_editor.php

Follows are sample access rules for an Apache .htaccess file to provide a temporary access block:

For IIS, the web.config file's hiddenSegments can be extended:

You should test these rules are working correctly after applying them.

Denial Of Service prevention

Composr is a sophisticated system and comes with an unavoidable overhead. This increases the opportunity for a malicious individual/group to try and take down a server by flooding it with requests. Composr is designed to prevent against this – it will ban flooders and hackattack repeaters after a point. However, the normal IP banning that Composr uses works via the database, and hence a significant overhead is taken before the ban can be detected. To workaround this, Composr can write IP bans directly into the Apache .htaccess file (obviously, Apache only) – to do this, the .htaccess file must be writable by the web server (typically, 666 permissions, although as explained, a well configured environment won't need that).

Rooted-website prevention

"Rooting" a server involves hacking the web server account and leaving a 'backdoor'. 'Rooting' is either done from some direction that Composr cannot monitor (such as via another web application), or done via a yet unknown vulnerability in Composr.

There is a special script (rootkit_detection.php) that will help detect if Composr PHP files or critical/sensitive database settings are changed, by off-server comparison of data. This is a very advanced script and requires a level of expertise that is outside the scope of this documentation. This method isn't foolproof, but does significantly raise the bar security-wise, reducing the chance that any particular hacker will be able to compromise your website.

HTTP authentication

There is nothing stopping you using HTTP authentication served by your web server on top of the website if you want some extra security.
For example, it is possible to use HTTP Authentication to deny access to the whole of Composr to anyone without a preallocated HTTP-Auth password. For more information on this, see 'related topics'.

However, you should let requests from the web server itself through that without needing to authenticate so that it can read its own URLs (otherwise you could have some problems, such as security errors when editing theme images).

Have you been hacked?

This advice is not specific to Composr, but rather a writeup on how web scripts generally can get hacked. It is not discussing any security holes in Composr, or anything specific to Composr's history.

If you are ever hacked, it is much more likely that you'd be attacked automatically than individually. Hackers write scripts to automatically probe servers for common vulnerability categories, or specific vulnerabilities.

A telltale sign of being hacked is unrecognised code or redirects suddenly showing up on your website.

Often these kinds of hacks run on the server level, going from one site to the next on the server. That is possible if files are set to be world-writable (i.e. another account on the server can access your files for writing if that's the case), which should not be necessary on most modern hosting as suEXEC is now commonplace (PHP can write to its own files without special access). Composr tries to limit file permissions if it detects suEXEC.

This said, it is easy for permissions to get set too liberally when uploading. This can happen if an FTP client is set to mirror local permissions, and local permissions are set to full write – or if the client or server just has default permissions that are too high.

The above is the most likely scenario and is quite common among people running web scripts.

The other less likely possibilities that come to mind would be:

1. some hole in some script on your account. It could be any script you have because this kind of situation often combines with the likely one above: some script on the server somewhere has a hole, then the hacker tunnels through that to infect other things on the server that have too liberal permissions. Or, if you do have correct permissions, some script on your hosting account, affecting other things on your hosting account.
2. something local to your PC. That seems unlikely because it would be a lot of work for a virus to do this, and they'd have more commonplace targets (only a small proportion of people will have their own websites).
3. some server-level vulnerability, e.g. in PHP or Apache, or the FTP server.

To find the true cause of a hack it is a good idea to go through your access logs to find any evidence of malicious-appearing requests that happened around the time of your files being modified (you can easily find the last-modification date for your files).

However, be careful that once you have a cause identified, you do a full cleanup/restore as well as addressing that cause. You don't want to miss something a hacker might have left behind. It is best if you seek expert help for this.

Most users never get hacked, so it's pretty bad luck if you have been (or, you've not updated scripts with important security updates in ).

General considerations

This section contains some general things to bear in mind when considering your security.

URL monikers

The URL monikers feature puts content titles into URLs instead of IDs, and for SEO purposes Composr will enforce those URLs consistently. It does this when generating a page-link for inclusion from content (e.g. from a forum post), or if the numeric-ID URL is accessed (it redirects).

This is a long way of saying that the URL moniker exposes content titles to users who may not have access to that content, which could be a concern in some cases.

If you have sensitive material that might be in a URL moniker, you should either customise that moniker(s), or turn the feature off in the configuration.

See also

• Access control and privileges
• Linux file permissions
• Webhosting for Composr
• Integrating Composr into a network via HTTP authentication
• Integrating Composr into a corporate network via LDAP
• Policing a community site
• Using IP addresses to trace users
• Anti-spam settings
• Problem and feedback reports, and development policies
• robots.txt help
• The Internet Health Report

Feedback

Have a suggestion? Report an issue on the tracker.