In 2008, a rather interesting new kind of security problem within web applications was found called Clickjacking. The idea is rather simple but genious: A webpage from the attacked web application is loaded into an iframe (a way to display a webpage within another webpage), but so small that the user cannot see it. Via javascript, this iframe is always placed below the mouse cursor and a button is focused in the iframe. When the user clicks anywhere on an attackers page, it clicks the button in his webapp causing some action the user didn't want to do.
What makes this vulnerability especially interesting is that it is a vulnerability within protocols and that it was pretty that there would be no easy fix without any changes to existing technology. A possible attempt to circumvent this would be a javascript frame killer code within every web application, but that's far away from being a nice solution (as it makes it neccessary to have javascript code around even if your webapp does not use any javascript at all).
Now, Microsoft suggested a new http header X-FRAME-OPTIONS that can be set to DENY or SAMEORIGIN. DENY means that the webpage sending that header may not be displayed in a frame or iframe at all. SAMEORIGIN means that it may only be referenced from webpages on the same domain name (sidenote: I tend to not like Microsoft and their behaviour on standards and security very much, but in this case there's no reason for that. Although it's not a standard – yet? - this proposal is completely sane and makes sense).
Just recently, Firefox added support, all major other browser already did that before (Opera, Chrome), so we finally have a solution to protect against clickjacking (konqueror does not support it yet and I found no plans for it, which may be a sign for the sad state of konqueror development regarding security features - they're also the only browser not supporting SNI). It's now up to web application developers to use that header. For most of them – if they're not using frames at all - it's probably quite easy, as they can just set the header to DENY all the time. If an app uses frames, it requires a bit more thoughts where to set DENY and where to use SAMEORIGIN.
It would also be nice to have some "official" IETF or W3C standard for it, but as all major browsers agree on that, it's okay to start using it now.
But the main reason I wrote this long introduction: I've set up a little test page where you can check if your browser supports the new header. If it doesn't, you should look for an update.

In the last weeks, I made a study research project at the EISS at the University of Karlsruhe. The subject was »Session Cookies and SSL«, investigating the problems that arise when trying to secure a web application with HTTPS and using session cookies.

I already wrote about this in the past, presenting vulnerabilities in various web applications.

One of the notable results is probably that ebay has just no measurements against those issues at all, so it's pretty trivial to hijack a session (and use that to do bids and even change the address of the hijacked account).

Download »Session Cookies and SSL« (PDF, 317 KB)

Today heise security brought a news that a growing number of old wordpress installations get's misused by spammers to improve their pagerank. I've more or less waited for something like that, because it's quite obvious: If you have an automated mechanism to use security holes in a popular web application, you can search for them with a search engine (google, the mighty hacktool) and usually it's quite trivial to detect both application and version.

This isn't a wordpress-thing only, this can happen to pretty much every widespread web application. Wordpress had a lot of security issues recently and is very widespread, so it's an obvious choice. But other incidents like this will follow and future ones probably will affect more different web applications.

The conclusion is quite simple: If you're installing a web application yourself, you are responsible for it! You need to look for security updates and you need to install them, else you might be responsible for spammers actions. And there's no »nobody is interested in my little blog«-excuse, as these are not attacks against an individual page, but mass attacks.

For administrators, I wrote a little tool a while back, where I had such incidents in mind: freewvs, it checks locally on the filesystem for web applications and knows about vulnerabilities, so it'll tell you which web applications need updates. It already detects a whole bunch of apps, while more is always better and if you'd like to help, I'd gladly accept patches for more applications (the format is quite simple).

With it, server administrators can check the webroots of thier users and nag them if they have outdated cruft laying around.

I got some spam in the comment fields of my blog that raised my interest.

Some sample how they looked like:
http://www.unicef.org/voy/search/search.php?q=some+advertising%3Cscript%3Eparent%2elocation%2ereplace%28%22http%3A%2F%2Fgoogle%2ede22%29%3C%2Fscript%3E

I've replaced the forwarding URL and the advertising words (cause I don't want to raise interest on spammers pages). I got several similar spam comments the following days all with the same scheme. Using a Cross Site Scripting vulnerability, mostly on pages that might raise trust to forward to a medical selling page.

