Hanno's blog

I want to give some thoughts about some more advanced XSS-issues based on two vulnerability announcements I recently made.

First is backend XSS. I think this hasn't been adressed very much, most probably all CMS have this issue. If you have a CMS-System (a blog is also a CMS system in this case) with multiple users, there are various ways where users can XSS each other. The most obvious one is that it's common practice that a CMS gives you some way to publish raw html content.

Assuming you have a blog where multiple users are allowed to write articles. Alice writes an article, Eve doesn't like the content of that article. Eve can now write another article with some JavaScript adjusted to steal Alice's cookie. As soon as Alice is logged in and watches the frontpage with Eve's article, her cookie get's stolen, Eve can hijack her account and manipulate her articles.

Solution is not that simple. To prevent the XSS, you'd have to make sure that there's absolutely no way to put raw html code on the page. Serendipity for example has a plugin called trustxss which should do exactly that, though there are many ways to circumvent that (at least all I found should be fixed in 1.3-beta1, see advisory here: CVE-2008-0124). All fields like username, user-information etc. need to be escaped and it should be the default that users aren't allowed to post html. If a superuser enables html-posting for another user, he should be warned about the security implications.

A quite different way would be separating front- and backend on different domains. I don't know of any popular CMS currently doing that, but it would prevent a lot of vulnerabilities: The website content is, e.g., located on www.mydomain.com, while the backend is on edit.mydomain.com. It would add complexity to the application setup, especially on shared hosting environments.


Second issue is XSS/CSRF in the installer. I'm not really sure how I should classify these, as an open installer most probably has more security implications than just XSS. I recently discovered an XSS in the installer of moodle (CVE-2008-0123) which made me think about this.

I thought of a (real) scenario where I was sitting in a room with a group, discussing that we need a webpage, we would take Domain somedomain.de and install some webapp (in this case MediaWiki, but there I found no such issues) there. I suddenly started implementing that with my laptop. Other people in the room hearing the discussion could send me links to trigger some kind of XSS/CSRF there. This probably isn't a very likely scenario, but still, I'd suggest to prevent XSS/CSRF also in the installer of web applications.

I recently stepped upon some XSS issues in Serendipity.

The first is in the remoterss-plugin, which can be used to display the content of an RSS feed in the sidebar of a blog. It didn't escape links, so JavaScript-Code could be injected by malicious RSS feeds. This plugin is shipped with the base version of S9Y. They've released 1.2.1 this weekend which has the fix.
If you're using the remoterss plugin, you should upgrade to 1.2.1 as soon as possible. This issue is named CVE-2007-6205.

The other one is in the external mycalendar-plugin. It also allows unescaped content inside links. This wouldn't be a real issue, as this form should only be accessible by the blog administrator. But the form had no CSRF (Cross-Site-Request-Forgery) protection, so an attacker could trigger this form and thus inject javascript on the blog-page. This has been fixed within version 0.13 of the plugin, so if you're using it, please upgrade. CVE-2007-6390 now assigned.

Beside I'd like to note that I got fast replies to my reports and the s9y devs fixed them quite quickly. Thanks for that!

I recently wrote that I'm sometimes a bit unhappy how security issues are handled in free software project.

Now, to have some contrast, today I'll talk about an example how to do it right. Serendipity, the software I'm using to host this blog, had an SQL injection vulnerability. On the same day, they announced it and provide updated packages. The finder of the vulnerability is also mentioned. Now, it is only able to get password-hashes, many other projects probably would've treated this vulnerability as »low-impact« or something like that.
But beside that, they also provide some tipps how to check if the vulnerability has already been exploitet and suggest to change user passwords.

A while back, there was another vulnerability reported in serendipity. The authors said they don't think that it's really a vulnerability and it probably can't be used for anything evil. But anyway, an update was released and announced just to be sure.

Now, that's good security-work. The fact that serendipity has very few vulnerabilities at all already is very good. The fact they treat the few ones proper is even better. Some other projects should have a look at that.