als PDF
Werbung
ix.1107.x.1-16 27.09.2007 12:13 Uhr Seite I sponsored by: Ein Verlagsbeihefter der Heise Zeitschriften Verlag GmbH & Co. KG IT-Security extra IT-Security Angriffsmöglichkeiten auf Webapplikationen und Abwehrtechniken Schwerpunkt: Tools zur WebsiteAbsicherung Angriffsmöglichkeiten auf Webapplikationen und Abwehrtechniken Tückische Eingaben Tückische Eingaben Seite I Die meisten heute verfügbaren Sicherheitsprodukte sind nicht in der Lage, die Anwendungen auf einem Webserver adäquat zu schützen. Hinzu kommt, dass es kaum Webanwendungen gibt, die fehlerfrei sind. Zum Schutz vor Übergriffen sollten Anwender die gängigsten Angriffstechniken verstehen und einen Applikations-Scanner sowie eine mit speziellen Funktionen ausgestattete Firewall installieren. Firewalls für Webanwendungen Die Türsteher Seite VI Einbruchssimulation mit Proxy und Plug-ins Gekonnte Handarbeit Seite XI Identitätsmanagement in Zeiten von Webservices und Web 2.0 Meine Identität gehört mir Seite XIV Vorschau Storage Schwerpunkt: Disk-Systeme – Technik und Produkte Seite XVI Veranstaltungen 22. – 24. Oktober, London RSA Europe www.rsaconference.com/2007/Europe 23. – 26. Oktober, München Systems www.systems.de 3. – 4. November, Köln European Software Conference (ESWC) www.euroconference.org 19. – 21. November, Düsseldorf iX-Konferenz: Bessere Software! www.ix-konferenz.de nalysten und Szenebeobachter sind sich einig: Die meisten Hacker-Angriffe im Web erfolgen heutzutage auf Applikationsebene. Dabei geht es nicht um einfache Websites mit statischem Inhalt, sondern um dynamische Webapplikationen. Webauftritte mit einfachen HTML-Seiten ohne Formulare und Benutzerabfragen sind für einen Angreifer nur wenig interessant. Erst wenn Benutzereingaben verarbeitet werden, wie es bei Suchfunktionen, Onlinekatalogen, Bestellsystemen und so weiter der Fall ist, wird es für Hacker spannend. Besonders attraktiv sind Portale, die für Kunden oder Partnerfirmen konzipiert sind und mit internen IT-Systemen interagieren. Werden solche Systeme über einen Webbrowser bedient, kann man in den meisten Fällen davon ausgehen, dass sie Fehler enthalten, die einem Angreifer Tür und Tor öffnen können. Ob es sich im Einzelfall um eine ASP- oder PHP-basierte Anwendung, eine Webappli- A kation auf der Grundlage von Applikationsservern beziehungsweise Frameworks wie IBM Websphere, BEA Weblogic oder um eine SAP-Web-Application-Server-Anwendung handelt, macht kaum einen Unterschied. Denn fehlerfreie Software ist in diesem Umfeld nicht zu erwarten, und die Fehler sind meist gleichbedeutend mit Sicherheitslücken. Der zweite zu beachtende Ausgangspunkt ist, dass bestehende Firewalls in der Praxis nicht vor Angriffen auf Webapplikationen schützen können, selbst wenn deren Hersteller mit Funktionen für den Schutz auf „Anwendungsebene“ werben. Eine der ältesten und auch trivialsten Angriffsmethoden beruht schlicht und einfach auf dem Zugriff auf URLs, die eigentlich nicht erreichbar sein sollten und die innerhalb der Anwendung auch nicht verlinkt sind. In der Praxis kommt es immer wieder vor, dass eine ASP-Datei in einer älteren Ver- I ix.1107.x.1-16 27.09.2007 12:13 Uhr Seite II IT-Security sion mit der Endung .old oder .bak auf dem Server liegen bleibt. Wird beispielsweise eine ASP-Datei mit Namen feedback. asp als www.ix.de/feedback.asp aufgerufen, könnte ein Angreifer durch Ausprobieren eine URL wie www.ix.de/feedback. asp.old finden. Da die Endung nicht mehr .asp sondern .old lautet, würde diese Datei nicht auf dem Server interpretiert, sondern als Klartext an den Browser des Angreifers geschickt werden. Dieser kann dann im Quelltext gespeicherte Informationen oder Kennwörter heraussuchen. Diese Angriffstechnik nennt man Forceful Browsing. Einfallstor URL So harmlos sie zunächst aussehen mag, so tückisch wird sie beim Angriff auf Applikationsserver, denn hier bietet das Server-Framework häufig Funktionen über bekannte URLs. Selbst wenn diese URLs innerhalb der Applikation nicht verwendet werden, sind sie unter Umständen dennoch aktiv, und ein Angreifer kann durch direkte Eingabe der URL in der Adresszeile seines Browsers die dort angebotenen Funktionen aufrufen und nutzen. Ein SAP Web Application Server etwa bietet bereits in einer Basisinstallation mehr als 150 solcher URL-basierten Dienste an. Hier haben Administratoren kaum einen Überblick über die freigeschalteten oder tatsächlich benötigten Dienste und deren Funktionen. Diese könnten beispielsweise über den externen Zugriff auf SAP Remote Function Calls (RFCs) über das Simple Object Access Protocol (SOAP) für Unbefugte erreichbar sein. Ein Angreifer, der die Standard-URL einer dieser Funktionen kennt, ist damit in der Lage, Transaktionen auf dem SAP-Server auszulösen oder in einem zweiten Schritt Fehler in den somit erreichbaren SAP-RFCs auszunutzen und II den SAP-Server selbst unter seine Kontrolle zu bringen. Etwas komplizierter ist der häufig genannte SQL-InjectionAngriff. Er kann Webapplikationen betreffen, die Daten in einer SQL-Datenbank speichern oder auf Daten einer bestehenden SQL-Datenbank zugreifen. Beispielsweise könnte eine Webapplikation Produktinformationen aus einer Datenbank abrufen und anzeigen, nachdem der Anwender die Artikelnummer des gewünschten Produkts eingegeben hat. Der zum Abfragen der Datenbank benötigte SQL-Befehl ließe sich dafür aus einem festen Teil und der eingegebenen Artikelnummer zusammenbauen. Zum Beispiel könnte der Programmierer den festen Text select name, beschreibung, preis from artikel where artno = ' mit der vom Benutzer eingegebenen Nummer und einem abschließenden Hochkomma zusammenfügen. SQL Injection nach Schema F Ein Angreifer macht sich dieses harmlose Programmkonstrukt zunutze und gibt anstelle einer Artikelnummer beispielsweise folgenden Text ein: ' union select name, password, null from shopusers --. Das erste Hochkomma terminiert den zu suchenden Text aus dem ursprünglichen SQL-Befehl und erweitert diesen dann mit dem Union-Schlüsselwort, das zwei Select-Befehle miteinander verbindet. Der sich daraus ergebende Befehl, der an die Datenbank gesendet wird, lautet: select name, beschreibung, preis from artikel where artno = '' union select name, password, null from shopusers -- . Die beiden Bindestriche am Ende der Eingabe sorgen dafür, dass der folgende Text als Kommentar interpretiert wird und damit keinen Syntaxfehler auslösen kann. Der Angreifer würde in diesem Beispiel Namen und Kennwörter von Angriffe auf CGI, PHP, Servlets Internet Angreifer Angriffe auf den Serverprozess bösartige Inhalte in Daten (URLs, Form contents, cookies) HTTP / Port 80 klassische Angriffe auf das Betriebssystem Angriffe auf Webapplikationen können klassische Firewalls nicht abwehren, denn sie erfolgen über erlaubte Wege, etwa Formulareingaben auf Webseiten et cetera (Abb. 1). anderen Benutzern aus der Datenbank angezeigt bekommen. Dieses vereinfachte Beispiel geht davon aus, dass der Angreifer bereits weiß, dass es eine interessante Tabelle mit Namen shopusers gibt. Auch weiß er, welche Spalten die Tabelle enthält. In der Praxis müsste er dies erst herausfinden. Das bereitet jedoch keine größeren Schwierigkeiten, denn die vorhandenen Tabellen und ihre Spaltennamen stehen in bekannten Systemtabellen beziehungsweise in Views, die man ebenfalls abfragen kann. Bei Microsoft SQL gibt es dafür beispielsweise Views wie sys.objects oder sys.tables. Ein Angriff per SQL Injection ist damit meist ein Vorgang in mehreren Schritten. Im ersten Schritt identifiziert der Angreifer Eingabefelder oder andere Parameter, die für eine Datenbankabfrage verwendet werden. Im zweiten Schritt ermittelt er durch Ausprobieren die Struktur des benutzten SQLBefehls und die Anzahl der abgefragten Spalten und danach fragt er schrittweise Systemtabellen und Benutzertabellen ab. Selbstverständlich beschränkt sich SQL Injection nicht nur auf das Auslesen von möglicherweise vertraulichen Daten. Genauso kann ein Angreifer im letzten Schritt auch Daten in der Datenbank manipulieren. Des LAN Webserver Weiteren ist es gelegentlich sogar möglich, aus dem SQLServer auszubrechen und die Kontrolle über das Betriebssystem des Datenbankservers zu erlangen. Stored Procedures wie XP_CMDSHELL, die wie Microsofts SQL Befehle an das Betriebssystem übergeben, ermöglichen das. Erschwerend kommt hinzu, dass der erste Schritt zur Identifikation von möglichen Ansatzpunkten nicht nur einfach ist, sondern sich auch sehr gut automatisieren lässt. Webapplikations-Scanner nutzen das aus, um Schwachstellen aufzuspüren. WebInspect von HP (früher SPI-Dynamics) oder AppScan von IBM (ehemals Watchfire) durchlaufen wie eine Suchmaschine eine Webapplikation und geben unter anderem in jedes mögliche Eingabefeld Anführungszeichen, doppelte Bindestriche oder andere geeignete Sonderzeichen ein, um damit eine Fehlermeldung der zu prüfenden Applikation zu provozieren. Falls sie dabei an eine einfache SQL-Injection-Schwachstelle geraten, zeigt die zu prüfende Applikation einen internen Fehler oder sogar eine Datenbank-Fehlermeldung an. Daraus lässt sich schließen, dass die Eingabe des Sonderzeichens nicht einfach als Suchbegriff verwendet wurde, iX extra 11/2007 Web Application Firewall der 2. Generation kämpft blitzschnell: Schutz von High-Performance-Anwendungen dank Cluster-Administration und Multi-Prozessoren-Fähigkeit bündelt Kräfte: Verteilte Administration verschiedener Web-Anwendungen dank Mandantenfähigkeit behält den Überblick: Einfache Administration im laufenden Betrieb dank grafischer Oberfläche und Lernmodus www.artofdefence.com ix1107_x_000_ArtOfDefence.indd 1 ix1107_x_03_ArtOfDefence.pdf 1 04.10.2007 15:29:57 Uhr 28.09.2007 13:08:43 Uhr ix.1107.x.1-16 27.09.2007 12:13 Uhr Seite IV IT-Security sondern die SQL-Syntax der Backend-Abfrage verändert hat. Enthält das bereits beschriebene Beispiel nur ein einfaches Anführungszeichen, so ergibt sich der folgende SQL-Befehl: select name, beschreibung, preis from artikel where artno = ''' . Da drei aufeinanderfolgende einfache Anführungszeichen keine gültige SQL-Syntax darstellen, erzeugt die betroffene Webapplikation einen Fehler. Die automatisierte Suche nach Schwachstellen in Webapplikationen durch Provozieren von Fehlermeldungen erscheint auf den ersten Blick relativ einfach. In der Praxis gibt es jedoch viele Webshops oder Portale mit einer komplizierten Session-Verwaltung, sodass schon das vollständig automatisierte Durchlaufen aller Seiten mit einem Crawler alles andere als trivial ist. Dies ist wohl einer der Gründe dafür, dass es bisher nur wenige kommerzielle Prüfwerkzeuge und im Open-Source-Umfeld bisher keine vergleichbaren Produkte gibt. Keine Änderung zur Laufzeit Es existieren mehrere Ansätze, die eine SQL Injection verhindern sollen. Die beste Methode besteht jedoch darin, im Allgemeinen sogenannte Prepared Statements für SQL-Befehle zu verwenden. Damit kann man auf die Textverkettung zum Zusammenbauen von SQL-Befehlen verzichten und eine Änderung der Befehle zur Laufzeit ist nicht mehr möglich. Die sicherlich am häufigsten vorhandene und dennoch am wenigsten verstandene Schwachstelle nennt sich Cross-Site Scripting oder abgekürzt XSS. Dabei wird nicht die Applikation selbst sondern der Browser eines anderen Anwenders über eine Schwachstelle in der Applikation angegriffen. Grundlage dafür ist Skript-Code, zumeist Javascript, der einem Anwender wie ein Teil der Web- IV site angezeigt und dabei vom Browser des Anwenders interpretiert wird. Die Auswirkungen reichen vom Vortäuschen von Seiteninhalten über das Stehlen von Zugangsdaten oder Session-IDs bis hin zur Kontrollübernahme des Browsers durch einen Angreifer. Die verwundbare Webapplikation, die den Angriff auf ahnungslose Anwender ermöglicht, ist zunächst nur ein Vermittler. Erst wenn ein Angreifer die Session-ID eines anderen legitimen und authentifizierten Benutzers per XSS stiehlt, kann er in einem zweiten Schritt auf Bereiche der Applikation zugreifen, die eigentlich nur für authentifizierte Benutzer erreichbar sind. Damit wird XSS zu einer Schwachstelle, mit der man auch starke Authentifizierung und Zugriffsbeschränkungen bei einer Webapplikation umgehen kann. In der trivialsten, aber eher seltenen Form von XSS bietet die Applikation dem Anwender eine Eingabemöglichkeit wie bei einem Gästebuch. Er kann Text eingeben, der auf dem Server gespeichert wird und den andere Benutzer später wieder angezeigt bekommen. Ist es bei dieser Texteingabe möglich, HTML-Tags und vor allem das <script>-Tag einzugeben, kann ein Benutzer Javascript-Code zwischen <script> und </script> in seinem Text einbetten. Jeder Benutzer, der den Text später ansieht, erhielte dann nicht die Tags und den Code angezeigt, sondern sein Browser würde den JavascriptCode ausführen. Man spricht deshalb von persistentem XSS oder auch stored XSS. Sehr viel häufiger kommt nicht persistentes XSS vor. Dabei speichert die Applikation den Skript-Code nicht, sondern diesen muss das Opfer unbemerkt selbst als Parameter an einen Link übergeben. Der Angreifer benötigt dazu beispielsweise ein Eingabefeld oder einen URL-Parameter, der in einer Folgeseite ungefiltert wieder ausgegeben wird. Das klassische Beispiel hierfür sind Suchfunktionen innerhalb von Webseiten, bei denen der Benutzer einen Suchbegriff wie „XYZ“ eingeben kann und die Website danach die Ergebnisse mit dem Hinweis „Ihre Suche nach XYZ ergab folgende Treffer“ beantwortet. Das Opfer als Täter Da man solche Suchmasken nicht von Hand ausfüllen muss, sondern auch der direkte Aufruf des Skripts mit dem Suchbegriff als URL-Parameter möglich ist, könnte ein Angreifer einen Link auf die Suchseite mit Javascript zwischen <script> und </script> als Parameter verwenden. Diesen Link schickt er in einer gespooften Mail an ahnungslose Benutzer der Website, die dann beim Klick auf den Link zwar auf der echten Website landen, dabei aber den Javascript-Code zurückbekommen. Selbst vorsichtige Benutzer, die vor dem Klicken auf einen Link nachsehen, auf welchen Server der Link wirklich verweist, würden erkennen, dass der Link auf den echten Server zeigt. Der angehängte SkriptCode kann durch geschickte Schreibweise unauffällig gemacht werden. Zum Erkennen von XSS bieten sich die genannten Webapplikations-Scanner an. Bei ihrem Einsatz versucht die Software jedoch nicht, Fehlermeldungen zu provozieren. Stattdessen setzt sie automatisch Text zwischen Tags wie <script> und </script> in alle Eingabefelder und Parameter und prüft danach, ob die Eingabe ungefiltert in einer Ausgabeseite wieder auftaucht. Entsprechend einfach ließe sich XSS verhindern. Entweder bei der Eingabeverarbeitung oder der Aufbereitung von Ausgabeseiten oder im Idealfall sogar an beiden Stellen müsste Textfilterung verhindern, dass entsprechende Tags in Eingaben oder Parametern vorkommen. Da dies in der Praxis jedoch nicht so einfach umzusetzen ist oder immer wieder Parameter vergessen werden, geht der Trend heute zu zusätzlichem Schutz durch Web Application Firewalls. In letzter Zeit bauen immer mehr Serverbetreiber asynchrone Funktionen mit Ajax oder mit Techniken, die unter dem Schlagwort Web 2.0 laufen, in ihre Webapplikationen ein. Naturgemäß stellt sich die Frage, welche Auswirkungen diese neuen Funktionen auf die Sicherheit haben. Dabei ist recht schnell festzustellen, dass die Angriffsmethoden eigentlich gleich bleiben, dass jedoch die Möglichkeiten, Fehler zu machen, zunehmen. Prinzipiell lässt sich feststellen, dass durch Ajax beziehungsweise Web-2.0-Techniken zusätzliche Funktionen auf den Client verlagert werden, wodurch auch ein Angreifer mehr Einfluss auf den Ablauf nehmen kann. Die Angriffsfläche wird also größer. So gibt es beispielsweise Applikationen, die wie bisher auf SQL-Datenbanken im Backend zugreifen, die jedoch jetzt die SQL-Abfragen auf dem Client zusammenbauen und asynchron an den Server senden. Dabei sollte auf den ersten Blick klar sein, dass das keine gute Idee ist. Ein Angreifer kann jetzt so tun, als sei er ein Client und direkt SQL-Befehle an den Server senden, ohne sich um die Tricks und Kniffe von SQL Injection kümmern zu müssen. Einfacher kann man es einem Angreifer fast nicht machen. In diesem Fall handelt es sich nicht mehr um SQL Injection, sondern bereits um „SQL Invitation“. (sf/ur) Stefan Strobel ist Buchautor und Geschäftsführer des Heilbronner Beratungsunternehmens Cirosec. iX extra 11/2007 SUPERBLADETM GET THE EDGE ■ Performance mit bis zu 160 Cores in 7 HE Einsatz von Intel® Xeon® oder AMD Opteron® Der SuperBlade™ sind optimiert für folgende Anwendungen: Enterprise, Finanzdienste, ■ Dual- oder QuadCore Prozessoren Netzteile mit 90%+ Wirkungsgrad Datenbanken, Datenbank Center, wissenschaftliche Anwendungen, HPC, Personal Super Computer. ■ ■ Weniger Verkabelung Ethernet- und Infiniband-Switches ■ Sehr gutes Preis-/Leistungsverhältnis © www.artraction.de, 06/07 ■ ServerBlade mit 3.5" oder 2.5" Festplatten Infiniband Switch mit 10 externen Anschlüssen Weitere Informationen über unsere Produkte unter: www.cpigmbh.de und Hotline 0800-100 82 69 Alle Marken- und Produktbezeichnungen sind Warenzeichen oder eingetragene Warenzeichen des entsprechenden Unternehmens. Druckfehler, Irrtümer und Änderungen vorbehalten. ix1107_x_05_CPI_WH.pdf 1 ix0707_x_000_CPI.indd 1 Gigabit Ethernet Switch mit 10 externen Anschlüssen Management Modul zur Überwachung CPI Computer Partner Handels GmbH Kapellenstr. 11 D-85622 Feldkirchen Telefon: (+49)-0 89/96 24 41- 0 Telefax: (+49)-0 89/96 24 41- 33 04.10.2007 15:29:50 Uhr 08.06.2007 12:24:25 Uhr ix.1107.x.1-16 27.09.2007 12:13 Uhr Seite VI IT-Security Die Türsteher Firewalls für Webanwendungen Das erste Gebot für die Sicherheit von Webanwendungen ist eine sorgfältige Programmierung, die Schwachstellen vermeidet. Doch selbst dann bleiben die Applikationen angreifbar und müssen zusätzlich mit einer Web Application Firewall geschützt werden. o technisch unterschiedlich die Angriffe auf Webanwendungen wie Forceful Browsing, SQL Injection, Cross-Site Scripting oder Parametermanipulation auch sein mögen – sie werden alle über das HTTP(S)Protokoll zum Webserver beziehungsweise zur Webanwendung transportiert. Herkömmliche Paketfilter, die heute zum Teil noch als einzige Schutzmaßnahme vor dem Webserver stehen, erkennen solche Angriffe auf Anwendungsebene nicht, denn sie sind nicht in der Lage, in die über das HTTP-Protokoll übertragenen Inhalte hineinzuschauen. Auch das regelmäßige Patchen des Webservers schützt leider nicht gegen diese Art von Angriffen. Die Ursachen für die Schwachstellen, die diese Art von Attacken auf der Anwendungsebene erst möglich machen, sind fast immer Programmier- oder Designfehler bei der Entwicklung der Webanwendung. Nichts erscheint also naheliegender als sicher zu programmieren, um so die Schwachstellen von vornherein zu vermeiden. Dazu gehört zum Beispiel, dass sämtliche Daten, die an die Anwendung weitergegeben werden, auf „bösartige“ Inhalte überprüft werden. Auf diese Weise lassen sich etwa SQL- oder Command-InjectionAngriffe erkennen. Um Parametermanipulationen aufzuspüren, muss man die Daten zusätzlich auf Gültigkeit bezüglich ihres aktuellen Kontextes prüfen. S VI Leider erfordert die sichere Programmierung ein umfassendes und stets aktuelles Knowhow des Entwicklers im Bereich der Angriffstechniken auf der Anwendungsebene. Die Entwicklung eines Filters zur Erkennung bösartiger Benutzereingaben ist komplex und aufwendig, denn schließlich muss man alle Angriffsarten in allen Ausprägungen berücksichtigen – auch dann, wenn sie in kodierter Form vorliegen. Gleichzeitig muss die Anwendung weiter funktionieren. Der Auftraggeber einer Webanwendung hat sicherlich kein Verständnis dafür, wenn ein Anwender in ein Namensfeld zum Beispiel O’Brian eingibt und die HTTPAnfrage aufgrund des Hochkommas wegen Verdachts auf SQL Injection verworfen wird. Kein Einfluss auf Fremdcode Darüber hinaus stellt die sichere Programmierung keine vollständige Lösung des Problems dar. Selbst eine optimal programmierte Webanwendung ist immer noch angreifbar. Der Grund dafür liegt darin, dass bei einer Webanwendung stets Fremdcode zur Ausführung kommt, auf dessen Qualität der Entwickler keinen Einfluss hat. Beispiele für diese Art von Fremdcode sind Programmbibliotheken Dritter, die man in den eigenen Code einbindet, oder die eingesetzten Web- und Applikationsserverprodukte, bei denen regelmäßig kritische Schwachstellen bekannt werden. Außerdem sind die heutigen Webanwendungen häufig selbst Drittprodukte, beispielsweise Portalanwendungen oder Webzugriffslösungen für E-Mail. Aus diesen Gründen empfiehlt es sich für Unternehmen und Behörden, ihre Webanwendungen durch den Einsatz sogenannter Web Application Firewalls (kurz WAF) vor Angriffen zu schützen. Eine WAF steht vor der Webapplikation (siehe Abbildung 1) und prüft jede HTTPAnfrage des Anwenders (oder Angreifers), bevor sie zur Anwendung gelangt. Erkennt sie bei der Prüfung einen Angriff, beispielsweise eine manipulierte Session-ID oder einen Betriebssystembefehl in einem Formularfeld (Command Injection), leitet sie die Daten nicht weiter, sondern erzeugt einen Protokolleintrag und liefert eine Fehlerseite an den Anwender aus. Web Application Firewalls sind meist als Reverse Proxy in ein Netzwerk integriert. Das heißt, sie nehmen stellvertretend für den Webserver jede HTTP-Anfrage des Anwenders entgegen, untersuchen sie inhaltlich und bauen dann eine neue, zweite HTTP-Verbindung zum von ihnen geschützten Webserver auf. Der Anwender merkt nicht, dass er nicht mit dem Webserver direkt kommu- niziert. Die meisten WAF-Produkte lassen sich alternativ auch als Bridge ins Netzwerk integrieren, ähnlich wie ein netzwerkbasiertes IntrusionPrevention-System. Im Falle dieser Integrationsvariante spricht der Anwender weiterhin direkt mit dem Webserver; die WAF sitzt aber im Datenstrom und holt sich die HTTP-Pakete heraus, um die darin enthaltenen Daten inhaltlich zu prüfen. Für geschäftskritische Anwendungen, die meistens auf sensible Backend-Systeme wie SAPs R/3 oder Datenbanken im internen Netzwerk zugreifen müssen, ist der Einsatz einer WAF besonders wichtig. Allerdings kommunizieren in solchen Fällen Anwender und Webserver typischerweise verschlüsselt über SSL. Damit ist jedoch die inhaltliche Analyse des Datenstroms zunächst unmöglich. WAF-Produkte bieten jedoch die Möglichkeit, SSL zu terminieren (Reverse Proxy) beziehungsweise passiv zu entschlüsseln (Bridge). Aufgrund ihrer Architektur sind moderne Systeme so leistungsfähig, dass durch die Entschlüsselung keine spürbaren Performance-Einbußen entstehen. Die Praxis zeigt übrigens, dass fast immer die Webanwendung mit ihren vielen Transaktionen den Flaschenhals bildet und nicht die Verarbeitung durch die WAF. Webanwendung 1 Webanwendung 2 WAF Angreifer Da auch bei sorgfältiger Programmierung Angriffsmöglichkeiten auf Webanwendungen bestehen, sollte man sie mit einer vorgeschalteten Web Application Firewall, die alle HTTP-Anfragen prüft, schützen (Abb. 1). Webanwendung 3 Webanwendung n iX extra 11/2007 ix1107_x_07_datsec.indd.pdf 1 ix1107_x_000_datsec.indd 1 04.10.2007 15:29:46 Uhr 01.10.2007 16:34:14 Uhr ix.1107.x.1-16 27.09.2007 12:13 Uhr Seite VIII IT-Security Der Schutzmechanismus einer Web Application Firewall beruht auf ihrem Verständnis der von ihr geschützten Webanwendungen mit ihren einzelnen Seiten, Eingabefeldern, Cookies und Statuswerten. All dies befähigt sie, die aufgerufenen URLs sowie die Parameter in GETund POST-Requests zu kontrollieren und dabei Angriffe zu erkennen und zu blockieren. Woher weiß aber die Firewall, welche URLs zur Webanwendung gehören, ob Benutzereingaben gutartig sind oder ob beispielsweise eine Session-ID manipuliert wurde? Kontrolle der aufgerufenen URLs Eine WAF muss gewährleisten, dass nur URLs aufgerufen werden können, die zur Anwendung gehören. Der Zugriff auf alle anderen Ressourcen, die sich unterhalb der Webserver-Wurzel befinden, zum Beispiel DLLs, alte Dateiversionen (.old, .bak, et cetera) oder gar andere, interne Webanwendungen muss verhindert werden. Allein durch diese Kontrolle der URL-Aufrufe lässt sich bereits ein großer Teil des Angriffspotenzials vom Webserver fernhalten. Durch den Whitelist-Ansatz sind nur noch die URLs aufrufbar, die zur Anwendung gehören, alle anderen Zugriffe sind damit automatisch verboten. Es stellt sich die Frage, wie eine WAF unterscheiden kann, welche URLs zur Anwendung gehören und welche nicht. Die am Markt verfügbaren Produkte nutzen im Wesentlichen zwei Techniken für das Lernen der erlaubten URLs: dynamisches Lernen zur Laufzeit sowie statisches vor Aktivierung der WAF-Policy. Verwendet die WAF die Technik des dynamischen Lernens, so „merkt“ sie sich die erlaubten URLs automatisch zur Laufzeit, also während der Anwender surft, durch Analyse der vom Webserver an den Anwender gesendeten Webseiten. Im Idealfall muss der Administrator nur einmal die gewünschten Einstiegsseiten der Webanwendung als erlaubte URLs definieren. Anschließend sucht die WAF zur Laufzeit aus jeder angeforderten Seite die im HTMLCode enthaltenen Links (<a href …>) und Formular-Aktionen (<form action …>) und fügt sie automatisch einer Liste der für diesen Anwender erlaubten URLs hinzu (siehe Abbildung 2). Beim dynamischen Lernen kann der Anwender also stets nur die bis zum jeweiligen Zeitpunkt gelernten URLs aufrufen. Es gilt das Motto: Alles was verlinkt ist, gehört zur Anwendung und darf daher aufgerufen werden. In der Regel verwaltet eine dynamisch lernende WAF für jeden Anwender eine individuelle dynamische Policy, die die meis- ten Produkte im Hauptspeicher pflegen. Um die HTTP-Anfrage eines Anwenders „seiner“ Policy zuzuordnen, stellt die WAF ein anwenderspezifisches Cookie aus, das der Browser des Anwenders bei jeder HTTP-Anfrage wieder mit zurückschickt und das die WAF anschließend auswertet. Die Webanwendung bekommt von alledem nichts mit. Nach Ablauf eines frei definierbaren Timeouts, nach dem die WAF vom Anwender keine HTTP-Anfrage mehr gesehen hat, wird die dynamische Policy für diesen Anwender gelöscht. Beim nächsten Mal muss er beim Aufruf der Anwendung wieder über die definierten Startseiten einsteigen. Statisches versus dynamisches Lernen Beim statischen Lernen hingegen definiert der Administrator alle erlaubten URLs im Vorfeld, also vor Produktivschaltung der WAF-Policy. Was zunächst als aufwendig zu konfigurieren klingt, erweist sich in der Praxis jedoch als recht einfach und ist häufig sogar die bevorzugte Lernmethode: Die meisten WAFProdukte unterstützen die Verwendung von Wildcards oder gar von regulären Ausdrücken bei der Definition der URLs (beispielsweise /[a-z].html) und beinhalten vor allem einen Lernmodus. Dieser zeichnet für eine Session 1357 Links: 2b /products/index.html /services/index.html /cgi/feedback.pl GET / 1a GET / 1b 2c Startseite: / start.html 2a Startseite: / start.html Cookie: Session 1357 Anwender 3a GET /msadc/msadcs.dll WAF Webserver Dynamisches Lernen zur Laufzeit: Die WAF analysiert nach dem Aufrufen einer erlaubten Startseite (1a, 1b) alle vom Webserver zurückgelieferten Webseiten (2a) und fügt deren URLs der dynamischen Policy hinzu (2c). Nicht gelernte URLs blockiert sie (3a) (Abb. 2). VIII bestimmte Zeit alle URLs auf, die von einer vertrauenswürdigen IP-Adresse angefordert werden. Unter Verwendung eines Crawlers, der ausgehend von der Startseite alle Links automatisch verfolgt, lässt sich sehr schnell eine komplette Liste aller URLs aufzeichnen. Das dynamische Lernen zur Laufzeit erscheint im Vergleich zum statischen Lernen im ersten Augenblick als die elegantere Lernmethode, müssen doch nur einmalig die gültigen Startseiten definiert werden, und alles Weitere lernt die WAF automatisch. In der Praxis lässt sich das dynamische Lernen aus zwei Gründen jedoch leider nicht immer anwenden. Zum einen gibt es viele Webanwendungen, typischerweise Nachrichtenseiten wie www.heise.de, bei denen jede Seite eine gültige Startseite sein kann. Bei solchen inhalteorientierten Webanwendungen müsste der Administrator in der WAF jede Seite – und davon existieren meist sehr viele – als gültige Startseite hinterlegen, sodass letzten Endes eine statische Policy entsteht. Für andere Arten von Webanwendungen, beispielsweise bei workfloworientierten E-Business-Anwendungen, eignet sich der dynamische Ansatz hingegen optimal: Hier ist es meist ausdrücklich gewünscht, dass der Anwender von einer definierten Startseite aus anfängt und sich von dort Seite für Seite durch die Anwendung durcharbeitet. Eine weiteres K.o.-Kriterium für die Nutzung des dynamischen Lernmodus kann die extensive Verwendung von Javascript im HTML-Code der Anwendung sein. Javascript ist für eine WAF so lange kein Problem, wie der Javascript-Code beispielsweise Plausibilitätsprüfungen bei Eingaben in ein Formularfeld vornimmt, etwa prüft, ob in ein Postleitzahlenfeld genau fünf Ziffern eingegeben wurden. Sobald Javascript aber auch dazu eingesetzt wird, auf iX extra 11/2007 Warum vertrauen mehr als 1 Million Kunden unseren Microsoft® SQL Server™ Lösungen? Die maßgeschneiderte Lösung Dell™ und Microsoft® arbeiten eng zusammen, um Ihrem Unternehmen eine perfekt integrierte, vorkonfigurierte End-to-End Lösung anbieten zu können - optimal und individuell zugeschnitten auf Ihre speziellen Anforderungen! Ihre Vorteile auf einen Blick Microsoft® SQL Server™ 2005 Lösungen von Dell™ wurden von Experten getestet und geprüft. Das Ergebnis ist eine hochwertige, skalierbare und verlässliche Businesslösung, die Ihnen helfen kann, Risiken zu minimieren und Kosten zu reduzieren - und dabei eine herausragende Leistung liefert. Dell™ Lösungen bieten Ihnen eine ausgewogene Kombination aus Server- und Speichersystemen, Microsoft® Applikationen und Dell™ Professional Services (DPS) - alles aus einer Hand. Die auf Dell™ basierten Microsoft® SQL Server™ 2005 Lösungen sind laut TCP-C Benchmark* Spitzenreiter im Preis-Leistungs-Vergleich. Beginnen Sie jetzt! Wenden Sie sich an unsere Kundenbetreuer, die Ihnen gerne Ihre individuelle IT-Lösung zusammenstellen. 0800 / 2 17 33 55 Mo - Fr 8 - 19 Uhr, Sa 10 - 16 Uhr Bundesweit zum Nulltarif Sie benötigen weitere Informationen zu unseren Datenbank-Lösungen? Besuchen Sie uns unter www.dell.de/sql Diese Werbung richtet sich an kleine und mittelständische Unternehmen. Die gesetzlichen Verbraucherschutzregelungen bleiben unverändert wirksam. Es gelten die allgemeinen Geschäftsbedingungen der Dell GmbH. Angebot kann von Abbildung abweichen. Änderungen, Druckfehler und Irrtümer vorbehalten. Dell, das Dell Logo, PowerEdge und PowerVault sind Marken der Dell Inc. Microsoft, Windows, SQL Server, Windows Vista und das Windows Vista-Logo sind eingetragene Marken oder Marken der Microsoft Corporation in den USA und/oder in anderen Ländern. *Basierend auf Transaction Processing Performance Council (TPC) - www.tpc.org - Top Ten TPC-C by Price/Performance, Version 5 Results, 30-Aug-2007. Dell GmbH, Unterschweinstiege 10, D-60549 Frankfurt am Main. 60802_IX Extra Beihefter_200x2801 1 ix1107_x_09_Dell.pdf 1 04.10.2007 15:29:53 Uhr 21/09/2007 12:18:36 ix.1107.x.1-16.neu2.EP 10.10.2007 11:59 Uhr Seite X IT-Security dem Client zur Laufzeit die in der Seite verlinkten URLs zusammenzusetzen, kommt es unter Umständen zu Schwierigkeiten. Um solche URLs dynamisch zu lernen, müsste die WAF nämlich in der Lage sein, Javascript zu analysieren, damit sie die URLs berechnen kann. Das ist ohne Weiteres machbar, falls die URL im Skript-Code als Ganzes enthalten ist. Wird sie hingegen zum Beispiel mit String-Verkettungen „zusammengebastelt“, eventuell sogar noch unter Verwendung von Variablen, ist die WAF nicht mehr in der Lage, die daraus resultierende URL zu berechnen. In solchen Fällen, wie sie manchmal bei Navigationsleisten anzutreffen sind, muss der Administrator die URLs analog zur Einstiegsseite als statische Ausnahmeregel in der WAF konfigurieren. In der Praxis wird aufgrund der beschriebenen möglichen Seiteneffekte des dynamischen Lernens daher häufig eine statische WAF-Policy definiert und das dynamische Lernen nur für das Lernen von Formular-Aktionen aktiviert, aber nicht für das Lernen der sonstigen verlinkten URLs. Übermittelte Parameter überprüfen Das größte Angriffspotenzial auf Webanwendungen besteht in Injection-Angriffen (SQL Injection, Command Injection, Cross-Site Scripting et cetera), bei denen der Angreifer die jeweilige Angriffssyntax in die Felder von Webformularen eingibt, sowie in der Manipulation der Werte von „Read-Only“-Parametern wie Session-IDs, Hidden-Feldern oder Auswahlmöglichkeiten bei Radio Buttons in Webformularen. Eine zentrale Aufgabe einer WAF ist daher die Kontrolle aller Parameter, die in den HTTP-Anfragen an die Webanwendung übermittelt werden. Im Fall der Read-Only-Parameter muss sie gewährleisten, dass der Anwender die Werte nicht verändert X hat, beispielsweise dass die Session-ID nicht von 123456 auf 123457 geändert wurde. Um Injection-Angriffen vorzubeugen, muss die Firewall alle Benutzereingaben in Webformularen sowie alle sonstigen Parameter hinsichtlich ihres Wertebereichs überprüfen. Zusätzlich muss sie die Länge der Parameterwerte kontrollieren, um der Ausnutzung etwaiger PufferüberlaufSchwachstellen vorzubeugen. Fast alle WAF-Produkte bieten die Möglichkeit, Wert und Länge jedes einzelnen Parameters der Webanwendung individuell zu konfigurieren. In der Praxis ist diese Vorgehensweise jedoch selbst bei einer kleinen Anwendung, die unter Umständen auch noch häufig geändert wird, nicht mit einem vertretbaren Konfigurationsaufwand zu betreiben. Aus diesem Grund aktivieren Anwender stattdessen meist die auf Blacklists basierenden Filtermodule der Firewall, die bei guten Produkten für alle Arten von Injection-Angriffen mitgeliefert werden. Die schwarzen Listen enthalten keine primitiven Muster wie ein <script>-Tag (Cross-Site Scripting) oder ein Hochkomma (SQL Injection), sondern echte Angriffssyntax, zum Beispiel „SQLSonderzeichen gefolgt von einem SQL-Befehl“. Auf diese Weise sind bei einer WAF im Gegensatz zu Technologien wie Intrusion-Detection-/IntrusionPrevention-Systemen kaum False Positives zu beobachten. Die Blacklist-basierten Überprüfungen erfolgen standardmäßig für alle Parameter einer Anwendung. Das heißt, es besteht keine Notwendigkeit, einzelne Parameter zu konfigurieren. Bei einem guten Produkt ist es freilich möglich, einzelne Felder oder Formulare von der Überprüfung auszunehmen und stattdessen etwa den Wertebereich des Parameters in Form einer Whitelist zu konfigurieren. Neben der Kontrolle der Benutzereingaben muss die Integrität der Read-Only-Parameter gewährleistet sein. Hierfür ist es erforderlich, dass die WAF die Benutzer-Session zur Laufzeit verfolgt und sich den Wert eines Read-Only-Parameters merkt, sobald dieser das erste Mal an den Anwender übermittelt wird. Dabei kommt wieder das oben beschriebene Konzept des dynamischen Lernens zur Laufzeit zur Anwendung: Aus den HTMLSeiten, die der Webserver an den Anwender ausliefert, „extrahiert“ die WAF nicht nur die verlinkten URLs (Suche nach <a href …>), sondern auch die darin enthaltenen Read-OnlyParameter, also beispielsweise die Auswahlmöglichkeiten bei einem Radio Button (Suche nach <input type=radio …>). Bei den nachfolgenden HTTP-Anfragen, in denen die Parameter wieder übermittelt werden, prüft die WAF dann, ob die Werte noch dieselben sind. (ur) Steffen Gundel ist Mitgründer der cirosec GmbH in Heilbronn und Experte im Bereich Applikationssicherheit. WEB APPLICATION FIREWALLS UND SCHWACHSTELLENSCANNER Die Übersicht erhebt keinen Anspruch auf Vollständigkeit. Hersteller Produkt Web Application Firewalls Website art of defence hyperguard Breach WebDefend/ModSecurity Cisco AVS 3100 Application Velocity System Citrix Citrix Application Firewall DenyAll rWeb F5 TrafficShield, Magnifier Imperva SecureSphere NetContinuum NC-1100, NC-2000 Protegrity Defiance TMS United Security Providers Secure Entry Server Visonys Airlock Webschwachstellen-Scanner www.artofdefence.com www.breach.com www.cisco.com www.citrix.com www.denyall.com www.f5.com www.imperva.com www.netcontinuum.com www.protegrity.com www.united-security-providers.ch www.visonys.com Acunetix Cenzic HP IBM Mayflower N-Stalker Syhunt www.acunetix.de www.cenzic.com www.hp.com www.watchfire.com https://chorizo-scanner.com www.nstalker.com www.syhunt.com Acunetix Hailstorm WebInspect Appscan Chorizo-Scanner N-Stalker Sandcat iX extra 11/2007 ix.1107.x.1-16 27.09.2007 12:13 Uhr Seite XI epq070778_9140_93x280.qxp 11.09.2007 11:26 Uhr Seite 1 IT-Security Gekonnte Handarbeit Einbruchssimulation mit Proxy und Plug-ins Kraft. Können. Ausdauer. Ihre 19“ IT hat hohe Ansprüche. Die Powerware 9140 USV erfüllt sie. Die größte Gefahr für die Sicherheit von Webanwendungen liegt in den Lücken, die durch Fehler in der Entwicklung zustande kommen. Um diese aufzudecken, lassen sich Scanner einsetzen. Effizienter noch sind die Penetrationstests, die mithilfe von Proxies oder Browser-Plug-ins, aber vor allem in Handarbeit über fingierte Angriffe die Schwachstellen offenlegen. Standardsoftware oder auch sonst weit verbreitete Anwendungen werden in regelmäßigen Abständen auf Sicherheitsprobleme untersucht. Denn die negative Publicity durch die Veröffentlichung einer entdeckten Lücke ist alles andere als ein erwünschter Werbeeffekt. Hinzu kommt, dass sich die auf diese Weise gefundenen Exploits auf dem Markt direkt versilbern lassen. Webapplikationen aber sind in vielen Fällen Eigenentwicklungen und finden in diesem Prozess kaum Beachtung. Deswegen gibt es kaum eine Webanwendung, in der der Interessierte keine Fehler beziehungsweise Schwachstellen findet. Umso wichtiger ist es, diese Anwendungen mit Scannern zu untersuchen. Diese reichen jedoch nicht aus, um alle Fehler zu finden. Deshalb sollte man ergänzend Penetrationstests durchführen. Schwachstellen-Penetrationstestern bieten sich einige Werkzeuge zur Automatisierung ihrer Aktionen an. Diese Tools sind hervorragend für die Vereinfachung des ersten Schritts dieser Aufgabe geeignet, doch die wirkliche iX extra 11/2007 Überprüfung muss immer in Handarbeit erfolgen. Ziel einer solchen Überprüfung ist es, die Sicherheit in der Kommunikation zwischen der Oberfläche der Anwendung und dem Server im Backend zu gewährleisten. Jede Anwendung bietet dem Benutzer eine Oberfläche, die sich als HTML-Format darstellt, aber im Hintergrund mit unterschiedlichen Techniken mit dem Server kommuniziert. In der einfacheren Welt vor vielen Jahren wurde diese Kommunikation über das Common Gateway Interface (CGI) abgewickelt. Es galten unkomplizierte Regeln, jeden Mausklick setzte der Browser in einen Request um und übertrug die Daten per POST oder GET. Dank neuer Techniken wie Javascript, Ajax, Webservices und Flash wird dem Browser die früher nur im Server enthaltene API präsentiert. Diese Tatsache macht das Testen nicht einfacher, aber wenigstens interessanter. Bei einem Penetrationstest hat der Tester die Aufgabe, unabhängig von der vorhandenen Technik die übertragenen Daten so zu verändern, Kraft 7,5 – 10 kVA saubere, kontinuierliche Leistung in nur 6 HE Können Einfachste Installation, Wartung und Management Ausdauer Sicherer Betrieb schützt Ihre wertvollen IT-Investitionen über viele Jahre hinweg In Racks mit mittlerer bis hoher Leistungsdichte liefert die Doppelwandler-USV Powerware 9140 höchste Sicherheit – keinen Stress. Mehr unter: www.powerware.de Tel. +49 (0) 7841 604-0 …mit Sicherheit U S V- U N D D C - S Y S T E M E ix.1107.x.1-16 27.09.2007 IT-Sicherheit Ihr Spezialist für die Sicherheit von Web-Applikationen • Sicherheitsüberprüfungen / Audits • Beratung zu Architekturen, Konzepten und Entwicklungsrichtlinien • Schutz von WebApplikationen mit Web-ApplikationsFirewalls (WAFs) 12:13 Uhr Seite XII IT-Security dass potenzielle Fehler aufgespürt und ausgenutzt werden können. Jedes Formular, jedes Datenfeld, auch die verdeckten und im Hintergrund von beispielsweise Javascript inklusive Ajax übermittelten, nehmen ihren Weg durch das World Wide Web. Dies vereinfacht die Aufgabe des Testers, denn alle Daten werden im Klartext übertragen, und die Technik zum Abfangen dieser Daten setzt ohnehin schon jedes Unternehmen ein – denn nichts anderes macht ein Proxy. So ist es naheliegend, auch die Penetrationstests durch einen Proxy zu unterstützen. Das OWASP (Open Web Application Security Project) bietet den WebScarab an, der durch seine vielen Funktionen Tests gut unterstützt. Die wichtigste Funktion ist die komplette Aufzeichnung der Requests. So kann der Tester die Webanwendung einfach beobachten und eine Liste aller genutzten Parameter und der in diesen üblicherweise übertragenen Daten erstellen. Im nächsten Schritt verändert er diese Daten so, dass der Server Dinge tut, die so vom Programmierer nicht beabsichtigt waren. Proxy als Werkzeug Eine vom Hacker gewünschte Reaktion sind Fehlermeldungen, die interne Daten offenlegen. Eine andere ist die Ausführung von Shell- oder • Trainings Hacking Extrem Web-Applikationen Lernen Sie die Vorgehensweise der Angreifer sowie bekannte und weniger bekannte Angriffstechniken auf Web-Applikationen in einem sehr praxisorientierten Stil kennen! Nur so können Sie Ihre IT-Infrastruktur vor Angriffen schützen. 06.11. - 08.11.2007 Hamburg 04.12. - 06.12.2007 München Wiederholbarkeit erwünscht Ein Zugriff auf www.heise.de, aufgezeichnet vom WebScarab. Gut zu sehen die Anfragen an Werbeanbieter und WebseitenTracker (Abb. 1) Angriffe und Gegenmaßnahmen für Web-Applikationen und E-Business-Systeme In diesem Training werden Angriffsarten auf WebApplikationen & E-BusinessSysteme anhand zahlreicher, praxisnaher Beispiele demonstriert. Am zweiten Tag stellen wir ausführlich innovative Lösungsansätze vor. 20.11. - 21.11.2007 Köln cirosec GmbH Edisonstraße 21 74076 Heilbronn Telefon (0 71 31) 5 94 55-0 www.cirosec.de SQL-Code. Details zu den möglichen Fehlern in Webapplikationen beschreibt der Artikel auf Seite I. Der Tester kann die Requests im Proxy auf zwei Arten verändern. Bei der ersten Methode stoppt der Proxy die Requests vor der Weiterleitung an den Server. Auf der Oberfläche sieht der Tester nun den Request inklusive aller Parameter und deren Daten. Dort kann er jeden angezeigten Wert editieren und danach den gesamten Request absenden. Der Server erhält den Request, als ob er vom Browser direkt gesendet worden wäre und kann keinen Unterschied feststellen. Der Vorteil hierbei besteht darin, dass ein Penetrationstester in den Ablauf einer Session gezielt eingreifen kann, wenn er beispielsweise ein bestimmtes Element eines Vorgangs als Schwachstelle identifiziert hat, der Server jedoch die Requests nur in einer bestimmten Reihenfolge akzeptiert. Manuelle Request-Bearbeitung im WebScarab mit einem zugefügten Header (Abb. 2) Bei der zweiten Methode nutzt der Schwachstellentester die gespeicherten Daten der bereits gesendeten Requests. Der Proxy wiederum stellt die Daten in seiner Oberfläche zur Bearbeitung zur Verfügung. Auch in diesem Fall schickt der Tester den Request mit einem Klick ab. Der Unterschied und gleichzeitig Vorteil dieser Methode in bestimmten Situationen ist die Möglichkeit, den Vorgang beliebig oft zu wiederholen. Mit der ersten Methode lässt sich pro Klick im Browser nur ein Request bearbeiten, während mit dieser Methode diese Einschränkung fällt, denn der Proxy arbeitet autark und ist nicht davon abhängig, einen neuen Request vom Browser zu erhalten. Somit kann der Tester schnell viele Variationen der geänderten Daten ausprobieiX extra 11/2007 ix.1107.x.1-16 27.09.2007 12:13 Uhr Seite XIII _1I2hKalenderNetze.qxp 28.09.2007 13:48 Uhr Seite 1 IT-Security eMedia Fun-Shop Anzeige der Query-Strings von www.heise.de in Sleuth (Abb. 3) ren. Der Proxy zeigt ihm dafür eine Antwort vom Server im Text- oder HTML-Format an. In dieser Hinsicht lässt sich das Vorgehen am ehesten mit der Arbeit von Webanwendungs-Scannern vergleichen: Auch diese erzeugen Requests mit jeweils leicht veränderten Daten und schicken diese an den Server, um danach die Ergebnisse auszuwerten. WebScarab wie auch die anderen PenetrationstestProxies bieten dementsprechend einen ähnlichen Funktionsumfang wie die Scanner und unterstützen den Tester mit Features wie Fuzzing (das Erzeugen von zufälligen Daten, die über Eingabeschnittstellen eines Programms verarbeitet werden), Session-ID-Analyse und je nach Produkt auch selbst geschriebenen Plug-ins. enthaltenen. Der Zugriff auf die Header, die an den Server gesendet werden, gestaltet sich dabei schwieriger. Zum Hacken ist der WebDeveloper auch nur bedingt geeignet, kann aber in manchen Tests nützliche Dienste leisten. Anders sieht es bei Sleuth aus. Die Software stellt eine Mischform zwischen Proxy und Plugin dar, kann also HTML im Browser bearbeiten und gleichzeitig auch als Proxy mit Automatisierung, Fuzzing und Request-Interception agieren. Der Nachteil der Mischform ist die unübersichtliche Darstellung der Requests und die Abhängigkeit vom Internet Explorer. Der Vorteil jedoch liegt in der übersichtlichen Darstellung der Daten der im Browser angezeigten HTMLSeite und in der eingebauten Authentifizierung. Fazit Hilfreiche Browser Plug-ins Eine dritte Art der RequestBearbeitung arbeitet mit Browser-Plug-ins, die es für den Internet Explorer in Form von Sleuth von www.sand sprite.com oder mit dem WebDeveloper von Chris Pederick für den Firefox gibt. Über die Plug-ins erhält der Tester einen Zugriff auf die HTML-Ergebnisse, während sie der Browser darstellt. Auch in diesem Fall kann er alle Werte verändern, allerdings nur die in der HTML-Darstellung Durch schlanke und funktionale Werkzeuge kann ein Test einer Webanwendung erfolgreicher und schneller durchgeführt werden. Allerdings ist der Erfolg stark von der Erfahrung des Testers abhängig, da jede Webapplikation unterschiedliche Lücken hat, die sich teilweise an überraschenden Stellen in der Request-Verarbeitung verstecken. (sf/js) Christoph Puppe ist Security Consultant bei der HiSolutions AG in Berlin und seit mehreren Jahren als Berater tätig. Der c’t Kalender 2008 Die besten Illustrationen aus der c’t DIN A3, quer, 26 Kalenderblätter, 4-farbig Best.-Nr.: 77759 Preis: 14,80 € Ein tragbares „Netzhemd“ T-Shirt „heise Netze“, schwarz, 100% gekämmte Baumwolle, ca. 190 g/m, Nackenband, Doppelnaht an den Ärmeln und am Abschluss. Größe M Größe L Größe XL Größe XXL Best.Nr.: 77731 Best.Nr.: 77732 Best.Nr.: 77733 Best.Nr.: 77734 Preis: jeweils 9,80 € Bestellung eMedia GmbH Bissendorfer Straße 8 D-30625 Hannover Telefon: +49 [0]511 53 72 95 Fax: +49 [0]511 5352-147 [email protected] Preisänderung/Irrtum/Ausverkauf vorbehalten. Alle Preise inkl. MwSt. iX extra 11/2007 ix.1107.x.1-16 27.09.2007 12:13 Uhr Seite XIV IT-Security Meine Identität gehört mir Identity-Management in Zeiten von Webservices und Web 2.0 Infolge der Öffnung der bislang abgeschotteten Unternehmensnetzwerke und der Verbreitung von Webservices rückt das Thema Identitäts- und Zugriffskontrolle noch mehr in den Mittelpunkt. Hier zeichnet sich ein grundlegender Wandel ab: Identity 2.0 soll dem Benutzer die Kontrolle über seine Daten zurückgeben. Die Grundlage bilden zwei ähnliche Systeme, OpenID und CardSpace. etztlich geht es bei IT-Sicherheit immer darum zu gewährleisten, dass nur bestimmte Personen – in ihrer digitalen oder beim physischen Zugang realen Identität – bestimmte Dinge mit Systemen und den darauf laufenden Anwendungen machen dürfen. Die letzten Jahre haben gezeigt, dass Lösungen, die keine Rücksicht auf die Frage der digitalen Identität nehmen, im Grunde nur Notlösungen sind. Nirgendwo wird das deutlicher als bei Webservices. Kaum ein Thema hat die IT so verändert wie die Öffnung einst in sich geschlossener IT-Welten. Heute geht es nicht mehr darum, das Unternehmen nach außen über einen Perimeterschutz – also an der Netzwerkgrenze – abzuschotten. In der heutigen Welt soll vielmehr der Zugang auf IT-Ressourcen von außen erleichtert werden – allerdings nur für ganz bestimmte Personen. Und die sollen auch nur ganz bestimmte Dinge tun dürfen. Dabei will man im Grunde zwei Dinge vereinen, die im Gegensatz zueinander stehen: Öffnung und Kontrolle. Wer die digitalen L Identitäten seiner Kunden, Lieferanten oder auch Mitarbeiter nicht im Griff hat, geht ein hohes Risiko ein. Der Kunde hat ebenfalls zweigeteilte Interessen: Er möchte einerseits schnell und einfach auf Onlineinhalte zugreifen können, andererseits aber seine Privatsphäre gewahrt wissen. Je mehr persönliche Daten er im Zuge einer Shoppingtour im Internet preisgeben muss, desto mehr ver- liert er mit der Zeit die Kontrolle über das, was die Anbieter von ihm wissen. Im Kampf um die informationelle Selbstbestimmung, immerhin ein zumindest in Europa hochrangiges Rechtsgut, ist der Nutzer heute weitgehend der Unterlegene. Ein Grund dafür ist, dass erstaunlich viele Lösungen die Sicherheit heute noch ausschließlich auf der Systemebene angehen, also die Identität des Benutzers beispielsweise mit dessen IP-Adresse gleichsetzen. Das beginnt bei der Paketfilterung und geht bis hin zu Network-Access-ControlLösungen oder Client-Management-Produkten, die zwar Systeme, aber keine individuellen Benutzer kennen. Ohne Identität geht nichts Bei der Kontrolle des Netzwerkzugangs kommt die Identität des Benutzers stärker ins Spiel. Unterschiedliche Mitarbeiter müssen meist auch auf unterschiedliche Anwendungen zugreifen können, um ihre Aufgaben zu erfüllen, und manchmal gelten dabei überdies unterschiedliche Regeln. Das gilt erst recht, wenn Externe auf das Unternehmensnetzwerk zugrei- Relying Parties A B C Policy 1) Get security token requirements Identity Providers 4) Present security token X Y Z Security Token Application InfoCard Information Card 1 3) Get security token Security Token Information Card 2 Information Card 3 2) Select desired identity by choosing an information card Kehrtwende: Anders als bei früheren Versuchen setzt Microsoft bei seinem mit Vista vorgestellten CardSpaceModell, das auf verschiedenen „Visitenkarten” beruht, auf die Kontrolle und Hoheit des Nutzers über seine eigenen Daten – ohne Einwilligung geht nichts. iX extra 11/2007 ix1107_x_000_qskills.indd x1107_x_000_qskills.indd 1 28.09.2007 17:43:08 Uhr ix.1107.x.1-16 27.09.2007 12:13 Uhr Seite XV IT-Security fen sollen. Und will ein Kunde etwas bestellen, bezahlen und an seine Adresse geliefert bekommen, geht es nicht ohne Kenntnis seiner Identität. Sicherheit, das wird dadurch klar, ist nur über erfolgreiches Identitätsmanagement zu haben. Mehr noch: Durchgängige Sicherheitskonzepte vom Perimeter bis zu den Anwendungen verlangen geradezu eine durchgängige Sicht auf die Identität. Sicherheitslösungen müssen also zunehmend auf vorhandene Verzeichnisse zugreifen können – oder auf virtuelle Verzeichnisdienste, die dann auf Verzeichnisse mit Kunden, Partnern oder Mitarbeitern verweisen und so eine virtuelle Gesamtsicht schaffen. Das Hauptproblem der „neuen Offenheit“ vernetzter Systeme liegt nach Ansicht von Experten weniger in der technischen Umsetzung als vielmehr in der alten Sichtweise auf die IT-Security. Diese geht davon aus, dass der Anbieter einer Ware, Dienstleistung oder Information, mithin der Systemadministrator, derjenige ist, der die Identitäten zu verwalten hat. Wer seine persönlichen Daten nicht an der Tür abgibt, kommt gar nicht erst ins System. Dies gefällt einer kleinen, aber wachsenden Schar von Identitäts-Aktivisten gar nicht. Sie fordern nicht mehr und nicht weniger als eine Umkehrung der Machtverhältnisse: Der Benutzer soll wieder die Kontrolle über seine Daten bekommen. Ihr Schlagwort heißt: „User-centric Identity“. Selbstbestimmung auch im Netz Einer von ihnen ist Dick Hardt, Chef der kleinen Softwarefirma Sxip, der für Internet und Webservices ein „dezentrales, kompatibles, skalierbares und sicheres System“ fordert, das dem Menschen erlaubt, sich im Internet genauso einfach auszuweisen wie in der richtigen Welt. Doch Hardt und seine Mitstreiter gehen einen Schritt weiter. Sie wollen, dass der Benutzer selbst bestimmen kann, welche Informationen er im Zuge der Anmeldung und Interaktion mit Webservices preisgibt. Dieses „Identity 2.0“ genannte Prinzip wäre Hardts Meinung nach „ein auf Internetmaß zugeschnittenes Identity- und Access-Management-System, das einfach, sicher und offen ist und bei dem der Benutzer im Mittelpunkt steht“. Bei Identity 1.0 weiß das System nur, dass eine Person ein Eintrag in einem Verzeichnis ist, aber es hat keine Ahnung, wer sie ist. In der abgeriegelten Welt geschlossener Firmennetze hat das noch genügt, zumal der Arbeitgeber der „Besitzer“ der meisten Identitätsdaten der Mitarbeiter war. Im offenen Kontext von externen Webservices funktionieren solche Systeme Hardts Meinung nach nicht. Die Folge sei Ärger und Mehraufwand für den Benutzer, der immer wieder Namen, Kennwörter und viele Informationen über sich selbst eingeben muss. Dies aber steht dem Geschäftserfolg von Onlineanbietern im Weg. Gleichzeitig schafft die fehlende Selbstbestimmung des Nutzers ein Identitätsproblem für die Betreiber von Web-2.0-Anwendungen wie MySpace, Flickr oder die Videoarchive von YouTube, deren Reiz für die meisten Benutzer ja gerade darin besteht, sich nach außen auf möglichst kreative Weise darstellen zu können. Hardts Firma hat mit Sxipper, einem kostenlosen Plug-in für den Firefox-Browser, gezeigt, wo die Reise hingehen soll. Der Benutzer lädt die Erweiterung auf seinen Rechner herunter und trägt darin seine persönlichen Daten ein, etwa Privat- und Geschäftsadresse, Kreditkartennummern oder Führerscheindaten. Jedes Mal, wenn er danach auf eine Website zugreift, die Informationen über ihn fordert, startet Sxipper, stellt die gewünschten Informationen dar und fragt, ob der Benutzer mit der Übermittlung einverstanden ist. Pflichtfelder werden gekennzeichnet, freiwillige Angaben ebenfalls. Mit einem Mausklick auf ein Hakenkästchen entscheidet der Benutzer, welche Daten er weitergeben will und welche nicht. Vielversprechender Zusammenschluss Sxipper ist nur eine Lösung unter einem guten Dutzend, die große und kleine Anbieter unter dem Banner von OpenID entwickeln und anbieten. OpenID ist ein dezentrales System zur Identifizierung, dessen zugrunde liegendes Protokoll von Brad Fitzpatrick, dem Vater von LiveJournal (eine quelloffene Serversoftware), und David Recordon von VeriSign entwickelt wurde. Mit im Boot sind große Anbieter wie IBM und Novell sowie die Eclipse Foundation, die sich Hat Ihr Netzwerk wirklich keine Schwachstellen? Nur die AVG Internet Security Network Edition bietet: 2 Jahre Lizenzlaufzeit Anti-Virus Anti-Spyware Anti-Spam Firewall Kostenlose neue Programmversionen Zentrale Verwaltung für Server, Clients und Desktops 24/7 technische Unterstützung Alles über AVG: www.jakobsoftware.de Halle B 3.14 ix1107_x_000_AVG.indd 1 NE U ! Deutsche Vertretung und deutschsprachiger Support für AVG: Jürgen Jakob Software-Entwicklung · www.jakobsoftware.de 20.09.2007 18:43:26 Uhr AVG75 ISNE01 AVG Internet Security für Windows®, für Netzwerke, für Linux und für E-Mail-Server. ix.1107.x.1-16.neu1 02.10.2007 10:46 Uhr Seite XVI IT-Security unter anderem mit dem quelloffenen Bandit-Projekt an der Entwicklung von Standards für das Identitätsmanagement über unterschiedliche Systeme hinweg beteiligt hat und somit einen einheitlichen Ansatz für die Sicherheit und Verwaltung von Identitäten schaffen will. OpenID dient zunächst nur zur gegenseitigen Identifikation von Benutzern. Die sollen sich mithilfe ihres digitalen Ausweises bei verschiedenen Websites anmelden können, ohne jedes Mal dieselben persönlichen Informationen eintippen zu müssen. Die anschließende Authentifizierung erfolgt durch einen sogenannten Identity Service Provider (auch iBroker genannt). Denjenigen, über dessen Website sich der Benutzer eingeloggt hat, bezeichnet man als „Relying Party“ (RP), denn er vertraut aufgrund seiner – in der Regel vorher vertraglich fixierten – Beziehung zum Identity Service Provider dieser Authentifizierung. Der Identity Service Provider kann bei Bedarf zusätzliche Informationen vom Benutzer anfordern. Im Internet weist sich der OpenID-Benutzer mithilfe eines sogenannten URI (Uniform Resource Identifier) aus, den er von seinem iBroker erhält und der genauso arbeitet wie die URL eines Webdokuments. Zur Authentifizierung verwendet OpenID Standards wie Yadis, ein Protokoll und Datenformat, mit dem Informationen über unterstützte Dienste einer HTTP-URL im Konzept der URI-basierten Identität beschrieben und abgerufen werden können. Im Grunde genommen verwendet der Benutzer seinen URI als Benutzernamen, während sein „Passwort“ sicher beim OpenID-Provider verwahrt wird. Prinzipiell ähneln OpenID-Lösungen dem neuen CardSpaceModell von Microsoft, das der Konzern mit dem Start von Vista einführte. Hier trägt der Benutzer seine Identitätsdaten in sogenannten InfoCards ein, die XVI auf der Festplatte liegen und Informationen wie Name, Geburtsdatum, Wohnort, Geschlecht, Telefonnummern, Kreditkartendaten und Ähnliches enthalten. Er kann mehrere Karten mit unterschiedlich ausführlichen Informationen über sich erstellen, je nach Anforderung. Verlangt nun eine Website bestimmte Daten, zückt CardSpace die passende Karte und fragt den Benutzer, ob er einverstanden ist, diese weiterzugeben. Oft genügt Vertrauen Diese Form der sogenannten Self-assertion (Selbstbehauptung) kommt ohne Verifizierung durch eine übergeordnete Instanz aus. Im Prinzip muss der Anbieter einfach glauben, was ihm der Benutzer sagt. Das ist in vielen Fällen im praktischen Leben ausreichend, etwa um sich Zutritt zu einem kostenlosen Onlinemagazin zu verschaffen oder sich in ein Chat-Forum einzuloggen. Wollen beide Seiten dagegen miteinander Geschäfte machen, genügt eine solche freiwillige Selbstauskunft nicht. In diesem Fall muss sich der CardSpace-Benutzer vorher, ähnlich wie beim iBroker von OpenID, bei einer vertrauenswürdigen Stelle (Trusted Third Party) anmelden und dort seine Daten hinterlegen. Das kann eine offiziell zugelassene Zertifizierungsstelle sein, zum Beispiel ein Trust Center, aber auch eine Bank, eine Kreditkartenfirma oder ein Arbeitgeber. Will ein Internetanbieter Informationen, wird die Anfrage automatisch an die Vertrauensstelle weitergeleitet, die die gewünschte Information bereitstellt. Gleichzeitig ergeht an den Benutzer eine Anfrage nach dessen Einverständnis, die Daten weitergeben zu dürfen. Häufig genügen auch sogenannte Metadaten. Beim Kauf per Kreditkarte reicht meistens eine Bestätigung: „Zahlung erfolgt“. Mehr muss der Anbieter gar nicht wissen. Ähnlich bei Informationen, die lediglich als Altersnachweis dienen. Statt des tatsächlichen Geburtsdatums genügt es, wenn von vertrauenswürdiger Seite bestätigt wird: „Der Kunde ist über 18“. Auf diese Weise soll sich die Menge der preiszugebenden persönlichen Daten im InternetAlltag deutlich reduzieren lassen – zur Freude von Verbrauchern, aber auch zur Entlastung von Anbietern. Für Microsoft stellt OpenCard damit eine radikale Abkehr von früheren Systemen wie MS Passport dar, bei denen die Kontrolle über die Daten weitgehend in Redmond lag. Dennoch kam die Ankündigung im Februar 2007 für die Fachwelt einigermaßen überraschend, dass Microsoft und die OpenID-Gemeinde in Zukunft eng zusammenarbeiten und für vollständige Interoperabilität sorgen wollen. Die Nachricht von der ungewöhnlichen Allianz zeitigte gleich Folgen. So kündigte beispielsweise der Onlinedienst AOL an, künftig mit OpenID arbeiten zu wollen. Und Ping Identity, ein führender Hersteller von IAM-Systemen, will ein CardSpace-Modul als OpenSource-Element für den Apache 2 Server auf den Markt bringen. (sf/ur) Tim Cole ist Consultant bei Kuppinger Cole & Partner sowie Mitveranstalter der European Identity Conference. In iX extra 12/2007 Storage – Disk-Systeme: Technik und Produkte Disk-Subsysteme finden sich in den unterschiedlichsten Anwendungen als Primär- oder Sekundärspeicher, als virtuelle Tape Library, als Backup- oder Archivsystem. Genau so unterschiedlich sind die Umgebungen und Konfigurationen: als Speichererweiterung direkt an Server angeschlossen, für den Zugriff durch mehrere Server in ein Speichernetz eingebunden – als Standalone-System, im Gruppenverbund, kaskadiert, gespiegelt, hierarchisch angeordnet oder über einen Virtualisierer zusammengeschaltet. Entsprechend groß ist die Spannbreite verfügbarer DiskSysteme. Sie reicht vom einfachen JBOD bis zum Super- system mit 247 Petabyte Gesamtkapazität. Was Disk-Systeme heute alles können, wie man das geeignete System für seine Umgebung findet und wie man sich auf künftige Anforderungen vorbereitet, erläutert iX extra in Heft 12/07. Erscheinungstermin: 15. November 2007 DIE WEITEREN IX EXTRAS: Ausgabe Thema Erscheinungstermin 01/08 02/08 Networking Mobility 03/08 IT-Security Aktuelle Trends bei Wireless LANs Mobiler Arbeitsplatz: Konsolidierte Verwaltung; Notebooks als Desktopersatz Malware-Trends – Trojaner, Botnetze & Co. 13.12.07 17.01.08 21.02.08 iX extra 11/2007
