Tückische Ein Verlagsbeihefter der Heise Zeitschriften ... · kaum einen Überblick über die ......

16
I A nalysten und Szenebe- obachter 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 Webapplikatio- nen. Webauftritte mit einfachen HTML-Seiten ohne Formulare und Benutzerabfragen sind für einen Angreifer nur wenig inter- essant. Erst wenn Benutzerein- gaben verarbeitet werden, wie es bei Suchfunktionen, Online- katalogen, 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 be- dient, 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-basier- te Anwendung, eine Webappli- kation auf der Grundlage von Applikationsservern bezie- hungsweise Frameworks wie IBM Websphere, BEA Weblogic oder um eine SAP-Web-Applica- tion-Server-Anwendung handelt, macht kaum einen Unterschied. Denn fehlerfreie Software ist in diesem Umfeld nicht zu erwar- ten, und die Fehler sind meist gleichbedeutend mit Sicher- heitslücken. Der zweite zu be- achtende 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 „Anwendungs- ebene“ 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- IT-Security IT-Security extra Ein Verlagsbeihefter der Heise Zeitschriften Verlag GmbH & Co. KG Schwerpunkt: Tools zur Website- Absicherung Angriffsmöglichkeiten auf Webapplikationen und Abwehrtechniken Tückische Eingaben Seite I 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 Tückische Eingaben Angriffsmöglichkeiten auf Webapplikationen und Abwehrtechniken 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. sponsored by:

Transcript of Tückische Ein Verlagsbeihefter der Heise Zeitschriften ... · kaum einen Überblick über die ......

I

Analysten und Szenebe-obachter sind sich einig:

Die meisten Hacker-Angriffe imWeb erfolgen heutzutage aufApplikationsebene. Dabei gehtes nicht um einfache Websitesmit statischem Inhalt, sondernum dynamische Webapplikatio-nen. Webauftritte mit einfachenHTML-Seiten ohne Formulareund Benutzerabfragen sind füreinen Angreifer nur wenig inter-essant. Erst wenn Benutzerein-gaben verarbeitet werden, wiees bei Suchfunktionen, Online-katalogen, Bestellsystemen undso weiter der Fall ist, wird es fürHacker spannend. Besondersattraktiv sind Portale, die fürKunden oder Partnerfirmenkonzipiert sind und mit internenIT-Systemen interagieren.

Werden solche Systemeüber einen Webbrowser be-dient, kann man in den meistenFällen davon ausgehen, dasssie Fehler enthalten, die einemAngreifer Tür und Tor öffnenkönnen. Ob es sich im Einzelfallum eine ASP- oder PHP-basier-te Anwendung, eine Webappli-

kation auf der Grundlage vonApplikationsservern bezie-hungsweise Frameworks wieIBM Websphere, BEA Weblogicoder um eine SAP-Web-Applica-tion-Server-Anwendung handelt,macht kaum einen Unterschied.Denn fehlerfreie Software ist indiesem Umfeld nicht zu erwar-ten, und die Fehler sind meistgleichbedeutend mit Sicher-heitslücken. Der zweite zu be-achtende Ausgangspunkt ist,dass bestehende Firewalls inder Praxis nicht vor Angriffenauf Webapplikationen schützenkönnen, selbst wenn derenHersteller mit Funktionen fürden Schutz auf „Anwendungs-ebene“ werben.

Eine der ältesten und auchtrivialsten Angriffsmethodenberuht schlicht und einfach auf dem Zugriff auf URLs, dieeigentlich nicht erreichbar sein sollten und die innerhalbder Anwendung auch nichtverlinkt sind.

In der Praxis kommt esimmer wieder vor, dass eineASP-Datei in einer älteren Ver-

IT-Security

IT-Securityextra

Ein

Ver

lags

bei

heft

er d

er H

eise

Zei

tsch

rifte

n V

erla

g G

mb

H &

Co.

KG

Schwerpunkt: Tools zur Website-AbsicherungAngriffsmöglichkeiten auf Webapplikationen und Abwehrtechniken

Tückische Eingaben Seite IFirewalls für Webanwendungen

Die Türsteher Seite VIEinbruchssimulation mit Proxy und Plug-ins

Gekonnte Handarbeit Seite XIIdentitätsmanagement in Zeiten vonWebservices und Web 2.0

Meine Identität gehört mir Seite XIVVorschau

StorageSchwerpunkt: Disk-Systeme – Technik und Produkte Seite XVI

Veranstaltungen22. – 24. Oktober, LondonRSA Europewww.rsaconference.com/2007/Europe

23. – 26. Oktober, MünchenSystemswww.systems.de

3. – 4. November, KölnEuropean Software Conference (ESWC)www.euroconference.org

19. – 21. November, DüsseldorfiX-Konferenz: Bessere Software! www.ix-konferenz.de

TückischeEingabenAngriffsmöglichkeiten auf Webapplikationen und Abwehrtechniken

Die meisten heute verfügbaren Sicherheitsprodukte sind nicht in der Lage, die Anwendungen auf einemWebserver adäquat zu schützen. Hinzu kommt, dass es kaum Webanwendungen gibt, die fehlerfrei sind.Zum Schutz vor Übergriffen sollten Anwender diegängigsten Angriffstechniken verstehen und einenApplikations-Scanner sowie eine mit speziellenFunktionen ausgestattete Firewall installieren.

sponsored by:

ix.1107.x.1-16 27.09.2007 12:13 Uhr Seite I

sion mit der Endung .old oder.bak auf dem Server liegenbleibt. Wird beispielsweise eineASP-Datei mit Namen feedback.asp als www.ix.de/feedback.aspaufgerufen, könnte ein Angreiferdurch Ausprobieren eine URLwie www.ix.de/feedback.asp.old finden. Da die Endungnicht mehr .asp sondern .oldlautet, würde diese Datei nichtauf dem Server interpretiert,sondern als Klartext an denBrowser des Angreifers ge-schickt werden. Dieser kanndann im Quelltext gespeicherteInformationen oder Kennwörterheraussuchen. Diese Angriffs-technik nennt man ForcefulBrowsing.

Einfallstor URL

So harmlos sie zunächst aus-sehen mag, so tückisch wird siebeim Angriff auf Applikations-server, denn hier bietet das Ser-ver-Framework häufig Funktio-nen über bekannte URLs. Selbstwenn diese URLs innerhalb derApplikation nicht verwendetwerden, sind sie unter Umstän-den dennoch aktiv, und ein An-greifer kann durch direkte Ein-gabe der URL in der Adresszeileseines Browsers die dort ange-botenen Funktionen aufrufenund nutzen. Ein SAP Web Appli-cation Server etwa bietet bereitsin einer Basisinstallation mehrals 150 solcher URL-basiertenDienste an.

Hier haben Administratorenkaum einen Überblick über diefreigeschalteten oder tatsäch-lich benötigten Dienste undderen Funktionen. Diese könn-ten beispielsweise über den ex-ternen Zugriff auf SAP RemoteFunction Calls (RFCs) über dasSimple Object Access Protocol(SOAP) für Unbefugte erreichbarsein. Ein Angreifer, der dieStandard-URL einer dieserFunktionen kennt, ist damit inder Lage, Transaktionen aufdem SAP-Server auszulösenoder in einem zweiten SchrittFehler in den somit erreichba-ren SAP-RFCs auszunutzen und

den SAP-Server selbst unterseine Kontrolle zu bringen.

Etwas komplizierter ist derhäufig genannte SQL-Injection-Angriff. Er kann Webapplikatio-nen betreffen, die Daten in einerSQL-Datenbank speichern oderauf Daten einer bestehendenSQL-Datenbank zugreifen. Bei-spielsweise könnte eine Webap-plikation Produktinformationenaus einer Datenbank abrufenund anzeigen, nachdem der An-wender die Artikelnummer desgewünschten Produkts eingege-ben hat. Der zum Abfragen derDatenbank benötigte SQL-Be-fehl ließe sich dafür aus einemfesten Teil und der eingegebe-nen Artikelnummer zusammen-bauen. Zum Beispiel könnte derProgrammierer den festen Textselect name, beschreibung,preis from artikel where artno = ' mit der vom Benutzereingegebenen Nummer undeinem abschließenden Hoch-komma zusammenfügen.

SQL Injection nachSchema FEin Angreifer macht sich diesesharmlose Programmkonstruktzunutze und gibt anstelle einerArtikelnummer beispielsweisefolgenden Text ein: ' union se-lect name, password, null fromshopusers --. Das erste Hoch-komma terminiert den zu suchenden Text aus dem ur-sprünglichen SQL-Befehl underweitert diesen dann mit demUnion-Schlüsselwort, das zweiSelect-Befehle miteinander ver-bindet. Der sich daraus erge-bende Befehl, der an die Daten-bank gesendet wird, lautet: se-lect name, beschreibung, preisfrom artikel where artno = ''union select name, password,null from shopusers -- . Diebeiden Bindestriche am Endeder Eingabe sorgen dafür, dassder folgende Text als Kom-mentar interpretiert wird unddamit keinen Syntaxfehlerauslösen kann. Der Angreiferwürde in diesem BeispielNamen und Kennwörter von

