Wiki Security – An Ethical Hacker Perspective
Hi, this is Andy Webber. I am an ethical hacker in Oracle Global Product Security
I recently attended WikiSym2008. This conference was a great place to meet up with people interested in collaborative working and related technologies. I gave a presentation to share a recent experience my team and I had while reviewing Wiki extensions and plugins for security vulnerabilities.
In addition to providing a tool for collaboratively creating web content, Wikis are increasingly being used as a framework on which to build small applications. Many Wiki engines already provide limited support for this capability through extensions or plug-ins. These extensions will typically let developers use the Wiki engine in ways that were never envisaged by the original developers. Writing extensions is usually quite straightforward and generally gives a lot of freedom and access to the Wiki engine’s internal state and hence access to everything the Wiki engine has access to.
No matter how much care and attention the Wiki engine developers have put into making the wiki software as robust as they reasonably can, all these efforts may be undermined by any extension that has not been developed with the same level of care. The ease with which Wiki extensions can be developed means that anyone can develop and publish such extensions. Unfortunately, a large proportion of software developers are not properly educated about secure coding practices (See Mary Ann Davidson’s blog entry on this topic).
When we wanted to make more extensive use of extensions on one of our internal wikis, we performed some security reviews. It shouldn’t have been much of a surprise that we found quite a high proportion of the Wiki extensions we examined included potential security vulnerabilities. In most cases, these vulnerabilities were straightforward cross-site scripting or HTML injections. But, we also saw some other interesting possibilities like log injection attacks and inappropriate trust in 3rd party data.
[The work of the Ethical Hacking Team is not just about finding security bugs. The more interesting aspect of my job is to learn from these bugs, characterize them, understand why they happened, and establish methods for rapidly finding similar bugs. The most gratifying aspect of my job is helping development and testing organizations understand the security bugs, how to find them and fix them (and help ensure they don’t come back).]
After we found three or four vulnerabilities in a small set of extensions, we had a good characterization of what generally made these extensions vulnerable and what to look for in the code. We were then able to promptly review a large number (around 100) of extensions and quickly found that more than 20 of them were vulnerable. We reported these issues back to their respective developers (or Wiki engine maintainers) and, as a result, most of them have been fixed or withdrawn.
Even when educational institutions start to pay more attention to the security aspect of software development in their courses, it will be a long time before we can expect developers to consistently produce reasonably secure code. By analogy, I fasten my seat belt whenever I get in a car. Each time I get in a car I don't do a threat assessment and decide that a second to fasten the seatbelt is worth the effort compared to the risk of diving through the windscreen, or of being stopped and fined. I do it as a habit: a habit formed before it was a legal requirement and before I was able to appreciate the damage that flying through the windscreen might do to my future. Reviewing Wiki extensions for security vulnerabilities further highlighted that developers needed to form the habit of using bind variables in SQL queries, HTML/XML encoding output, etc.
Now, after this brief excursion into finding vulnerabilities in community-developed code, it's back to Oracle products for me.
For more information, see http://www.wikisym.org/ws2008/index.php/Security_of_Community_Developed_and_3rd_party_Wiki_Plug-ins
