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!

SektionEins: joined forces of Stefan Esser/Hardened PHP and Mayflower

 

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.

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?

XSS and CSRF made easy

 

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

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

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

We did talk about Web-2.0 Security

On Tuesday our CIO, Johann-Peter Hartmann, gave a Web-seminar about security issues in the Web 2.0 era. We had about 140 participants and some very good questions in the following Q&A Session. We would like to thank you for the response and also we´d like to thank Jürgen from MySQL, our webinar-host.

We uploaded our slides as promised. To download them, click here.

If you missed the Web-Seminar you get a chance to see the recording of it here.
But be aware: It´s in german!!!

For english readers/speakers: Johann held an english security talk some time ago. Find it here

We already heard that some participants found some quite severe security issues right after listening to Johann´s talk. Therefore we strongly recommend to all of you to have a look at it.

Weiterlesen

Web-2.0 Security

Hi Folks,

This is an announcement for a webinar in German. Therefore only written in German. If you are interested in the security topic be sure to see the english webinar, which is stored here.


Web-2.0-Anwendungen absichern

Die verbesserte Einsatztauglichkeit der Web-2.0-Anwendungen wird auf
Kosten von neuen Sicherheitsproblemen erworben. Sowohl die mächtige
Logik im JavaScript als auch der permanente Login auf vielen Sites
bergen Risiken, die anders und gezielt beantwortet werden müssen.
Dieses Webseminar gibt einen Überblick, bewertet die Probleme und
stellt Lösungswege vor.

Wenn Sie Web 2.0- und AJAX-Anwendungen entwickeln, ist dieser Vortrag genau das Richtige für Sie! Hier erfahren Sie:

  • Welche neuen Sicherheitsrisiken es für Webanwendungen gibt
  • Welche Bedeutung XSS hat
  • Ursprünge und Typen von JavaScript-Malware
  • Wege zur Absicherung Ihrer LAMP-Anwendungen für Web 2.0

Weiterlesen

Webmontag Köln: AJAX Security, die Slides

Webmontag war gestern in Köln. Scheee wars. Proppenvoll, mit sicherlich über 100 Leuten. Und mal wieder fest gestellt, wie klein die Welt doch ist, viele bekannte Leute getroffen und vielleicht dem Einen oder Anderen einen Denkanstoß gegeben, wie man seine Applikationen schrittweise verbessern kann. Ein Dank auch an René Bredlau, der mir den Kölner Webmontag schmackhaft gemacht hatte.

Die Slides zum Vortrag finden sich hier zum Download. Im Wesentlichen handelt es sich dabei um die Folien des Vortrags von meinem Kollegen Johann-Peter Hartmann, gehalten u.a. auf der AJAX in Action und der PHP Konferenz im letzten Jahr. In der Tonspur, die ich auf Anfrage gerne im persönlichen Gespräch nachreiche, wurden die beschriebenen Fakten noch um einige aktuelle Beispiele von mir ergänzt.