anderen Benutzern aus der Da-tenbank angezeigt bekommen.

Dieses vereinfachte Beispielgeht davon aus, dass der An-greifer bereits weiß, dass eseine interessante Tabelle mitNamen shopusers gibt. Auchweiß er, welche Spalten die Ta-belle enthält. In der Praxismüsste er dies erst herausfin-den. Das bereitet jedoch keinegrößeren Schwierigkeiten, denndie vorhandenen Tabellen undihre Spaltennamen stehen inbekannten Systemtabellen be-ziehungsweise in Views, dieman ebenfalls abfragen kann.Bei Microsoft SQL gibt es dafürbeispielsweise Views wiesys.objects oder sys.tables.

Ein Angriff per SQL Injectionist damit meist ein Vorgang inmehreren Schritten. Im erstenSchritt identifiziert der AngreiferEingabefelder oder andere Parameter, die für eine Daten-bankabfrage verwendet wer-den. Im zweiten Schritt ermittelter durch Ausprobieren dieStruktur des benutzten SQL-Befehls und die Anzahl der ab-gefragten Spalten und danachfragt er schrittweise Systemta-bellen und Benutzertabellen ab.Selbstverständlich beschränktsich SQL Injection nicht nur aufdas Auslesen von möglicher-weise vertraulichen Daten. Ge-nauso kann ein Angreifer imletzten Schritt auch Daten in derDatenbank manipulieren. Des

Weiteren ist es gelegentlichsogar möglich, aus dem SQL-Server auszubrechen und dieKontrolle über das Betriebssys-tem des Datenbankservers zuerlangen. Stored Procedureswie XP_CMDSHELL, die wie Microsofts SQL Befehle an dasBetriebssystem übergeben, er-möglichen das.

Erschwerend kommt hinzu,dass der erste Schritt zur Iden-tifikation von möglichen An-satzpunkten nicht nur einfachist, sondern sich auch sehr gutautomatisieren lässt. Webappli-kations-Scanner nutzen dasaus, um Schwachstellen auf-zuspüren. WebInspect von HP(früher SPI-Dynamics) oderAppScan von IBM (ehemalsWatchfire) durchlaufen wie eineSuchmaschine eine Webappli-kation und geben unter ande-rem in jedes mögliche Einga-befeld Anführungszeichen,doppelte Bindestriche oder an-dere geeignete Sonderzeichenein, um damit eine Fehlermel-dung der zu prüfenden Applika-tion zu provozieren. Falls siedabei an eine einfache SQL-In-jection-Schwachstelle geraten,zeigt die zu prüfende Applika-tion einen internen Fehler odersogar eine Datenbank-Fehler-meldung an.

Daraus lässt sich schließen,dass die Eingabe des Sonder-zeichens nicht einfach alsSuchbegriff verwendet wurde,

II iX extra 11/2007

IT-Security

LAN

Internet

Angreifer

klassische Angriffeauf das Betriebssystem

bösartige Inhalte in Daten(URLs, Form contents, cookies)HTTP / Port 80

Webserver

Angriffe aufCGI, PHP,Servlets

Angriffe aufden Server-

prozess

Angriffe auf Web-applikationen könnenklassische Firewalls nichtabwehren, denn sie er-folgen über erlaubteWege, etwa Formular-eingaben auf Webseitenet cetera (Abb. 1).

ix.1107.x.1-16 27.09.2007 12:13 Uhr Seite II

www.artofdefence.com

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-Anwendungendank Mandantenfähigkeit

behält den Überblick: Einfache Administration im laufenden Betrieb dank grafischer Oberfläche und Lernmodus

ix1107_x_000_ArtOfDefence.indd 1ix1107_x_000_ArtOfDefence.indd 1 28.09.2007 13:08:43 Uhr28.09.2007 13:08:43 Uhrix1107_x_03_ArtOfDefence.pdf 1ix1107_x_03_ArtOfDefence.pdf 1 04.10.2007 15:29:57 Uhr04.10.2007 15:29:57 Uhr

