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.
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:
- Done a new security review of ocPortal, focusing on XSS, but also re-considering some other areas based on OWASP guidance
- Went through every data field, screen, block, and Comcode tag, to manually check for XSS holes
- 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)
- Went through every data field, screen, block, and Comcode tag, ensuring the custom PHP version doesn't throw up any errors
- Changed a number of APIs in v10 to explicitly force us to think about how we want to do data escaping when using them
- Tested our HTML-blacklist-filter with some heavy-duty XSS tests
- Created new unit tests specifically to test against particular kinds of Comcode attack
- 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)
- 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)
- Tuned and carefully documented our input filtering strategy in our Security tutorial
- 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.