ocPortal Tutorial: Security
- perform the practices of producing secure and robust code
- scan and penalise security hot-spots (such as database queries)
- design the ocPortal architecture to abstract away common security hot-spots wherever possible
- have designed ocPortal to actively detect and log possible security issues via defining and enforcing tight interfaces into ocPortal, and consistency rules
If you find a flaw in ocPortal's security please submit a security support ticket to us so that we may have time to fix the problem before hackers get a chance to exploit it on innocent users.
Table of contents
- ocPortal Tutorial: Security
Security logsocPortal defines a large number of 'hack attack' situation, and in case of any of these situations occurring, stops execution, sends out an e-mail detailing the attack, and logs 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).
A security alert for a real hack-attempt
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 ocPortal 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 an ocPortal site, so was logged.
Alert typesAt the time of writing, 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 ocPortal 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 ocPortal, where the iframe URL was given by the main page URL. By doing this, social engineering, or referrer faking, might be achievable.
- 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.
- 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).
- SCRIPT_TAG_HACK = The user tried to introduce a script tag. This would be likely to be a hack attempt if it wasn't for the fact that by default, ordinary members cannot submit any HTML at all; it is therefore likely that a privileged user has out-stepped the norm, or a privileged member is not to be trusted.
- SCRIPT_URL_HACK = This is highly likely to be a hack attempt, as a user explicitly specified a URL which was code and not a real URL
- 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 info.php, then it is very likely to be a hack attempt.
- 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
- ADMINCENTRE_ACCESS_DENIED = The user tried to access a secured zone without permission. This is unlikely to be a serious attack, as the user may just have been following a misplaced URL, or messing about. This error is not enabled by default on ocPortal because we found that googleads triggered it massively!
- 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.
In this config option that embeds an "E-mail the staff" link, the address is obfuscated so most bots won't understand it
Failed login attempts
File-type white-listIn the security configuration, ocPortal defines a list of file types that may be uploaded to the website, via the various upload mechanisms that exist in ocPortal, such as that of the download module and the attachment system. By default, this white-list is:
It is important to understand that there are two sides to the security of file uploads:
- 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 it's original extension (which the attachment system does not do)
The client-side HTML situation is unfortunate, as in theory, ocPortal should be able to control how a downloaded file is treated by something called a 'mime-type': if ocPortal defines a mime-type for an unknown file-type, or dangerous file-type, as that of a plain-download, it should never do anything but download-directly. However, Microsoft Internet Explorer does not comply with the mime-format and will execute based on file type even when a mime-type is explicitly given: if you do not like this situation, I suggest you direct your disdain toward Microsoft as you consider appropriate.
Techniques for increasing security furtherThis section details some techniques to increase the security of your site. Most of these techniques are either advanced, or unattractive for most ocPortal users, which is why they are not included in the default ocPortal configuration.
Securing the member joining process
To force members to be vetted, you need to enable the 'Require member validation' option, as shown in the screen-shot.
It is possible to use HTTP-Authentication to deny access to the whole of ocPortal to anyone without a pre-allocated HTTP-Auth password. For more information on this, see 'related topics'.
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.
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 whilst 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 e-commerce site, SSL is essential, as the stakes are high enough for criminal interest to be stimulated.
Note that a page viewed under HTTPS will use HTTPS for all images and other embedded files. The banner will be disabled to make sure this requirement is enforced. The reason for this is that users should not get mixed environment messages that warn them about potential security problems. Template makers and coders should be careful to use the proper ocPortal mechanisms for referencing resources.
Securing a zone so that an explicitly logged-in session is required
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.
The Admin Zone is configured to behave like this by-default, as it is extremely critical, but you may choose to also secure the 'site' zone in the similar fashion.
ocPortal does provide a secondary defence against this scenario, by checking referrer's, but we do not consider referrer's secure based on two facts:
- this seems an area where there may be web browser vulnerabilities, or unfortunate situations, that lead to inaccuracy of this data
- user firewalls, ironically, often block this data (for privacy reasons), preventing us from using it to add to security
Restricting login so it can only be done for IP addresses that are confirmed via e-mail
This technique reduces the chance of someone gaining unauthorised access to an account, but is also very annoying for users who do not have a stable IP address.
Optimum server environmentIt is an unfortunate fact that shared web hosting 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.
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.
The main issue with shared hosting, is that, unless either:
- the environment for hosting accounts is restricted to being PHP-only, with safe-mode (which limits PHP and hence ocPortal in a negative way) or open_base_dir (which we advise) enabled
- or, the server is set to run web scripts on different hosting accounts using the account holder user-names (this is very rare)
If you are fortunate enough to be in situation 2, but not fortunate enough to be in situation 1 (fortunate, depending on your needs of course), then ocPortal needs special configuration to make use of it. You need to make it so that no files are "world writeable" (which is the case unless you have suddenly switched to this environment) and so that info.php is not world writeable or world readable (to protect your database password). ocPortal is clever enough to detect your situation, and hence will not chmod any PHP-created-files to a world-writeable 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 writeable is the only way to achieve this in a hosting environment).
info.phpBy default, the info.php is left "world-writeable" by the installer. This allows the configuration editor to work with it, and allowed the file to be initially filled, but does represent a potential security risk on a shared server.
Whilst many files are world writeable, 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 info.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 ocPortal must on: in trying to increase security, there would be a big likelihood we could incidentally decrease it.
Denial Of Service preventionocPortal is a sophisticated system and comes with an unavoidable overhead. This increases the opportunity for a maliceous individual/group to try and take down a server by flooding it with requests. ocPortal is designed to prevent against this - it will ban flooders and hackattack repeaters after a point. However, the normal IP banning that ocPortal uses works via the database, and hence a significant overhead is taken before the ban can be detected. To workaround this, ocPortal can write IP bans directly into the Apache .htaccess file (obviously, Apache only) - to do this, the .htaccess file must be writeable 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 ocPortal cannot monitor (such as via another web application), or done via a yet unknown vulnerability in ocPortal.
There is a special script (rootkit_detection.php) that will help detect if ocPortal 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.
- Secure Socket Layer - encryption over Internet connections so as to avoid interception of information
- White lists show what things are allowed, as opposed to what are not (black lists); they are theoretically better (but not always practical), as they guard against changes that could add insecurity (e.g. if a file type suddenly starts supporting dangerous macros and wasn't black-listed, it would spell trouble) or oversights
- Muddled up, made difficult to understand: but still correct
- A special code that identifies a file type; this allows web systems to make it explicit how files should be treated (e.g. as an attachment, as a 'open in' link, or as a pure file download), rather than being bound by the file extension (which can't really be changed)