HTML Logo by World Wide Web Consortium ( Click to learn more about our commitment to accessibility and standards.

Moving forward with Composr

ocPortal has been relaunched as Composr CMS. ocPortal 9 is superseded by Composr 10.

Head over to for our new site, and to our migration roadmap. Existing ocPortal member accounts have been mirrored.

Script security

There are no pages beneath this page

Submitted by Chris Graham
This advice is not specific to ocPortal, but rather a writeup on how web scripts generally can get hacked. It is not discussing any security holes in ocPortal, or anything specific to ocPortal'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 su-exec is now commonplace (PHP can write to its own files without special access). ocPortal tries to limit file permissions if it detects su-exec.

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 amongst 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 ;)).
CEDI change-log Post