Redis – Vortrag@Mayflower-München

Am kommenden Donnerstag, den 30.06.2011 findet ein weiterer öffentlicher Vortrag im Mayflower-Büro in München statt (Mannhardtstraße 6, S-Bahn Isartor).
Beginn ist um 18:00 Uhr, Thema des Vortrags ist „Redis„.

In dem Vortrag von Peter Voringer geht es um die Funktionalität und den Einsatzbereich/-möglichkeiten von Redis, sowie die PHP Client Library Rediska.

Die „Donnerstags-Vorträge“ werden sowohl in Würzburg als auch in München gehalten. Bei Interesse einfach das Blog beobachten, um auf dem Laufenden zu bleiben!

Wir freuen uns auf viele Teilnehmer!

Anfahrt zum Mayflowerbüro München

Zur Anmeldung einfach einen Kommentar im Beitrag hinterlassen.

c’t empfiehlt Chorizo für ajax Sicherheitsprüfungen

Die aktuelle Ausgabe der c’t bringt unter dem Titel „Risiko 2.0“ einen Artikel zur Sicherheit von Ajax Anwendungen. Der Autor stellt fest daß den vielfältigen Möglichkeiten, Ajax Funktionen auszuhebeln, eine sehr geringe Zahl von Tools gegenübersteht, die Schwachstellen zu testen und zu reporten. Neben Sprajax wird unser Security Scanner Chorizo! empfohlen.

Wer ihn noch nicht kennt: Chorizo ist ein Online-Scanner der nach XSS, CSRF, SQL Injections, Remote Code Executions und vielen anderen Vulnerabilites fahndet und reported. Keine Softwareinstallation nötig – alles geschieht im Browser.

Wer ihn testen mag: einen vollwertigen Account für eine Domain (Chorizo Free) gibt es hier.

SektionEins launcht offiziell (Deutsch)

 

(Fast) Pünktlich zum von SektionEins verfassten Security Audit von phpBB3, der im dortigen RC6/RC7 mündete, ist nun auch die SektionEins Website in Deutsch und Englisch online gegangen (falls es zu Problemen beim Zugriff kommt, kann es noch an Ihrer DNS-Auflösung liegen). Zur Rekapitulation: die SektionEins GmbH ist unsere Schwesterfirma/Joint Venture, die wir zusammen mit Stefan Esser gegründet haben. SektionEins führt primär Security Audits für Applikationen auf Basis von serverseitigen (PHP, Java, Ruby, Perl, Python, …) und clientseitigen (Flash, JavaScript) Technologien durch. Mehr Informationen gibt es über das Kontaktformular.

 

Wer die Security Captains der SektionEins persönlich zum Gespräch treffen möchte, der kann das auch im neuen Büro tun:

SektionEins GmbH
Eupener Straße 150
50933 Köln

 

Ein herzliches Dankeschön gilt auch Oliver Schwarz von hasematzel.de, der das Layout in feinstem Photoshop, XHTML und CSS umgesetzt hat!

Warmlaufen mit Flash Security

fukamiDie SektionEins GmbH, unser neues Venture zusammen mit Stefan Esser, bekommt Zuwachs. fukami, Speaker zum Beispiel auf dem Chaos Communication Camp 2007 und der FrOSCON, wird ab September unser neuer Mitarbeiter. Zur Erinnerung: die SektionEins GmbH führt in erster Linie Security Audits durch, mit einem Spezialfokus auf PHP, aber auch grundsätzlich alle webbasierten Applikationen (Java, RubyOnRails, Perl, …). Künftig bereichert SektionEins alle Audit-Kunden auch mit einem besonderen Flash Security KnowHow.

 

Sein erstes Warmup hatte fukami auf dem Kölner Webmontag vor zwei Tagen: dort hielt er einen Vortrag über „Flash Security Basics – Register Globals the Flash Way“ und durfte dankenswerterweise die Applikation der Kollegen von TownKings (Blog-Eintrag von TownKings zum Webmontag) dazu benutzen. :-) Erfreulicherweise gibt es von fukamis Vortrag einen Videomitschnitt (auf das Bild klicken, dann gelangt Ihr zum Video):

 

 

Noch Fragen?

Scriptgenerierung zur Einbindung nach extern nicht immer sinnvoll

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?

Update: Analyse des HTML Sourcecodes der Second Order Attacke

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:

 

fukami.

shoppero.com gleich erstes Opfer von Second Order XSS Attacks

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.

Twitter-Klone, Web2.0 Apps & Co: sicher genug?

Nachdem nun auch im deutschsprachigen Raum der eine oder andere twitter Klon aus dem Boden gestampft wurde, sollte man die Diskussion um die ganzen Copycats der so genannten Web2.0 Communities/Portale/Applikation auch noch einmal aus einem anderen Blickwinkel betrachten: der Sicherheit.

 

Wenn Dinge „schnell, schnell“ aus dem Boden gestampft werden, ist die Gefahr immer hoch, dass der Sicherheitsaspekt darunter leiden mag. Sicherheit hat ihren Preis und im Übrigen auch dank des Internets und seiner Vielfalt auch eine immer höhere Komplextität. Von Dingen wie UTF-7 XSS Bugs mag ich gar nicht reden, aber ein Mindestmaß an Filterung/Validierung, um zumindest die gröbsten Schnitzer à la

„><script>alert(document.cookie);</script><a href=“

zu vermeiden, sollte schon drin sein. Speziell, wenn es sich um die so genannten „Web2.0 Communities“ handelt, bei denen eine Heerschar an Nutzern ihre Profile pflegt.

 

Das Problem ist doch ganz einfach folgendes:
Weiterlesen

Johann-Peter Hartmann spricht auf heise Security Konferenz

Johann-Peter Hartmann, technischer Leiter der Mayflower GmbH, spricht im Rahmen der Sicherheitskonferenzen des heise-Verlages.
Im Rahmen immer komplexerer Webanwendungen werden auch die Möglichkeiten für Angriffe immer zahlreicher. Mit neuen Technologien, wie beispielsweise AJAX, und der neuen Mitmachkultur im Web2.0 entstehen Sicherheitsprobleme für Anbieter und Nutzer, die sich aktuell erst erahnen lassen.

Johann-Peter Hartmann wird in seinem Vortrag die Themen XSS und Sicherheit bei Verwendung von AJAX-Applikationen intensiv erläutern und Lösungswege aufzeigen. Des Weiteren wird das Thema User-Generated-Content aus Security-Sicht erörtert. Freuen Sie sich auf interessante Vorträge in:

24. April 2007, Düsseldorf, Hilton Hotel
03. Mai 2007, Frankfurt, Radisson SAS Hotel
09. Mai 2007, Hamburg, Dorint Sofitel
15. Mai 2007, München, Dorint Novotel

Melden Sie sich hier an

Chorizo posters

Somewhere around this time last year we did go public with our security scanner Chorizo!.

One year later, Chorizo! is well established in the world of web development and a useful tool for a lot of developers, especially when you deal with PHP applications.
Doing a lot of marketing work in the last year, one special activity (and one of my favourites) was until now only available for readers of the German PHP-Magazin. But we think that it is time to change that…

So we proudly present the Chorizo!-adapt a movie poster-Series

Ladies and Gentlemen, here’s the Gallery:

Our first poster does have some elements from a movie dealing with virtual reality and a man-machine conflict.

Weiterlesen