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
- develop on our own version of PHP that can detect XSS security holes
If you find a flaw in ocPortal'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.
Table of contents
ocPortal Tutorial: Security
- Security logs
- Alert types
- Input filtering
- Anti-spam measures
- Failed logins
- File-type white-list
- Protect your domain name
- Protect your session security
- Client-side measures
- Techniques for increasing security further
- Master password
- Denial Of Service prevention
- Rooted-website prevention
- HTTP authentication
- The "TRY_TO_DOWNLOAD_SCRIPT" error in detail
- See also
Security logsocPortal 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).
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 – 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)
- 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 / 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 (ocPortal 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 info.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
- 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 Google ads 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
- BRUTEFORCE_LOGIN_HACK, Someone gave incorrect login details 30 times over a 15 minute period (brute-force attack)
Input filteringWe have 4 privileges relating to input filtering:
- Avoid broad input filtering security layer
- Use dangerous Comcode
- Use potentially-troublesome Comcode
- Subject to a more liberal HTML filter
"Avoid broad input filtering security layer" turns on filtering that may result in some data loss, but gives 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
"Use dangerous Comcode" should only be granted to trusted staff. Users with this permission can effectively exert full control over the site, via placement of advanced blocks.
"Use potentially-troublesome Comcode" is fairly safe to give. Without it we will try and filter out certain stuff that may be annoying (such as particular interactive interfaces), but not an actual security risk.
"Subject to a more liberal HTML filter" is fairly safe to give, but for high security sites best avoided. If granted, users can basically use whatever HTML they want, if we don't see that HTML as a security risk (insecure HTML will be cleaned up automatically). Without this, there's a particular white-list of allowed HTML (not specifically tags, but tag patterns), corresponding to HTML created directly within the WYSIWYG editor. Users may get confused why content they paste into the WYSIWYG editor comes out a mess, as pasted content is unlikely to use only white-listed HTML segments.
We also have of internal checks that always run, many related to "Alert types" (see above), including:
a) Constraining of input parameters for filename-only scenarios (filter_naughty, PATH_HACK)
b) Constraining of input parameters for codename-only scenarios (filter_naughty_harsh, EVAL_HACK)
c) 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)
e) Referrer checks, to make sure POST requests aren't being made from non-trusted sites (i.e. CSRF-prevention, EVIL_POSTED_FORM_HACK)
f) 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)
g) 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.
h) Obvious spamming (some common spam patterns are so obvious, we can just route them direct to LAME_SPAM_HACK)
i) Click-jacking frame protection, using standard X-Frame-Options functionality
j) 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.
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
robots.txtTo 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-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 roughly (this is not kept up-to-date):
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 its 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. Update: Microsoft saw the light and IE8 has improved things. ocPortal will set the switch IE8 has introduced to disable this functionality.
Protect your domain nameIt 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 securityWe 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 ocPortal – 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:
0000708: Increase complexity of session IDs - ocPortal feature tracker
ReferrersAll users with privileged access should have referrers enabled in their web browser. Without this, ocPortal 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 OcCLE (Admin Zone > Tools > OcCLE) and type:
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 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'.
SSLIf 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. Before you may select which pages to use, you must enable the "HTTPS support" option from the "General" subsection of the "Security/Usergroup configuration" section of the configuration.
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 ocPortal as follows:
- Go to the Admin Zone, Setup section, Configuration icon, Security options, 'General' box, and turn on 'HTTPS Support'.
- Go to the Admin Zone, Security section, SSL/TLS (HTTPS) configuration icon, and tick (check) the boxes for the following pages… :join, :login, :purchase, :shopping, site:members, site:points. (These are the pages that purchases or passwords happen on – but you can enable for other pages too if you like)
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.
Please be aware ocPortal can not function with a base URL that is HTTPS, or with server-level restrictions enforcing it's directories to work via HTTPS. HTTPS must be specified by specifying within ocPortal what pages are to use it (ocPortal-level), not on a web-server-level.
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 referrers, but we do not consider referrers 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
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, 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.
Master passwordFor added security you can remove the:
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.
- If someone found a vulnerability that allowed them to read the hashed master password out of info.php, they could not use ocPortal-specific rainbow tables to get the original password and therefore login.
- Bruce force login attempts cannot work.
Denial Of Service preventionocPortal 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. 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.
HTTP authenticationThere is nothing stopping you using HTTP authentication served by your web server on top of the website if you want some extra security. However, you should let requests from the web server itself through that without needing to authenticate so that it can read it's own URLs (otherwise you could have some problems, such as security errors when editing theme images).
The "TRY_TO_DOWNLOAD_SCRIPT" error in detailThe 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 ocPortal 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 â€" ocPortal never trusts absolute URLs.
This error could also be caused by some server configuration issue too. For example:
- 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".
- 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 ocPortal would not receive the file it expected to be checking.
- 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)