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.

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.

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

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

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

Code Inclusions on a Silver Plate

Looking for code inclusions?
The versatile google cluster has a solution for this, like for many other tasks.

This search


lang:php \secho\([^)]*_REQUEST[^)]*\);

lets You find various places where some variable from the superglobal $_REQUEST is printed with echo. By the same means, you can easily find places where such a variable is directly included in an SQL query, for instance with

lang:php \smysql_query\([^)]*_REQUEST[^)]*\);

.

This alone yields 50 results for each query, but it may be varied with printf() instead of echo() or just leaving out the () with echo. Further, there are some more superglobals, most important $_GET and $_POST.

If that’s not enough, there are some more code search engines, like Krugle or Koders. Even though the llatter does not allow queries like the above, even there inclusions can be found between examples of how to prevent such security flaws.

Looking at the sites of the search hits yields quite a bunch of well-known projects/sites, so this is not just gray theory.

Buy one XSS, get a CSRF for free

Cross Site Request Forging (see http://en.wikipedia.org/wiki/Cross-site_request_forgery for more information) has been around for a while now. It misuses the trust of a web application that every request sent by the browser is wanted by its user.
For example, if you know that i am logged in to our blog admin backend most of the time, and you know its url and software, you could trick me into visiting a special prepared url. That url contains a small javascript that automatically submits a fake form to our admin backend, and short time later everybody is surprised to read on our blog that Mayflower will leave the domain of web application development and open a butcher’s shop instead.

Since the authors of our blog software are smart people, they implemented a CSRF protection. And not only them, even we not as smart PHProjekt developers implemented one.
There are three popular ways to protect your software against CSRF:
Weiterlesen