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.

XSS vulnerability patch for ocPortal

XSS vulnerability patch for ocPortal In February 2015 we had a number of ocPortal XSS vulnerabilities reported to us.

XSS vulnerabilities are a class of security bugs that are basically JavaScript code injection attacks. A malicious hacker submits something with embedded JavaScript code, and then when a user goes and views what was submitted, the JavaScript code runs on their machine. This code can then potentially hijack their browser session, for example getting them to unintentionally delete stuff on the site.

It's a very common indirect form of attack.

We have just released a new patch release that resolves all the issues. We recommend all v9 users upgrade if possible (otherwise, read on).

Additionally, a sources_custom/input_filter.php is attached to this news post. This file should work well on any ocPortal version going back years, and is supplied for those users that do not want to upgrade yet, or are on heavily modified custom versions. The file works by placing a high-level filter in front of ocPortal requests for users without the "Use dangerous Comcode" privilege. To test the filter is working, as a non-admin user try posting <script> in a forum post (just as plain text, not within an HTML tag) – you should see it changes to <span> – this is our redundant protection in action, even stuff not routinely shown as HTML will get filtered just in case it ever accidentally is.
We have already put this in place for customers on our security updates service. If you are a customer and see a sources_custom/input_filter.php file this almost certainly means that we have already patched you, as we're not aware of any ocPortal addon/customisation ever creating an override to this file.
» Download: input_filter.php (5 Kb, 248 downloads so far)

We have a very strong reputation for security, so having security holes reported to us is something we take very seriously, and do our best to learn from. A few years back we went to great lengths to avoid such issues by developing an XSS-security scanner for our custom development version of PHP – but unfortunately there was a flaw in our scanning technology, so certain cases of issue were missed. Having this powerful tool made us over-confident, so we are now more than compensating for that by adding multiple new redundant layers of security.

We have now done the following to significantly reduce the chance of more XSS vulnerabilities in the future:
  1. Done a new security review of ocPortal, focusing on XSS, but also re-considering some other areas based on OWASP guidance
  2. Went through every data field, screen, block, and Comcode tag, to manually check for XSS holes
  3. Fixed our custom PHP version to correctly scan for issues through the PHP output buffering feature (which is what caused it to miss issues before)
  4. Went through every data field, screen, block, and Comcode tag, ensuring the custom PHP version doesn't throw up any errors
  5. Changed a number of APIs in v10 to explicitly force us to think about how we want to do data escaping when using them
  6. Tested our HTML-blacklist-filter with some heavy-duty XSS tests
  7. Created new unit tests specifically to test against particular kinds of Comcode attack
  8. Created new unit tests specifically to test against particular kinds of filesystem attack (there are no attacks for ocPortal in this set of vulnerabilities, but we took the opportunity to add extra protection here too)
  9. Created new unit tests specifically to ensure that our Tempcode engine continues to work properly in coordination with our custom PHP version (checking particular unsafe situations really do continue to flag errors)
  10. Added a new privilege ("Avoid broad input filtering security layer") that adds additional filtering, for an additional layer of safety; by default all non-admins will now have this run, as non-admins typically do not need to post anything looking like JavaScript code in any situation. This is a filter, not a block – anything potentially dangerous is transformed, rather than turned into a suspected-hack-attempt
  11. Tuned and carefully documented our input filtering strategy in our Security tutorial
  12. Manual XSS checks are now a part of our documented release process for new major releases

Finally we would like to thank Dennis Veninga from Forus-P BV for reporting these issues to us, and giving us the time to make a solid response. We respect and appreciate the help of reputable security professionals such as Dennis.

Update: our input_filter.php patch has been updated, as it was causing the word 'on' to not display correctly in non-Comcode contexts, if posted by non-staff.

View all


There have been no trackbacks yet