sondern die SQL-Syntax derBackend-Abfrage verändert hat.Enthält das bereits beschriebe-ne Beispiel nur ein einfachesAnführungszeichen, so ergibtsich der folgende SQL-Befehl:select name, beschreibung,preis from artikel where artno = ''' . Da drei aufeinanderfol-gende einfache Anführungszei-chen keine gültige SQL-Syntaxdarstellen, erzeugt die betroffe-ne Webapplikation einen Fehler.

Die automatisierte Suchenach Schwachstellen in Webap-plikationen durch Provozierenvon Fehlermeldungen erscheintauf den ersten Blick relativ ein-fach. In der Praxis gibt es jedochviele Webshops oder Portale miteiner komplizierten Session-Ver-waltung, sodass schon das voll-ständig automatisierte Durch-laufen aller Seiten mit einemCrawler alles andere als trivialist. Dies ist wohl einer der Grün-de dafür, dass es bisher nur we-nige kommerzielle Prüfwerkzeu-ge und im Open-Source-Umfeldbisher keine vergleichbaren Pro-dukte gibt.

Keine Änderung zurLaufzeitEs existieren mehrere Ansätze,die eine SQL Injection verhin-dern sollen. Die beste Methodebesteht jedoch darin, im Allge-meinen sogenannte PreparedStatements für SQL-Befehle zuverwenden. Damit kann manauf die Textverkettung zum Zu-sammenbauen von SQL-Befeh-len verzichten und eine Ände-rung der Befehle zur Laufzeit istnicht mehr möglich.

Die sicherlich am häufigs-ten vorhandene und dennocham wenigsten verstandeneSchwachstelle nennt sichCross-Site Scripting oder abge-kürzt XSS. Dabei wird nicht dieApplikation selbst sondern derBrowser eines anderen Anwen-ders über eine Schwachstelle in der Applikation angegriffen.Grundlage dafür ist Skript-Code,zumeist Javascript, der einemAnwender wie ein Teil der Web-

site angezeigt und dabei vomBrowser des Anwenders inter-pretiert wird. Die Auswirkungenreichen vom Vortäuschen vonSeiteninhalten über das Stehlenvon Zugangsdaten oder Ses-sion-IDs bis hin zur Kontroll-übernahme des Browsers durcheinen Angreifer.

Die verwundbare Webappli-kation, die den Angriff auf ah-nungslose Anwender ermöglicht,ist zunächst nur ein Vermittler.Erst wenn ein Angreifer dieSession-ID eines anderen legi-timen und authentifizierten Be-nutzers per XSS stiehlt, kann erin einem zweiten Schritt aufBereiche der Applikation zu-greifen, die eigentlich nur fürauthentifizierte Benutzer er-reichbar sind. Damit wird XSSzu einer Schwachstelle, mit derman auch starke Authentifizie-rung und Zugriffsbeschränkun-gen bei einer Webapplikationumgehen kann.

In der trivialsten, aber eherseltenen Form von XSS bietetdie Applikation dem Anwendereine Eingabemöglichkeit wie beieinem Gästebuch. Er kann Texteingeben, der auf dem Servergespeichert wird und den ande-re Benutzer später wieder an-gezeigt bekommen. Ist es beidieser Texteingabe möglich,HTML-Tags und vor allem das<script>-Tag einzugeben, kannein Benutzer Javascript-Codezwischen <script> und</script> in seinem Text ein-betten. Jeder Benutzer, der denText später ansieht, erhieltedann nicht die Tags und denCode angezeigt, sondern seinBrowser würde den Javascript-Code ausführen. Man sprichtdeshalb von persistentem XSSoder auch stored XSS.

Sehr viel häufiger kommtnicht persistentes XSS vor. Da-bei speichert die Applikationden Skript-Code nicht, sonderndiesen muss das Opfer unbe-merkt selbst als Parameter aneinen Link übergeben. Der An-greifer benötigt dazu beispiels-weise ein Eingabefeld odereinen URL-Parameter, der in

einer Folgeseite ungefiltert wie-der ausgegeben wird. Dasklassische Beispiel hierfür sindSuchfunktionen innerhalb vonWebseiten, bei denen der Be-nutzer einen Suchbegriff wie„XYZ“ eingeben kann und dieWebsite danach die Ergebnissemit dem Hinweis „Ihre Suchenach XYZ ergab folgende Tref-fer“ beantwortet.

Das Opfer als Täter

Da man solche Suchmaskennicht von Hand ausfüllenmuss, sondern auch der direk-te Aufruf des Skripts mit demSuchbegriff als URL-Parametermöglich ist, könnte ein Angrei-fer einen Link auf die Suchsei-te mit Javascript zwischen<script> und </script> als Parameter verwenden. DiesenLink schickt er in einer ge-spooften Mail an ahnungsloseBenutzer der Website, diedann beim Klick auf den Linkzwar auf der echten Websitelanden, dabei aber den Java-script-Code zurückbekommen.Selbst vorsichtige Benutzer,die vor dem Klicken auf einenLink nachsehen, auf welchenServer der Link wirklich ver-weist, würden erkennen, dassder Link auf den echten Serverzeigt. Der angehängte Skript-Code kann durch geschickteSchreibweise unauffällig ge-macht werden.

Zum Erkennen von XSS bie-ten sich die genannten Web-applikations-Scanner an. Beiihrem Einsatz versucht die Soft-ware jedoch nicht, Fehlermel-dungen zu provozieren. Statt-dessen setzt sie automatischText zwischen Tags wie<script> und </script> in alleEingabefelder und Parameterund prüft danach, ob die Einga-be ungefiltert in einer Ausgabe-seite wieder auftaucht. Entspre-chend einfach ließe sich XSSverhindern. Entweder bei derEingabeverarbeitung oder derAufbereitung von Ausgabeseitenoder im Idealfall sogar an bei-den Stellen müsste Textfilterung

verhindern, dass entsprechen-de Tags in Eingaben oder Pa-rametern vorkommen. Da diesin der Praxis jedoch nicht soeinfach umzusetzen ist oderimmer wieder Parameter ver-gessen werden, geht derTrend heute zu zusätzlichemSchutz durch Web ApplicationFirewalls.

In letzter Zeit bauen immermehr Serverbetreiber asynchro-ne Funktionen mit Ajax oder mit Techniken, die unter demSchlagwort Web 2.0 laufen, inihre Webapplikationen ein. Na-turgemäß stellt sich die Frage,welche Auswirkungen dieseneuen Funktionen auf die Si-cherheit haben. Dabei ist rechtschnell festzustellen, dass dieAngriffsmethoden eigentlichgleich bleiben, dass jedoch dieMöglichkeiten, Fehler zu ma-chen, zunehmen. Prinzipielllässt sich feststellen, dassdurch Ajax beziehungsweiseWeb-2.0-Techniken zusätz-liche Funktionen auf den Clientverlagert werden, wodurchauch ein Angreifer mehr Ein-fluss auf den Ablauf nehmenkann. Die Angriffsfläche wirdalso größer.

So gibt es beispielsweiseApplikationen, die wie bisherauf SQL-Datenbanken im Back-end zugreifen, die jedoch jetztdie SQL-Abfragen auf demClient zusammenbauen undasynchron an den Server sen-den. Dabei sollte auf den erstenBlick klar sein, dass das keinegute Idee ist. Ein Angreiferkann jetzt so tun, als sei er einClient und direkt SQL-Befehlean den Server senden, ohnesich um die Tricks und Kniffevon SQL Injection kümmern zumüssen. Einfacher kann manes einem Angreifer fast nichtmachen. In diesem Fall handeltes sich nicht mehr um SQL In-jection, sondern bereits um„SQL Invitation“. (sf/ur)

Stefan Strobelist Buchautor und

Geschäftsführer des HeilbronnerBeratungsunternehmens

Cirosec.

IV iX extra 11/2007

IT-Security

ix.1107.x.1-16 27.09.2007 12:13 Uhr Seite IV

SUPERBLADETM

GET THE EDGE

Weitere Informationen über unsere Produkte unter:www.cpigmbh.de und Hotline 0800-100 82 69

CPI Computer Partner Handels GmbHKapellenstr. 11D-85622 FeldkirchenTelefon: (+49)-0 89/96 24 41-0Telefax: (+49)-0 89/96 24 41-33

Alle Marken- und Produktbezeichnungen sind Warenzeichen oder eingetrageneWarenzeichen des entsprechenden Unternehmens. Druckfehler, Irrtümer undÄnderungen vorbehalten.

■ Performance mit bis zu 160 Cores in 7 HE■ Einsatz von Intel® Xeon® oder AMD Opteron®

Dual- oder QuadCore Prozessoren■ Netzteile mit 90%+ Wirkungsgrad■ Weniger Verkabelung■ Ethernet- und Infiniband-Switches■ Sehr gutes Preis-/Leistungsverhältnis

Der SuperBlade™ sind optimiert für folgendeAnwendungen: Enterprise, Finanzdienste,Datenbanken, Datenbank Center, wissenschaftlicheAnwendungen, HPC, Personal Super Computer.

ServerBlade mit 3.5"oder 2.5" Festplatten

Infiniband Switch mit10 externen Anschlüssen

Gigabit Ethernet Switch mit10 externen Anschlüssen

Management Modulzur Überwachung

© w

ww

.artr

actio

n.de

, 06/

07

ix0707_x_000_CPI.indd 1ix0707_x_000_CPI.indd 1 08.06.2007 12:24:25 Uhr08.06.2007 12:24:25 Uhrix1107_x_05_CPI_WH.pdf 1ix1107_x_05_CPI_WH.pdf 1 04.10.2007 15:29:50 Uhr04.10.2007 15:29:50 Uhr

So technisch unterschiedlichdie Angriffe auf Weban-

wendungen wie Forceful Brow-sing, SQL Injection, Cross-SiteScripting oder Parametermani-pulation auch sein mögen – siewerden alle über das HTTP(S)-Protokoll zum Webserver bezie-hungsweise zur Webanwendungtransportiert. Herkömmliche Pa-ketfilter, die heute zum Teilnoch als einzige Schutzmaßnah-me vor dem Webserver stehen,erkennen solche Angriffe aufAnwendungsebene nicht, dennsie sind nicht in der Lage, in die über das HTTP-Protokollübertragenen Inhalte hineinzu-schauen. Auch das regelmäßigePatchen des Webservers schütztleider nicht gegen diese Art vonAngriffen.

Die Ursachen für dieSchwachstellen, die diese Artvon Attacken auf der Anwen-dungsebene erst möglich ma-chen, sind fast immer Program-mier- oder Designfehler bei derEntwicklung der Webanwen-dung. Nichts erscheint also naheliegender als sicher zu programmieren, um so dieSchwachstellen von vornhereinzu vermeiden. Dazu gehört zumBeispiel, dass sämtliche Daten,die an die Anwendung weiterge-geben werden, auf „bösartige“Inhalte überprüft werden. Aufdiese Weise lassen sich etwaSQL- oder Command-Injection-Angriffe erkennen. Um Parame-termanipulationen aufzuspüren,muss man die Daten zusätzlichauf Gültigkeit bezüglich ihresaktuellen Kontextes prüfen.

Leider erfordert die sichereProgrammierung ein umfassen-des und stets aktuelles Know-how des Entwicklers im Bereichder Angriffstechniken auf derAnwendungsebene. Die Ent-wicklung eines Filters zur Er-kennung bösartiger Benutzer-eingaben ist komplex und aufwendig, denn schließlichmuss man alle Angriffsarten inallen Ausprägungen berücksich-tigen – auch dann, wenn sie inkodierter Form vorliegen. Gleich-zeitig muss die Anwendung wei-ter funktionieren. Der Auftrag-geber einer Webanwendung hat sicherlich kein Verständnisdafür, wenn ein Anwender in ein Namensfeld zum BeispielO’Brian eingibt und die HTTP-Anfrage aufgrund des Hochkom-mas wegen Verdachts auf SQLInjection verworfen wird.

Kein Einfluss aufFremdcode Darüber hinaus stellt die sichereProgrammierung keine vollstän-dige Lösung des Problems dar.Selbst eine optimal program-mierte Webanwendung istimmer noch angreifbar. DerGrund dafür liegt darin, dass bei einer Webanwendung stetsFremdcode zur Ausführungkommt, auf dessen Qualität derEntwickler keinen Einfluss hat.Beispiele für diese Art vonFremdcode sind Programm-bibliotheken Dritter, die man in den eigenen Code einbindet,oder die eingesetzten Web- undApplikationsserverprodukte, bei

denen regelmäßig kritischeSchwachstellen bekannt wer-den. Außerdem sind die heuti-gen Webanwendungen häufigselbst Drittprodukte, beispiels-weise Portalanwendungen oderWebzugriffslösungen für E-Mail.

Aus diesen Gründen emp-fiehlt es sich für Unternehmenund Behörden, ihre Webanwen-dungen durch den Einsatz soge-nannter Web Application Fire-walls (kurz WAF) vor Angriffenzu schützen. Eine WAF steht vorder Webapplikation (siehe Ab-bildung 1) und prüft jede HTTP-Anfrage des Anwenders (oderAngreifers), bevor sie zur An-wendung gelangt. Erkennt siebei der Prüfung einen Angriff,beispielsweise eine manipulierteSession-ID oder einen Betriebs-systembefehl in einem Formu-larfeld (Command Injection), lei-tet sie die Daten nicht weiter,sondern erzeugt einen Protokoll-eintrag und liefert eine Fehler-seite an den Anwender aus.

Web Application Firewallssind meist als Reverse Proxy inein Netzwerk integriert. Dasheißt, sie nehmen stellvertre-tend für den Webserver jedeHTTP-Anfrage des Anwendersentgegen, untersuchen sie in-haltlich und bauen dann eineneue, zweite HTTP-Verbindungzum von ihnen geschütztenWebserver auf. Der Anwendermerkt nicht, dass er nicht mitdem Webserver direkt kommu-

niziert. Die meisten WAF-Pro-dukte lassen sich alternativauch als Bridge ins Netzwerkintegrieren, ähnlich wie einnetzwerkbasiertes Intrusion-Prevention-System. Im Falledieser Integrationsvariantespricht der Anwender weiterhindirekt mit dem Webserver; dieWAF sitzt aber im Datenstromund holt sich die HTTP-Paketeheraus, um die darin enthalte-nen Daten inhaltlich zu prüfen.

Für geschäftskritische An-wendungen, die meistens aufsensible Backend-Systeme wieSAPs R/3 oder Datenbanken iminternen Netzwerk zugreifenmüssen, ist der Einsatz einerWAF besonders wichtig. Aller-dings kommunizieren in solchenFällen Anwender und Webservertypischerweise verschlüsseltüber SSL. Damit ist jedoch dieinhaltliche Analyse des Daten-stroms zunächst unmöglich.WAF-Produkte bieten jedoch dieMöglichkeit, SSL zu terminieren(Reverse Proxy) beziehungs-weise passiv zu entschlüsseln(Bridge). Aufgrund ihrer Archi-tektur sind moderne Systeme soleistungsfähig, dass durch dieEntschlüsselung keine spür-baren Performance-Einbußenentstehen. Die Praxis zeigtübrigens, dass fast immer dieWebanwendung mit ihren vielenTransaktionen den Flaschenhalsbildet und nicht die Verarbeitungdurch die WAF.

VI iX extra 11/2007

IT-Security

Die TürsteherFirewalls für Webanwendungen

Das erste Gebot für die Sicherheit von Webanwen-dungen ist eine sorgfältige Programmierung, dieSchwachstellen vermeidet. Doch selbst dann bleibendie Applikationen angreifbar und müssen zusätzlich miteiner Web Application Firewall geschützt werden.

AngreiferWebanwendung 3

WAF

Webanwendung 1Webanwendung 2

Webanwendung n

Da auch bei sorgfältiger ProgrammierungAngriffsmöglichkeiten auf Webanwendungenbestehen, sollte man sie mit einer vorge-schalteten Web Application Firewall, die alleHTTP-Anfragen prüft, schützen (Abb. 1).

ix.1107.x.1-16 27.09.2007 12:13 Uhr Seite VI

ix1107_x_000_datsec.indd 1ix1107_x_000_datsec.indd 1 01.10.2007 16:34:14 Uhr01.10.2007 16:34:14 Uhrix1107_x_07_datsec.indd.pdf 1ix1107_x_07_datsec.indd.pdf 1 04.10.2007 15:29:46 Uhr04.10.2007 15:29:46 Uhr

Der Schutzmechanismuseiner Web Application Firewallberuht auf ihrem Verständnisder von ihr geschützten Weban-wendungen mit ihren einzelnenSeiten, Eingabefeldern, Cookiesund Statuswerten. All dies befä-higt sie, die aufgerufenen URLssowie die Parameter in GET-und POST-Requests zu kontrol-lieren und dabei Angriffe zu er-kennen und zu blockieren.Woher weiß aber die Firewall,welche URLs zur Webanwen-dung gehören, ob Benutzerein-gaben gutartig sind oder obbeispielsweise eine Session-IDmanipuliert wurde?

Kontrolle deraufgerufenen URLsEine WAF muss gewährleisten,dass nur URLs aufgerufen wer-den können, die zur Anwendunggehören. Der Zugriff auf alle an-deren Ressourcen, die sichunterhalb der Webserver-Wurzelbefinden, zum Beispiel DLLs,alte Dateiversionen (.old, .bak,et cetera) oder gar andere,interne Webanwendungen mussverhindert werden. Allein durchdiese Kontrolle der URL-Aufrufelässt sich bereits ein großer Teildes Angriffspotenzials vomWebserver fernhalten. Durchden Whitelist-Ansatz sind nurnoch die URLs aufrufbar, die zurAnwendung gehören, alle ande-ren Zugriffe sind damit automa-tisch verboten.

Es stellt sich die Frage, wieeine WAF unterscheiden kann,welche URLs zur Anwendunggehören und welche nicht. Dieam Markt verfügbaren Produktenutzen im Wesentlichen zweiTechniken für das Lernen der er-laubten URLs: dynamisches Ler-nen zur Laufzeit sowie statischesvor Aktivierung der WAF-Policy.

Verwendet die WAF dieTechnik des dynamischen Ler-nens, so „merkt“ sie sich die er-laubten URLs automatisch zurLaufzeit, also während der An-wender surft, durch Analyse dervom Webserver an den Anwen-der gesendeten Webseiten. ImIdealfall muss der Administratornur einmal die gewünschtenEinstiegsseiten der Webanwen-dung als erlaubte URLs definie-ren. Anschließend sucht dieWAF zur Laufzeit aus jeder an-geforderten Seite die im HTML-Code enthaltenen Links (<a href…>) und Formular-Aktionen(<form action …>) und fügt sieautomatisch einer Liste der fürdiesen Anwender erlaubtenURLs hinzu (siehe Abbildung 2).Beim dynamischen Lernen kannder Anwender also stets nur diebis zum jeweiligen Zeitpunkt ge-lernten URLs aufrufen. Es giltdas Motto: Alles was verlinkt ist,gehört zur Anwendung und darfdaher aufgerufen werden.

In der Regel verwaltet einedynamisch lernende WAF fürjeden Anwender eine individuelledynamische Policy, die die meis-

ten Produkte im Hauptspeicherpflegen. Um die HTTP-Anfrageeines Anwenders „seiner“ Policyzuzuordnen, stellt die WAF einanwenderspezifisches Cookieaus, das der Browser des An-wenders bei jeder HTTP-Anfragewieder mit zurückschickt unddas die WAF anschließend aus-wertet. Die Webanwendung be-kommt von alledem nichts mit.Nach Ablauf eines frei definier-baren Timeouts, nach dem dieWAF vom Anwender keineHTTP-Anfrage mehr gesehenhat, wird die dynamische Policyfür diesen Anwender gelöscht.Beim nächsten Mal muss erbeim Aufruf der Anwendungwieder über die definiertenStartseiten einsteigen.

Statisches versusdynamisches LernenBeim statischen Lernen hinge-gen definiert der Administratoralle erlaubten URLs im Vorfeld,also vor Produktivschaltung derWAF-Policy. Was zunächst alsaufwendig zu konfigurierenklingt, erweist sich in der Praxisjedoch als recht einfach und isthäufig sogar die bevorzugteLernmethode: Die meisten WAF-Produkte unterstützen die Ver-wendung von Wildcards odergar von regulären Ausdrückenbei der Definition der URLs (bei-spielsweise /[a-z].html) undbeinhalten vor allem einen Lern-modus. Dieser zeichnet für eine

bestimmte Zeit alle URLs auf,die von einer vertrauenswürdi-gen IP-Adresse angefordertwerden. Unter Verwendungeines Crawlers, der ausgehendvon der Startseite alle Linksautomatisch verfolgt, lässt sichsehr schnell eine kompletteListe aller URLs aufzeichnen.

Das dynamische Lernen zurLaufzeit erscheint im Vergleichzum statischen Lernen im ers-ten Augenblick als die elegante-re Lernmethode, müssen dochnur einmalig die gültigen Start-seiten definiert werden, undalles Weitere lernt die WAFautomatisch. In der Praxis lässtsich das dynamische Lernenaus zwei Gründen jedoch leidernicht immer anwenden.

Zum einen gibt es viele Webanwendungen, typischer-weise Nachrichtenseiten wiewww.heise.de, bei denen jedeSeite eine gültige Startseite seinkann. Bei solchen inhalteorien-tierten Webanwendungen müss-te der Administrator in der WAFjede Seite – und davon existie-ren meist sehr viele – als gültigeStartseite hinterlegen, sodassletzten Endes eine statische Po-licy entsteht. Für andere Artenvon Webanwendungen, bei-spielsweise bei workfloworien-tierten E-Business-Anwendun-gen, eignet sich der dynamischeAnsatz hingegen optimal: Hierist es meist ausdrücklich ge-wünscht, dass der Anwendervon einer definierten Startseiteaus anfängt und sich von dortSeite für Seite durch die Anwen-dung durcharbeitet.

Eine weiteres K.o.-Kriteriumfür die Nutzung des dynami-schen Lernmodus kann die ex-tensive Verwendung von Java-script im HTML-Code der Anwendung sein. Javascript istfür eine WAF so lange kein Pro-blem, wie der Javascript-Codebeispielsweise Plausibilitätsprü-fungen bei Eingaben in ein For-mularfeld vornimmt, etwa prüft,ob in ein Postleitzahlenfeldgenau fünf Ziffern eingegebenwurden. Sobald Javascript aberauch dazu eingesetzt wird, auf

VIII iX extra 11/2007

IT-Security

Anwender Webserver

GET /

Startseite: / start.htmlCookie: Session 1357

GET /msadc/msadcs.dll

1a

2c

3a

GET /

Startseite: / start.html

1b

2a

WAF

Session 1357 Links:/products/index.html/services/index.html/cgi/feedback.pl

2b

Dynamisches Lernen zur Laufzeit: Die WAF analysiert nach dem Aufrufen einer erlaubtenStartseite (1a, 1b) alle vom Webserver zurückgelieferten Webseiten (2a) und fügt deren URLsder dynamischen Policy hinzu (2c). Nicht gelernte URLs blockiert sie (3a) (Abb. 2).

ix.1107.x.1-16 27.09.2007 12:13 Uhr Seite VIII

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.

Warum vertrauen mehr als 1 Million Kunden unseren Microsoft® SQL Server™ Lösungen?

Die maßgeschneiderte LösungDell™ und Microsoft® arbeiten eng zusammen, um Ihrem Unternehmen eine perfekt integrierte, vorkonfi gurierte 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.

Sie benötigen weitere Informationen zu unseren Datenbank-Lösungen?

Besuchen Sie uns unter www.dell.de/sql

Beginnen Sie jetzt! Wenden Sie sich an unsere Kundenbetreuer, die Ihnen gerne Ihre individuelle IT-Lösung zusammenstellen.0800 / 2 17 33 55Mo - Fr 8 - 19 Uhr, Sa 10 - 16 UhrBundesweit zum Nulltarif

60802_IX Extra Beihefter_200x2801 160802_IX Extra Beihefter_200x2801 1 21/09/2007 12:18:3621/09/2007 12:18:36ix1107_x_09_Dell.pdf 1ix1107_x_09_Dell.pdf 1 04.10.2007 15:29:53 Uhr04.10.2007 15:29:53 Uhr

dem Client zur Laufzeit die inder Seite verlinkten URLs zu-sammenzusetzen, kommt esunter Umständen zu Schwierig-keiten. Um solche URLs dyna-misch zu lernen, müsste dieWAF nämlich in der Lage sein,Javascript zu analysieren, damitsie die URLs berechnen kann.Das ist ohne Weiteres machbar,falls die URL im Skript-Code alsGanzes enthalten ist. Wird siehingegen zum Beispiel mitString-Verkettungen „zusam-mengebastelt“, eventuell sogarnoch unter Verwendung von Va-riablen, ist die WAF nicht mehrin der Lage, die daraus resultie-rende URL zu berechnen. In sol-chen Fällen, wie sie manchmalbei Navigationsleisten anzutref-fen sind, muss der Administratordie URLs analog zur Einstiegs-seite als statische Ausnahme-regel in der WAF konfigurieren.

In der Praxis wird aufgrundder beschriebenen möglichenSeiteneffekte des dynamischenLernens daher häufig eine sta-tische WAF-Policy definiert unddas dynamische Lernen nur fürdas Lernen von Formular-Ak-tionen aktiviert, aber nicht fürdas Lernen der sonstigen ver-linkten URLs.

ÜbermittelteParameter überprüfenDas größte Angriffspotenzial aufWebanwendungen besteht in In-jection-Angriffen (SQL Injection,Command Injection, Cross-SiteScripting et cetera), bei denender Angreifer die jeweilige An-griffssyntax in die Felder vonWebformularen eingibt, sowie inder Manipulation der Werte von„Read-Only“-Parametern wieSession-IDs, Hidden-Feldernoder Auswahlmöglichkeiten beiRadio Buttons in Webformularen.

Eine zentrale Aufgabe einerWAF ist daher die Kontrolle allerParameter, die in den HTTP-An-fragen an die Webanwendungübermittelt werden. Im Fall derRead-Only-Parameter muss siegewährleisten, dass der Anwen-der die Werte nicht verändert

hat, beispielsweise dass dieSession-ID nicht von 123456 auf123457 geändert wurde. Um In-jection-Angriffen vorzubeugen,muss die Firewall alle Benutzer-eingaben in Webformularensowie alle sonstigen Parameterhinsichtlich ihres Wertebereichsüberprüfen. Zusätzlich muss siedie Länge der Parameterwertekontrollieren, um der Ausnut-zung etwaiger Pufferüberlauf-Schwachstellen vorzubeugen.

Fast alle WAF-Produkte bie-ten die Möglichkeit, Wert undLänge jedes einzelnen Parame-ters der Webanwendung indivi-duell zu konfigurieren. In derPraxis ist diese Vorgehensweisejedoch selbst bei einer kleinenAnwendung, die unter Umstän-den auch noch häufig geändertwird, nicht mit einem vertret-baren Konfigurationsaufwand zubetreiben. Aus diesem Grundaktivieren Anwender stattdessenmeist die auf Blacklists basie-renden Filtermodule der Fire-wall, die bei guten Produkten füralle Arten von Injection-Angriffen

mitgeliefert werden. Dieschwarzen Listen enthaltenkeine primitiven Muster wie ein<script>-Tag (Cross-Site Scrip-ting) oder ein Hochkomma (SQLInjection), sondern echte An-griffssyntax, zum Beispiel „SQL-Sonderzeichen gefolgt voneinem SQL-Befehl“. Auf dieseWeise sind bei einer WAF imGegensatz zu Technologien wieIntrusion-Detection-/Intrusion-Prevention-Systemen kaumFalse Positives zu beobachten.

Die Blacklist-basierten Über-prüfungen erfolgen standardmä-ßig für alle Parameter einer An-wendung. Das heißt, es bestehtkeine Notwendigkeit, einzelneParameter zu konfigurieren. Beieinem guten Produkt ist es frei-lich möglich, einzelne Felderoder Formulare von der Über-prüfung auszunehmen undstattdessen etwa den Wertebe-reich des Parameters in Formeiner Whitelist zu konfigurieren.

Neben der Kontrolle der Be-nutzereingaben muss die Inte-grität der Read-Only-Parameter

gewährleistet sein. Hierfür ist eserforderlich, dass die WAF dieBenutzer-Session zur Laufzeitverfolgt und sich den Wert einesRead-Only-Parameters merkt,sobald dieser das erste Mal anden Anwender übermittelt wird.Dabei kommt wieder das obenbeschriebene Konzept des dy-namischen Lernens zur Laufzeitzur Anwendung: Aus den HTML-Seiten, die der Webserver anden Anwender ausliefert, „extra-hiert“ die WAF nicht nur die verlinkten URLs (Suche nach <a href …>), sondern auch diedarin enthaltenen Read-Only-Parameter, also beispielsweisedie Auswahlmöglichkeiten beieinem Radio Button (Suche nach<input type=radio …>). Bei dennachfolgenden HTTP-Anfragen,in denen die Parameter wiederübermittelt werden, prüft dieWAF dann, ob die Werte nochdieselben sind. (ur)

Steffen Gundel ist Mitgründer der cirosec GmbH

in Heilbronn und Experte imBereich Applikationssicherheit.

X iX extra 11/2007

IT-Security

WEB APPLICATION FIREWALLS UNDSCHWACHSTELLENSCANNER

Die Übersicht erhebt keinen Anspruch auf Vollständigkeit.

Hersteller Produkt WebsiteWeb Application Firewalls

art of defence hyperguard www.artofdefence.comBreach WebDefend/ModSecurity www.breach.comCisco AVS 3100 Application Velocity System www.cisco.comCitrix Citrix Application Firewall www.citrix.comDenyAll rWeb www.denyall.comF5 TrafficShield, Magnifier www.f5.comImperva SecureSphere www.imperva.comNetContinuum NC-1100, NC-2000 www.netcontinuum.comProtegrity Defiance TMS www.protegrity.comUnited Security Providers Secure Entry Server www.united-security-providers.chVisonys Airlock www.visonys.comWebschwachstellen-Scanner

Acunetix Acunetix www.acunetix.deCenzic Hailstorm www.cenzic.comHP WebInspect www.hp.comIBM Appscan www.watchfire.comMayflower Chorizo-Scanner https://chorizo-scanner.comN-Stalker N-Stalker www.nstalker.comSyhunt Sandcat www.syhunt.com

ix.1107.x.1-16.neu2.EP 10.10.2007 11:59 Uhr Seite X

iX extra 11/2007

Standardsoftware oder auchsonst weit verbreitete Anwen-dungen werden in regelmäßi-gen Abständen auf Sicherheits-probleme untersucht. Denn dienegative Publicity durch dieVeröffentlichung einer entdeck-ten Lücke ist alles andere alsein erwünschter Werbeeffekt.Hinzu kommt, dass sich die aufdiese Weise gefundenen Ex-ploits auf dem Markt direktversilbern lassen. Webapplika-tionen aber sind in vielen Fäl-len Eigenentwicklungen undfinden in diesem Prozesskaum Beachtung. Deswegengibt es kaum eine Webanwen-dung, in der der Interessiertekeine Fehler beziehungsweiseSchwachstellen findet. Umsowichtiger ist es, diese Anwen-dungen mit Scannern zuuntersuchen. Diese reichen je-doch nicht aus, um alle Fehlerzu finden. Deshalb sollte manergänzend Penetrationstestsdurchführen.

Schwachstellen-Penetra-tionstestern bieten sich einigeWerkzeuge zur Automatisie-rung ihrer Aktionen an. DieseTools sind hervorragend fürdie Vereinfachung des erstenSchritts dieser Aufgabe ge-eignet, doch die wirkliche

Überprüfung muss immer inHandarbeit erfolgen.

Ziel einer solchen Überprü-fung ist es, die Sicherheit inder Kommunikation zwischender Oberfläche der Anwen-dung und dem Server im Back-end zu gewährleisten. JedeAnwendung bietet dem Benut-zer eine Oberfläche, die sichals HTML-Format darstellt,aber im Hintergrund mit unter-schiedlichen Techniken mitdem Server kommuniziert. Inder einfacheren Welt vor vie-len Jahren wurde diese Kom-munikation über das CommonGateway Interface (CGI) abge-wickelt. Es galten unkompli-zierte Regeln, jeden Mausklicksetzte der Browser in einenRequest um und übertrug dieDaten per POST oder GET.Dank neuer Techniken wie Javascript, Ajax, Webservicesund Flash wird dem Browserdie früher nur im Server ent-haltene API präsentiert. DieseTatsache macht das Testennicht einfacher, aber wenigs-tens interessanter.

Bei einem Penetrationstesthat der Tester die Aufgabe,unabhängig von der vorhan-denen Technik die übertrage-nen Daten so zu verändern,

IT-Security

GekonnteHandarbeitEinbruchssimulation mit Proxy und Plug-ins

Die größte Gefahr für die Sicherheit vonWebanwendungen liegt in den Lücken, die durchFehler in der Entwicklung zustande kommen. Umdiese aufzudecken, lassen sich Scanner einsetzen.Effizienter noch sind die Penetrationstests, die mithilfevon Proxies oder Browser-Plug-ins, aber vor allem inHandarbeit über fingierte Angriffe die Schwachstellenoffenlegen.

ix.1107.x.1-16 27.09.2007 12:13 Uhr Seite XI

U S V - U N D D C - S Y S T E M E

Kraft. Können.Ausdauer.

Ihre 19“ IT hat hohe Ansprüche.

Die Powerware 9140 USV erfüllt sie.

… m i t S i c h e r h e i t

Kraft 7,5 – 10 kVA saubere, kontinuier-liche Leistung in nur 6 HE

Können Einfachste Installation, Wartungund Management

Ausdauer Sicherer Betrieb schützt Ihrewertvollen IT-Investitionen überviele Jahre hinweg

In Racks mit mittlerer bis hoherLeistungsdichte liefert die Doppel-wandler-USV Powerware 9140höchste Sicherheit – keinen Stress.Mehr unter:

www.powerware.de Tel. +49(0)7841 604-0

epq070778_9140_93x280.qxp 11.09.2007 11:26 Uhr Seite 1

iX extra 11/2007

IT-Security

dass potenzielle Fehler aufge-spürt und ausgenutzt werdenkönnen. Jedes Formular, jedesDatenfeld, auch die verdeck-ten und im Hintergrund vonbeispielsweise Javascript inklusive Ajax übermittelten,nehmen ihren Weg durch dasWorld Wide Web. Dies verein-facht die Aufgabe des Testers,denn alle Daten werden imKlartext übertragen, und dieTechnik zum Abfangen dieserDaten setzt ohnehin schonjedes Unternehmen ein – dennnichts anderes macht einProxy. So ist es naheliegend,auch die Penetrationstestsdurch einen Proxy zu unter-stützen.

Das OWASP (Open Web Application Security Project)bietet den WebScarab an, der

durch seine vielen FunktionenTests gut unterstützt. Diewichtigste Funktion ist diekomplette Aufzeichnung derRequests. So kann der Testerdie Webanwendung einfachbeobachten und eine Listealler genutzten Parameter undder in diesen üblicherweiseübertragenen Daten erstellen.Im nächsten Schritt veränderter diese Daten so, dass derServer Dinge tut, die so vomProgrammierer nicht beab-sichtigt waren.

Proxy als Werkzeug

Eine vom Hacker gewünschteReaktion sind Fehlermeldun-gen, die interne Daten offen-legen. Eine andere ist dieAusführung von Shell- oder

SQL-Code. Details zu denmöglichen Fehlern in Web-applikationen beschreibt derArtikel auf Seite I.

Der Tester kann die Re-quests im Proxy auf zwei Artenverändern. Bei der ersten Me-thode stoppt der Proxy die Re-quests vor der Weiterleitung anden Server. Auf der Oberflächesieht der Tester nun den Re-quest inklusive aller Parameterund deren Daten. Dort kann erjeden angezeigten Wert editie-ren und danach den gesamtenRequest absenden. Der Servererhält den Request, als ob ervom Browser direkt gesendetworden wäre und kann keinenUnterschied feststellen. DerVorteil hierbei besteht darin,dass ein Penetrationstester inden Ablauf einer Session ge-zielt eingreifen kann, wenn erbeispielsweise ein bestimmtesElement eines Vorgangs alsSchwachstelle identifiziert hat,der Server jedoch die Requestsnur in einer bestimmten Rei-henfolge akzeptiert.

WiederholbarkeiterwünschtBei der zweiten Methode nutztder Schwachstellentester diegespeicherten Daten der bereitsgesendeten Requests. DerProxy wiederum stellt die Datenin seiner Oberfläche zur Bear-beitung zur Verfügung. Auch indiesem Fall schickt der Testerden Request mit einem Klickab. Der Unterschied und gleich-zeitig Vorteil dieser Methode inbestimmten Situationen ist dieMöglichkeit, den Vorgang belie-big oft zu wiederholen. Mit derersten Methode lässt sich proKlick im Browser nur ein Re-quest bearbeiten, während mitdieser Methode diese Ein-schränkung fällt, denn derProxy arbeitet autark und istnicht davon abhängig, einenneuen Request vom Browser zuerhalten.

Somit kann der Testerschnell viele Variationen dergeänderten Daten ausprobie-

Manuelle Request-Bearbeitung im WebScarab mit einemzugefügten Header (Abb. 2)

Ein Zugriff auf www.heise.de, aufgezeichnet vom WebScarab.Gut zu sehen die Anfragen an Werbeanbieter und Webseiten-Tracker (Abb. 1)

ix.1107.x.1-16 27.09.2007 12:13 Uhr Seite XII

IT-Sicherheit

Ihr Spezialist fürdie Sicherheit vonWeb-Applikationen

• Sicherheitsüber-

prüfungen / Audits

• Beratung zu Architekturen,

Konzepten und Entwick-

lungsrichtlinien

• Schutz von Web-

Applikationen mit

Web-Applikations-

Firewalls (WAFs)

• Trainings Hacking Extrem Web-Applikationen Lernen Sie die Vorgehensweise der Angreifer sowie bekannte und weniger bekannte Angriffs- techniken 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

Angriffe und Gegenmaßnahmen für Web-Applikationen und E-Business-Systeme In diesem Training werden Angriffsarten auf Web- Applikationen & E-Business- Systeme anhand zahlreicher, praxisnaher Beispiele demon- striert. Am zweiten Tag stellen wir ausführlich innovative Lösungsansätze vor.

20.11. - 21.11.2007 Köln

cirosec GmbHEdisonstraße 2174076 HeilbronnTelefon (0 71 31) 5 94 55-0www.cirosec.de

ren. Der Proxy zeigt ihm dafüreine Antwort vom Server imText- oder HTML-Format an.In dieser Hinsicht lässt sichdas Vorgehen am ehesten mitder Arbeit von Webanwen-dungs-Scannern vergleichen:Auch diese erzeugen Re-quests mit jeweils leicht ver-änderten Daten und schickendiese an den Server, um da-nach die Ergebnisse auszu-werten. WebScarab wie auchdie anderen Penetrationstest-Proxies bieten dementspre-chend einen ähnlichen Funk-tionsumfang wie die Scannerund unterstützen den Testermit Features wie Fuzzing (das Erzeugen von zufälligenDaten, die über Eingabe-schnittstellen eines Pro-gramms verarbeitet werden),Session-ID-Analyse und jenach Produkt auch selbst ge-schriebenen Plug-ins.

Hilfreiche BrowserPlug-insEine dritte Art der Request-Bearbeitung arbeitet mitBrowser-Plug-ins, die es fürden Internet Explorer in Formvon Sleuth von www.sandsprite.com oder mit demWebDeveloper von Chris Pe-derick für den Firefox gibt.Über die Plug-ins erhält derTester einen Zugriff auf dieHTML-Ergebnisse, währendsie der Browser darstellt. Auchin diesem Fall kann er alleWerte verändern, allerdings nurdie in der HTML-Darstellung

enthaltenen. Der Zugriff auf dieHeader, die an den Server ge-sendet werden, gestaltet sichdabei schwieriger.

Zum Hacken ist der Web-Developer auch nur bedingt ge-eignet, kann aber in manchenTests nützliche Dienste leisten.Anders sieht es bei Sleuth aus.Die Software stellt eine Misch-form zwischen Proxy und Plug-in dar, kann also HTML imBrowser bearbeiten und gleich-zeitig auch als Proxy mit Auto-matisierung, Fuzzing und Re-quest-Interception agieren. DerNachteil der Mischform ist dieunübersichtliche Darstellung derRequests und die Abhängigkeitvom Internet Explorer. Der Vor-teil jedoch liegt in der übersicht-lichen Darstellung der Daten derim Browser angezeigten HTML-Seite und in der eingebautenAuthentifizierung.

Fazit

Durch schlanke und funktiona-le Werkzeuge kann ein Testeiner Webanwendung erfolg-reicher und schneller durchge-führt werden. Allerdings ist derErfolg stark von der Erfahrungdes Testers abhängig, da jedeWebapplikation unterschied-liche Lücken hat, die sich teil-weise an überraschendenStellen in der Request-Verar-beitung verstecken. (sf/js)

Christoph Puppeist Security Consultant bei der

HiSolutions AG in Berlin undseit mehreren Jahren als

Berater tätig.

Anzeige der Query-Strings von www.heise.de in Sleuth(Abb. 3)

iX extra 11/2007

IT-Security

ix.1107.x.1-16 27.09.2007 12:13 Uhr Seite XIII

eMedia

BestellungeMedia GmbH Bissendorfer Straße 8 D-30625 Hannover

Der c’t Kalender 2008Die besten Illustrationen aus der c’tDIN A3, quer, 26 Kalenderblätter, 4-farbig

Best.-Nr.: 77759

Preis: 14,80 €

Fun-Shop

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 Best.Nr.: 77731 Größe L Best.Nr.: 77732Größe XL Best.Nr.: 77733Größe XXL Best.Nr.: 77734

Preis: jeweils 9,80 €

Telefon: +49 [0]511 53 72 95 Fax: +49 [0]511 [email protected]

Preisänderung/Irrtum/Ausverkauf vorbehalten. Alle Preise inkl. MwSt.

_1I2hKalenderNetze.qxp 28.09.2007 13:48 Uhr Seite 1

Letztlich geht es bei IT-Si-cherheit immer darum zu

gewährleisten, dass nur be-stimmte Personen – in ihrerdigitalen oder beim physi-schen Zugang realen Identität– bestimmte Dinge mit Syste-men und den darauf laufen-den Anwendungen machendürfen. Die letzten Jahrehaben gezeigt, dass Lösun-gen, die keine Rücksicht aufdie Frage der digitalen Iden-tität nehmen, im Grunde nurNotlösungen sind.

Nirgendwo wird das deut-licher als bei Webservices.Kaum ein Thema hat die IT soverändert wie die Öffnung einstin sich geschlossener IT-Wel-ten. Heute geht es nicht mehrdarum, das Unternehmen nachaußen über einen Perimeter-schutz – also an der Netzwerk-grenze – abzuschotten. In derheutigen Welt soll vielmehr derZugang auf IT-Ressourcen vonaußen erleichtert werden –allerdings nur für ganz be-stimmte Personen. Und die sol-len auch nur ganz bestimmteDinge tun dürfen. Dabei willman im Grunde zwei Dinge ver-einen, die im Gegensatz zuein-ander stehen: Öffnung undKontrolle. Wer die digitalen

Identitäten seiner Kunden, Lie-feranten oder auch Mitarbeiternicht im Griff hat, geht einhohes Risiko ein.

Der Kunde hat ebenfallszweigeteilte Interessen: Ermöchte einerseits schnell undeinfach auf Onlineinhalte zu-greifen können, andererseitsaber seine Privatsphäre ge-wahrt wissen. Je mehr persön-liche Daten er im Zuge einerShoppingtour im Internet preis-geben muss, desto mehr ver-

liert er mit der Zeit die Kontrolleüber das, was die Anbieter vonihm wissen. Im Kampf um dieinformationelle Selbstbestim-mung, immerhin ein zumindestin Europa hochrangiges Rechts-gut, ist der Nutzer heute weit-gehend der Unterlegene.

Ein Grund dafür ist, dass erstaunlich viele Lösungen dieSicherheit heute noch aus-schließlich auf der Systemebe-ne angehen, also die Identitätdes Benutzers beispielsweisemit dessen IP-Adresse gleich-setzen. Das beginnt bei der Paketfilterung und geht bis hinzu Network-Access-Control-Lösungen oder Client-Manage-ment-Produkten, die zwar Sys-teme, aber keine individuellenBenutzer kennen.

Ohne Identität geht nichtsBei der Kontrolle des Netzwerk-zugangs kommt die Identitätdes Benutzers stärker ins Spiel.Unterschiedliche Mitarbeitermüssen meist auch auf unter-schiedliche Anwendungen zu-greifen können, um ihre Aufga-ben zu erfüllen, und manchmalgelten dabei überdies unter-schiedliche Regeln. Das gilt erstrecht, wenn Externe auf dasUnternehmensnetzwerk zugrei-

iX extra 11/2007

IT-Security

Meine Identitätgehört mirIdentity-Management in Zeiten von Webservices und Web 2.0

Infolge der Öffnung der bislang abgeschottetenUnternehmensnetzwerke und der Verbreitung vonWebservices rückt das Thema Identitäts- undZugriffskontrolle noch mehr in den Mittelpunkt. Hierzeichnet sich ein grundlegender Wandel ab: Identity2.0 soll dem Benutzer die Kontrolle über seine Datenzurückgeben. Die Grundlage bilden zwei ähnlicheSysteme, OpenID und CardSpace.

Application

InfoCard

Information Card 1

Information Card 2

Information Card 3

3) Getsecuritytoken

4) Presentsecurity token

1) Get security tokenrequirements

2) Select desired identityby choosing an information card

Relying Parties Identity Providers

Policy

X Y Z

SecurityToken

SecurityToken

A B C

Kehrtwende: Anders als bei früheren Versuchen setztMicrosoft bei seinem mit Vista vorgestellten CardSpace-Modell, das auf verschiedenen „Visitenkarten” beruht, auf dieKontrolle und Hoheit des Nutzers über seine eigenen Daten –ohne Einwilligung geht nichts.

ix.1107.x.1-16 27.09.2007 12:13 Uhr Seite XIV

ix1107_x_000_qskills.indd 1x1107_x_000_qskills.indd 1 28.09.2007 17:43:08 Uhr28.09.2007 17:43:08 Uhr

fen sollen. Und will ein Kundeetwas bestellen, bezahlen undan seine Adresse geliefert be-kommen, geht es nicht ohneKenntnis seiner Identität.

Sicherheit, das wird dadurchklar, ist nur über erfolgreichesIdentitätsmanagement zuhaben. Mehr noch: Durchgängi-ge Sicherheitskonzepte vomPerimeter bis zu den Anwen-dungen verlangen geradezueine durchgängige Sicht auf dieIdentität. Sicherheitslösungenmüssen also zunehmend aufvorhandene Verzeichnisse zu-greifen können – oder auf vir-tuelle Verzeichnisdienste, diedann auf Verzeichnisse mitKunden, Partnern oder Mitarbei-tern verweisen und so eine vir-tuelle Gesamtsicht schaffen.

Das Hauptproblem der„neuen Offenheit“ vernetzterSysteme liegt nach Ansicht vonExperten weniger in der techni-schen Umsetzung als vielmehrin der alten Sichtweise auf dieIT-Security. Diese geht davonaus, dass der Anbieter einerWare, Dienstleistung oder Infor-mation, mithin der Systemadmi-nistrator, derjenige ist, der dieIdentitäten zu verwalten hat.Wer seine persönlichen Datennicht an der Tür abgibt, kommtgar nicht erst ins System.

Dies gefällt einer kleinen,aber wachsenden Schar vonIdentitäts-Aktivisten gar nicht.Sie fordern nicht mehr undnicht weniger als eine Umkeh-rung der Machtverhältnisse: DerBenutzer soll wieder die Kon-trolle über seine Daten bekom-men. Ihr Schlagwort heißt:„User-centric Identity“.

Selbstbestimmungauch im NetzEiner von ihnen ist Dick Hardt,Chef der kleinen SoftwarefirmaSxip, der für Internet und Web-services ein „dezentrales, kom-patibles, skalierbares und siche-res System“ fordert, das demMenschen erlaubt, sich im Inter-net genauso einfach auszuwei-sen wie in der richtigen Welt.Doch Hardt und seine Mitstreitergehen einen Schritt weiter. Siewollen, dass der Benutzer selbstbestimmen kann, welche Infor-mationen er im Zuge der Anmel-dung und Interaktion mit Web-services preisgibt.

Dieses „Identity 2.0“ ge-nannte Prinzip wäre Hardts Mei-nung nach „ein auf Internetmaßzugeschnittenes Identity- undAccess-Management-System,das einfach, sicher und offen istund bei dem der Benutzer im

Mittelpunkt steht“. Bei Identity1.0 weiß das System nur, dasseine Person ein Eintrag in einemVerzeichnis ist, aber es hatkeine Ahnung, wer sie ist. In derabgeriegelten Welt geschlosse-ner Firmennetze hat das nochgenügt, zumal der Arbeitgeberder „Besitzer“ der meisten Iden-titätsdaten der Mitarbeiter war.

Im offenen Kontext von ex-ternen Webservices funktionie-ren solche Systeme Hardts Mei-nung nach nicht. Die Folge seiÄrger und Mehraufwand für denBenutzer, der immer wiederNamen, Kennwörter und vieleInformationen über sich selbsteingeben muss. Dies aber stehtdem Geschäftserfolg von Online-anbietern im Weg. Gleichzeitigschafft die fehlende Selbstbe-stimmung des Nutzers ein Iden-titätsproblem für die Betreibervon Web-2.0-Anwendungen wieMySpace, Flickr oder die Video-archive von YouTube, deren Reizfür die meisten Benutzer ja ge-rade darin besteht, sich nachaußen auf möglichst kreativeWeise darstellen zu können.

Hardts Firma hat mit Sxipper,einem kostenlosen Plug-in fürden Firefox-Browser, gezeigt,wo die Reise hingehen soll. DerBenutzer lädt die Erweiterungauf seinen Rechner herunter

und trägt darin seine persönli-chen Daten ein, etwa Privat- undGeschäftsadresse, Kreditkarten-nummern oder Führerschein-daten. Jedes Mal, wenn er da-nach auf eine Website zugreift,die Informationen über ihn for-dert, startet Sxipper, stellt diegewünschten Informationen darund fragt, ob der Benutzer mitder Übermittlung einverstandenist. Pflichtfelder werden gekenn-zeichnet, freiwillige Angabenebenfalls. Mit einem Mausklickauf ein Hakenkästchen ent-scheidet der Benutzer, welcheDaten er weitergeben will undwelche nicht.

VielversprechenderZusammenschlussSxipper ist nur eine Lösungunter einem guten Dutzend, diegroße und kleine Anbieter unterdem Banner von OpenID entwi-ckeln und anbieten. OpenID istein dezentrales System zurIdentifizierung, dessen zugrundeliegendes Protokoll von BradFitzpatrick, dem Vater von Live-Journal (eine quelloffene Server-software), und David Recordonvon VeriSign entwickelt wurde.Mit im Boot sind große Anbieterwie IBM und Novell sowie dieEclipse Foundation, die sich

IT-Security

ix.1107.x.1-16 27.09.2007 12:13 Uhr Seite XV

NEU!

Hat Ihr Netzwerk wirklich keine Schwachstellen?

Deutsche Vertretung und deutschsprachiger Support für AVG: Jürgen Jakob Software-Entwicklung · www.jakobsoftware.de

AVG7

5 IS

NE01

AVG Internet Security für Windows®, für Netzwerke, für Linux und für E-Mail-Server.

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 B3.14ix1107_x_000_AVG.indd 1ix1107_x_000_AVG.indd 1 20.09.2007 18:43:26 Uhr20.09.2007 18:43:26 Uhr

unter anderem mit dem quell-offenen Bandit-Projekt an derEntwicklung von Standards fürdas Identitätsmanagement überunterschiedliche Systeme hin-weg beteiligt hat und somiteinen einheitlichen Ansatz fürdie Sicherheit und Verwaltungvon Identitäten schaffen will.

OpenID dient zunächst nurzur gegenseitigen Identifikationvon Benutzern. Die sollen sichmithilfe ihres digitalen Auswei-ses bei verschiedenen Websitesanmelden können, ohne jedesMal dieselben persönlichen In-formationen eintippen zu müs-sen. Die anschließende Authen-tifizierung erfolgt durch einensogenannten Identity ServiceProvider (auch iBroker genannt).Denjenigen, über dessen Web-site sich der Benutzer einge-loggt hat, bezeichnet man als„Relying Party“ (RP), denn ervertraut aufgrund seiner – inder Regel vorher vertraglich fixierten – Beziehung zum Iden-tity Service Provider dieser Au-thentifizierung. Der Identity Ser-vice Provider kann bei Bedarfzusätzliche Informationen vomBenutzer anfordern.

Im Internet weist sich derOpenID-Benutzer mithilfe einessogenannten URI (Uniform Re-source Identifier) aus, den ervon seinem iBroker erhält undder genauso arbeitet wie dieURL eines Webdokuments. ZurAuthentifizierung verwendetOpenID Standards wie Yadis, einProtokoll und Datenformat, mitdem Informationen über unter-stützte Dienste einer HTTP-URLim Konzept der URI-basiertenIdentität beschrieben und abge-rufen werden können. Im Grun-de genommen verwendet derBenutzer seinen URI als Benut-zernamen, während sein „Pass-wort“ sicher beim OpenID-Provi-der verwahrt wird.

Prinzipiell ähneln OpenID-Lö-sungen dem neuen CardSpace-Modell von Microsoft, das derKonzern mit dem Start von Vistaeinführte. Hier trägt der Benut-zer seine Identitätsdaten in so-genannten InfoCards ein, die

auf der Festplatte liegen und Informationen wie Name, Geburtsdatum, Wohnort, Ge-schlecht, Telefonnummern, Kre-ditkartendaten und Ähnlichesenthalten. Er kann mehrere Kar-ten mit unterschiedlich ausführ-lichen Informationen über sicherstellen, je nach Anforderung.Verlangt nun eine Website be-stimmte Daten, zückt CardSpacedie passende Karte und fragtden Benutzer, ob er einverstan-den ist, diese weiterzugeben.

Oft genügt Vertrauen

Diese Form der sogenanntenSelf-assertion (Selbstbehaup-tung) kommt ohne Verifizierungdurch eine übergeordnete In-stanz aus. Im Prinzip muss derAnbieter einfach glauben, wasihm der Benutzer sagt. Das ist in vielen Fällen im praktischenLeben ausreichend, etwa umsich Zutritt zu einem kostenlo-sen Onlinemagazin zu verschaf-fen oder sich in ein Chat-Forumeinzuloggen. Wollen beide Sei-ten dagegen miteinander Ge-schäfte machen, genügt einesolche freiwillige Selbstauskunftnicht. In diesem Fall muss sich

der CardSpace-Benutzer vorher,ähnlich wie beim iBroker vonOpenID, bei einer vertrauens-würdigen Stelle (Trusted ThirdParty) anmelden und dort seineDaten hinterlegen. Das kanneine offiziell zugelassene Zertifi-zierungsstelle sein, zum Beispielein Trust Center, aber auch eineBank, eine Kreditkartenfirmaoder ein Arbeitgeber. Will einInternetanbieter Informationen,wird die Anfrage automatischan die Vertrauensstelle weiter-geleitet, die die gewünschte In-formation bereitstellt. Gleich-zeitig ergeht an den Benutzereine Anfrage nach dessen Ein-verständnis, die Daten weiter-geben zu dürfen.

Häufig genügen auch soge-nannte Metadaten. Beim Kaufper Kreditkarte reicht meistenseine Bestätigung: „Zahlung er-folgt“. Mehr muss der Anbietergar nicht wissen. Ähnlich bei In-formationen, die lediglich als Al-tersnachweis dienen. Statt destatsächlichen Geburtsdatumsgenügt es, wenn von vertrau-enswürdiger Seite bestätigtwird: „Der Kunde ist über 18“.Auf diese Weise soll sich dieMenge der preiszugebenden

persönlichen Daten im Internet-Alltag deutlich reduzieren lassen– zur Freude von Verbrauchern,aber auch zur Entlastung vonAnbietern.

Für Microsoft stellt OpenCarddamit eine radikale Abkehr vonfrüheren Systemen wie MS Pas-sport dar, bei denen die Kontrol-le über die Daten weitgehend inRedmond lag. Dennoch kam dieAnkündigung im Februar 2007für die Fachwelt einigermaßenüberraschend, dass Microsoftund die OpenID-Gemeinde inZukunft eng zusammenarbeitenund für vollständige Interopera-bilität sorgen wollen. Die Nach-richt von der ungewöhnlichenAllianz zeitigte gleich Folgen. Sokündigte beispielsweise der On-linedienst AOL an, künftig mitOpenID arbeiten zu wollen. UndPing Identity, ein führender Hersteller von IAM-Systemen,will ein CardSpace-Modul alsOpenSource-Element für denApache 2 Server auf den Markt bringen. (sf/ur)

Tim Coleist Consultant bei Kuppinger

Cole & Partner sowieMitveranstalter der European

Identity Conference.

XVI iX extra 11/2007

IT-Security

Disk-Subsysteme finden sichin den unterschiedlichsten An-wendungen als Primär- oderSekundärspeicher, als virtuelleTape Library, als Backup- oderArchivsystem. Genau so unter-schiedlich sind die Umgebun-gen und Konfigurationen: alsSpeichererweiterung direkt an Server angeschlossen, fürden Zugriff durch mehrere

Server in ein Speichernetz eingebunden – als Stand-alone-System, im Gruppenver-bund, kaskadiert, gespiegelt,hierarchisch angeordnet oderüber einen Virtualisierer zu-sammengeschaltet.

Entsprechend groß ist dieSpannbreite verfügbarer Disk-Systeme. Sie reicht vom ein-fachen JBOD bis zum Super-

system mit 247 Petabyte Ge-samtkapazität. Was Disk-Sys-teme heute alles können, wieman das geeignete System fürseine Umgebung findet undwie man sich auf künftige An-forderungen vorbereitet, erläu-tert iX extra in Heft 12/07.

Erscheinungstermin: 15. November 2007

In iX extra 12/2007 Storage – Disk-Systeme: Technik und Produkte

DIE WEITEREN IX EXTRAS:

Ausgabe Thema Erscheinungstermin

01/08 Networking Aktuelle Trends bei Wireless LANs 13.12.0702/08 Mobility Mobiler Arbeitsplatz: Konsolidierte Verwaltung; 17.01.08

Notebooks als Desktopersatz03/08 IT-Security Malware-Trends – Trojaner, Botnetze & Co. 21.02.08

ix.1107.x.1-16.neu1 02.10.2007 10:46 Uhr Seite XVI