This is probably a good reason why XSS should be fixed, no matter what attack vectors there are. It can always be used by spammers to use your pages fame / authority to advertise their services. Same goes for redirectors or frame injections. Some where already reported at some public place (for the above see here). I've re-reported them all, but got just one reply by a webmaster who fixed it. True reality on the internet today, even webmasters of famous public organizations don't seem to care about internet security.

For the record, the others:
http://adventisthealth.org/utilities/search.asp?Yider=<script>alert(1)</script>
http://www.loc.gov/rr/ElectronicResources/search.php?search_term=<script>alert(1)</script>

And thanks to iconfactory, they fixed their XSS.

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.

Recently I had a discussion with someone about the security of various linux distributions where he claimed Debian stable to be very secure and that they use old versions where they backport all occurances of security issues. This is a common assumption, too bad that it's wrong.
I want to document this to demonstrate the dangerousness of opinions like »stay with the old software«, »never touch a running system« and alike that are not limited but often found in the Debian community.

I had a look at the security policy on a package recently very popular for it's vast number of issues, namely php. Their last php-update on php5 was in july. They have a heavily patched version of php 5.2.0 and according to their changelog the last thing they patched was CVE-2007-1864.

Now that probably means that CVE-2007-3996, CVE-2007-3378, CVE-2007-3997, CVE-2007-4652, CVE-2007-4658, CVE-2007-4659, CVE-2007-4670, CVE-2007-4657, CVE-2007-4662, CVE-2007-3998, CVE-2007-5898, CVE-2007-5899, CVE-2007-5900 are unfixed. Oh, and before you ask: This list certainly is incomplete, it's just what I found without much hassle.

Not only looking at php5, php4 is still officially distributed by many vendors, some hosters still use it. You can't really blame them, as php.net announced it to be supported until 2007-12-31. But that's theory, in fact, nobody looks if the various recent issues also apply to php 4, most recent advisories don't mention it. Fact is, at least CVE-2007-3378, CVE-2007-3997, CVE-2007-4657, CVE-2007-3998 also apply to php 4 and are unfixed in their latest release 4.4.7 (not neccessary to mention that they're not fixed in the debian stable php4 package).

If someone prefers to stay with old software, it's up to them. But be serious. It's probably a hell-job to get all the recent security issues in an app like php backported to some ancient version. A quick check showed me that debian isn't able to do that. If you can't do that, don't claim it's in any way »supported«. Because doing that put's other people in dangerous situations.

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!

A big problem with web security in the past was that it was impossible to have https-hosts with more than one certificate per IP. This is due to the protocol design of https, which needs to establish an ssl-connection with the certificate before the hostname is transferred.

There is a solution though, called Server Name Indication (SNI) and part of TLS. Strange enough, client compatibility isn't that much of a problem. Firefox, Opera and IE already support it in their current versions, konqueror will with kde4, I've no information when it'll hit safari. Oh, and I haven't testet w3m, lynx, links and wget yet, but if you want, feel free to add your experiences to the comments :-)

The problem was that until some weeks ago, openssl didn't support SNI, apachen mod_ssl didn't, lighttpd didn't. Only GnuTLS, but mod_gnutls is considered unstable by it's authors. With OpenSSL 0.9.8f, TLS Extensions and with them SNI landet in openssl, apache still needs patches.

We've now implemented SNI on schokokeks.org, which you can test:
https://www.schokokeks.org/
https://www.hboeck.de/
https://www.fabian-fingerle.de/

If your browser supports SNI, you should see different certificates, all on the same IP. All certs are cacert-signed, they also have a Wiki page from the VhostTaskForce for SNI and alternative solutions.

I thought I'd give you some more (all have been informed months ago):

http://thepiratebay.org/search/"><script>alert(1)</script>
http://www.gruene.de/cms/default/dok/144/144640.dokumentsuche.htm?execute=1&suche_voll_starten=1&volltext_suchbegriff="><script>alert(1)</script>
http://www.terions.de/index_whois.php?ddomain="><script>alert(1)</script>
http://www.eselfilme.com/newsletter/newsletter.php?action=sign&email="><script>alert(1)</script>
http://www.region-stuttgart.de/sixcms/rs_suche/?_suche="><script>alert(1)</script>
http://reports.internic.net/cgi/whois?whois_nic="><script>alert(1)</script>&type=domain