|
|
Computersprachen, und SicherheitWelchen Einfluss hat der Einsatz bestimmter Sprachen und Erweiterungen auf die Sicherheit eines Systems.
Das World Wide Web wächstAls das Web populär wurde, waren seine Seiten noch statisch und dienten der reinen Darstellung von Informationen. Die meisten Seiten enthielten wissenschaftliche Informationen oder Werbematerial. Seitdem hat das WWW an Funktionalität gewonnen. Technologien wie das Common Gateway Interface (CGI) und Java haben die Art und Weise, wie wir das Internet nutzen, drastisch verändert. Heute ist das Web ein Kanal für Datenbankintegration, elektronischen Datenaustausch (EDI), E-Commerce und sogar Videokonferenzen. Viele dieser Technologien beruhen auf neuen Sprachen und Erweiterungen. Mit Hilfe solcher Tools kann man Webseiten noch mehr Funktionalität verleihen und die Nutzung für den Anwender interessanter und interaktiver gestalten. Diese Situation hat den Wettbewerb auf dem Gebiet der Software-Entwicklung weiter verschärft. Um ihre Tools so schnell wie möglich auf den Markt bringen zu können, haben viele Firmen übersehen, dass ihre Produkte Sicherheitslücken beinhalten. In diesem Kapitel möchte ich solche Schwachstellen ansprechen und Ihnen zeigen, wie Sie sich schützen können. Dabei geht es um folgende Themen:
CGI und SicherheitCGI ermöglicht Web-Servern die Weitergabe von Informationen an Web-Clients über die reine Wiedergabe von Text oder HTML-Dateien hinaus. Dafür können fast alle gängigen Programmiersprachen benutzt werden. Die am häufigsten für CGI- Programmierung verwendeten Sprachen sind:
Normalerweise beinhalten CGI- Aufgaben die Abfrage von Datenbanken, die Anzeige von Statistiken und die Ausführung von WHOIS- oder FINGER-Abfragen über ein Web-Interface (obwohl Sie theoretisch fast jede netzwerkbasierte Abfrage mit CGI durchführen können). CGI-Programme laufen immer auf dem Server, und aus diesem Grund stellen sie eine hohe Belastung für das Netzwerk dar. Da es durch CGI außerdem zu Sicherheitsgefährdungen kommen kann, erlauben viele Internet Service Provider ihren Benutzern die Verwendung von CGI gar nicht erst. Je nach Ihrer Konfiguration können diese Sicherheitsprobleme durch CGI durchaus ernster Natur sein. Wenn ein Cracker eine CGI- Sicherheitslücke erfolgreich ausnutzt, kann er Befehle mit der Benutzerkennung des Webservers ausführen. Bei vielen Default-Konfigurationen läuft HTTPD als root, und das kann ein kritisches Problem darstellen. Im nächsten Abschnitt behandeln wir die Sicherheitsprobleme von CGI, die sich auf die Programmiersprache Perl beziehen.
Perl (Practical Extraction and Report Language)Perl ist die bei weitem beliebteste Sprache für die CGI-Programmierung. Das hat mehrere Gründe:
Außerdem ähneln Syntax, Funktionen und Methoden von Perl denen von SED, AWK, C und den Shell-Sprachen. Deshalb ist Perl bei Unix-Programmierern sehr beliebt.
Die Sicherheit von PerlDie Sicherheit von Perl ist ziemlich gut; es sind die Programmierer, die Sicherheitslöcher verursachen. Im folgenden Abschnitt werden diese Sicherheitslöcher beschrieben, und wie man sie vermeidet. Der SystemaufrufEin Sicherheitsproblem ist der Systemaufruf. Sie geben Perl mit Hilfe eines Systemaufrufs die Anweisung, einen nativen Befehl des Betriebssystems auszuführen. Hier ist ein Beispiel:
Dies veranlaßt grep, die Datei my_database nach Übereinstimmungen mit der vom Benutzer eingegebenen Zeichenfolge $user_input zu durchsuchen. Systemaufrufe wie dieser sind gefährlich, weil Sie nie voraussehen können, was der Benutzer machen wird. Die meisten Benutzer geben eine Zeichenfolge ein, die korrekt ist (oder von der sie zumindest denken, dass sie korrekt ist). Cracker gehen jedoch anders vor. Ein Cracker versucht, die Schwächen Ihres Scripts herauszufinden. Dazu gibt er Zeichenfolgen ein, die zur Ausführung weiterer Befehle vorgesehen sind. Nehmen wir einmal an, Sie hätten den obigen Systemaufruf in Ihrem Script stehen und keinen Mechanismus zur Filterung unerlaubter Zeichenfolgen vorgesehen. Dann könnte der Cracker auf einfache Weise Befehle an die Shell leiten, indem er seinen Eingaben bestimmte Metazeichen anfügt. Die meisten Shell-Interpreter (einschließlich command.com von MS-DOS) stellen eine Möglichkeit zur Ausführung sequentieller Befehle zur Verfügung. Dazu schreibt man die Befehle einfach durch Metazeichen getrennt hintereinander. Wenn Sie keinen Mechanismus einfügen, der jede ankommende Zeichenkette filtert, kann ein Cracker diese Metazeichen verwenden, um zusätzliche Befehle auf die Argumentliste zu schieben. Das klassische Beispiel dafür ist:
Die Datei /etc/passwd wird per E-Mail an den Cracker gesendet. Das funktioniert, weil das Semikolon den Interpreter anweist, den Mail-Befehl auszuführen, nachdem die grep-Suche beendet ist. Sie sollten möglichst verhindern, dass Benutzer überhaupt Zeichenketten eingeben können, in die sie Befehle einbauen könnten. Es gibt viele Wege, das zu umgehen. Sie könnten z.B. Optionsfelder, Auswahllisten oder andere Objekte einfügen, die nur angeklickt werden müssen. Wenn Sie den Benutzer zwischen mehreren Optionen wählen lassen, haben Sie eine viel größere Kontrolle darüber, was an STDIN eingelesen wird. Tipp:
Eine weitere Lösung (wenn Sie unbedingt Systemaufrufe verwenden wollen) ist, alle Sonderzeichen in dem Aufruf in Escape-Zeichen einzuschließen. Dann würde der folgende Befehl
statt dessen so aussehen:
Noch eine Lösung (die zwar einfacher, aber vielleicht weniger wünschenswert ist) wäre die Überprüfung der Benutzereingaben, bevor diese weitergeleitet werden. Es gibt mehrere Möglichkeiten:
Das Problem der Systemaufrufe ist nicht auf Perl beschränkt, sondern kann in jeder Programmiersprache auftreten, auch in C. Eugene Eric Kim, Autor von Programming CGI in C, schreibt dazu folgendes:
Tipp:
Ich empfehle Ihnen Kims neuestes Buch, CGI Developer's Guide (Sams.net). Kapitel 9, »CGI Security: Writing Secure CGI Programs«, gibt einen ausgezeichneten Überblick über CGI-Sicherheit. Kim spricht viele Szenarien an, denen Sie begegnen könnten:
Skripte im privilegierten Modus ausführenSkripte im privilegierten Modus auszuführen, ist ein weiterer verbreiteter Fehler. Er ist sogar so verbreitet, dass Perl über eingebaute Sicherheitsvorkehrungen dagegen verfügt. Ein Beispiel ist die Behandlung von setuid-Skripte (solche, die spezielle Privilegien voraussetzen, um ausgeführt werden zu können):
Sie sollten dennoch niemals Skripte im privilegierten Modus ausführen; und ich bin nicht der einzige, der Ihnen dies raten wird. Lincoln Stein, Autor des WWW Security FAQ, gibt folgenden Rat:
Tipp:
Erzeugen von DateienWenn Ihre CGI-Programme Dateien erzeugen, sollten Sie die folgenden Regeln einhalten:
Tipp:
Server Side Includes (SSI)Server Side Includes können automatisch Dokumente oder andere Objekte in eine Webseite einfügen, indem sie diese Elemente von der lokalen Festplatte aufrufen. Dokumente können per SSI auf folgende Weise aufgerufen werden:
Das scheint eine nützliche Funktion zu sein. Ein SSI könnte jedoch auch leicht folgendermaßen aussehen:
Wenn dieses SSI geparst wird und Httpd als root läuft, wird Ihre gesamte Festplatte gelöscht. Die meisten Web-Administratoren deaktivieren SSI. Wenn Ihr Server sie parst, seien Sie gewarnt. Sie sollten beim Schreiben von CGI-Scripts eine Routine einbauen, die SSIs ausfiltert. Tipp:
Tipp:
Tipp:
JavaAls Java herauskam, ging eine Welle der Aufregung durch das gesamte Internet. Die Programmierer waren fasziniert von der Aussicht auf eine plattformunabhängige Sprache, und das zu Recht. Die Entwicklung von Hybridanwendungen ist schwierig, fehleranfällig und teuer. Alles, was diese Probleme lindern könnte, wird deshalb mit offenen Armen empfangen. Vor diesem Hintergrund bedeutete Java einen wunderbaren Fortschritt. Außerdem war Java für die Web-Entwicklung optimiert. Programmierer nutzten diese Funktionalität rasch zur Erstellung lebendiger Multimedia-Anwendungen für die WebBrowser-Umgebung. Es dauerte jedoch nicht lange, bis die neue Programmiersprache in Verdacht geriet, Sicherheitsgefahren zu bergen. Nach und nach wurden mehrere schwere Sicherheitslücken bekannt. Im folgenden Abschnitt will ich auf diese Lücken kurz eingehen. Warum das Theater?Die welterschütternden Neuigkeiten über die Java-Sicherheit kamen aus dem Fachbereich Informatik der Princeton University. Drew Dean, Edward W. Felten und Dan S. Wallach leiteten die Untersuchungen. Der Kopf der Gruppe, Felten, war seit 1993 Informatik-Dozent an der Princeton University und hatte 1994 die Forschungsauszeichnung National Young Investigator erhalten. Er arbeitete mit den beiden Informatik-Absolventen Dean und Wallach daran, Sicherheitslöcher in Java zu finden. Das Felten- Team identifizierte die folgenden Probleme:
Die Reaktionen der Öffentlichkeit waren natürlich sehr negativ. Die Sache wurde noch dadurch verschlimmert, dass, selbst nachdem Sun und Netscape einen Fix herausgebracht hatten, viele der ursprünglichen Probleme immer noch vorhanden und durch andere Angriffsarten ausnutzbar waren. Tipp:
Von da an wurde Java sehr sorgfältigen Prüfungen unterzogen, und mehrere weitere Probleme wurden identifiziert. Zum Beispiel gelangte Java ungehindert durch Firewalls. Daher wurde die Theorie aufgestellt, dass bösartige Applets die Firewall- Sicherheit untergraben könnten. Die Java-Befürworter hielten entrüstet dagegen, dass ein solcher Angriff nicht möglich sei. Beide Seiten wurden jedoch durch ein Dokument mit dem Titel »Blocking Java Applets at the Firewall« zum Schweigen gebracht. Die Autoren demonstrierten darin nämlich eine Methode, mit der ein Java- Applet eine Firewall dazu bringen konnte, beliebige, normalerweise eingeschränkte Ports für den Host des Applets zu öffnen. Mit anderen Worten konnte ein solches Applet den grundlegenden Zweck und die Funktion einer Firewall komplett umgehen. Tipp:
Hier sind ein paar neuere Sicherheitslöcher, die für Sie interessant sein dürften:
Tipp:
Den Quellcode finden Sie hier: http://geek-girl.com/bugtraq/1998_1/0091.htmldie Online-Demo ist hier: http://home1.swipnet.se/~w-10867/fork/fl00d.htm
Tipp:
Nun aber zu den positiven Seiten von Java. Es verfügt nämlich auch über mehrere Sicherheitsmechanismen, die ein Lob verdienen. Das Sicherheitsmodell von Java beruht größtenteils auf etwas, das der Java-Sandkasten (sandbox) genannt wird. Das ist ein Bereich, der für die Ausführung von nicht vertrauenswürdigem Code reserviert ist. Jeder Code wird innerhalb des Sandkastens in einem Web- Browser ausgeführt, und eine Klasse mit Namen SecurityManager erzwingt dort die Einhaltung strikter Sicherheitsrichtlinien. Der SecurityManager kontrolliert den Zugriff auf alle Systemressourcen, darunter folgende:
Theoretisch hat der Code keine Möglichkeit, aus dem Sandkasten herauszukommen (oder die SecurityManager- Einschränkungen zu umgehen), und deshalb können in Browsern ausgeführte Applets nicht auf Systemressourcen zugreifen. Dieses Sicherheitsmodell ist sehr viel sicherer als das von Microsofts ActiveX verwendete Modell. Tipp:
Über das Schema von Sandkasten und
Die Sicherheit von Java ist durch die Einführung von Verschlüsselungsroutinen sogar noch weiter verbessert worden. Java unterstützt nun alle folgenden Algorithmen:
Die Klasse java.security.Signature stellt die Funktionalität digitaler Signaturen durch Verwendung eines beliebigen dieser drei Algorithmen zur Verfügung. Mehr über diese Funktionalität erfahren Sie in Java Cryptography Architecture API Specification and Reference , das Sie hier finden: http://java.sun.com/products/jdk/1.1/docs/guide/security/CryptoSpec.html Sie fragen sich jetzt vielleicht, ob Java denn nun sicher ist oder nicht. Das Fazit lautet: Java hat eine unendlich höhere Sicherheit als ActiveX. Darüber hinaus hat Sun sich enorm bemüht, einige sehr fortschrittliche Sicherheitsmerkmale in Java zu integrieren. Ich halte Java für sicherer als Perl. Dennoch empfehle ich Ihnen, Java an der Firewall zu filtern, und zwar aus folgendem Grund: Wir haben die Cracker-Gemeinde bislang noch nicht wirklich mit Java arbeiten sehen. Das kann deshalb so sein, weil Java schwieriger zu lernen ist als C oder Perl, die traditionellen Lieblingssprachen von Crackern. Außerdem - und das ist ein ganz wichtiger Punkt - sind Java-Attacken normalerweise Serverbasiert. Es ist kein Problem, Java-Attacken zu erzeugen und sie zu Forschungszwecken zu testen. Im wirklichen Leben würden Angriffe von einem Server jedoch schnell entdeckt werden, und der Eigentümer würde sich in einer schwierigen Lage befinden. Das kann sich jedoch ändern. Java ist von seinem Wesen her so auf die Netzwerkprogrammierung ausgerichtet, dass wir schließlich Angriffe erleben könnten, die über Standardleitungen implementiert werden (d.h. ohne dass ein Server involviert wäre). ActiveXKeine Sprache oder Erweiterung bietet mehr Server-zu-Client-Funktionalität als die ActiveX-Technologie von Microsoft (solange die Client-Umgebung Microsoft-zentriert ist). Mit ActiveX entwickelte Webseiten bieten oft eine phänomenale Funktionalität, die in eine benutzerfreundliche Oberfläche eingepackt ist. Eigentlich schade drum, denn man kann mit Recht behaupten, dass ActiveX die größte Sicherheitsbedrohung des Internet darstellt, die es jemals gegeben hat. Ein 1997 von Ellen Messmer von Network World verfaßter Artikel faßt alles zusammen, was Sie über die Sicherheit von ActiveX wissen müssen:
Diese Ängste von Unternehmen sind durchaus berechtigt. Fragen Sie einmal den Chaos Computer Club, eine Gruppe von Hackern in Hamburg. Der CCC hat im Februar 1997 der ganzen Welt die Sicherheitsmängel von ActiveX demonstriert:
Tipp:
Spätestens seit diesem Vorfall sprach sich herum, dass ActiveX absolut unsicher ist. Firewall- Administratoren verlangten sofort nach Tools, die ActiveX ausfiltern können. Tipp:
Was ist das Problem von ActiveX?Das Problem von ActiveX wurde von den Leuten bei JavaSoft prägnant zusammengefaßt:
Das ist ein kritisches Problem, und zwar aus folgenden Gründen:
Die nicht auf NTFS beruhenden Microsoft-Umgebungen haben kein richtiges Dateiberechtigungsschema oder eine wahlweise Zugriffskontrolle. (Das ist bei allen Novell-NetWare- und Unix-Umgebungen anders.) Daher kann ein bösartiges ActiveX-Steuerelement nicht nur den Verzeichnisraum eines einzelnen Benutzers beschädigen, sondern ein gesamtes Netzwerk. Microsofts Reaktion auf den CCC-Vorfall war unbefriedigend. Man behauptete, diese Sache hätte nur eines bewiesen: dass Sie keinen unsignierten Code akzeptieren sollten. Es ist jedoch aufgrund seiner zugrundeliegenden Technologie fraglich, ob ActiveX jemals so eingeschränkt wird, dass es nicht mehr auf Ihre Festplatte zugreifen kann. Im Grunde ist ActiveX nämlich nichts anderes als ein weiterentwickeltes OLE. OLE (Object Linking and Embedding) ist eine Technologie, die mit zusammengesetzten Dokumenten arbeitet, d.h. Dokumenten, die verschiedene Arten von Daten enthalten. Vor OLE wurden Datenelemente verfälscht, wenn sie aus ihrer Ursprungsanwendung entnommen und in eine andere eingefügt wurden. (Sie passten sich der Umgebung der Host-Anwendung an.) Zum Beispiel wurden beim Einfügen eines Spreadsheets in eine Textverarbeitung die Daten durcheinander gebracht. Bei OLE behalten diese Objekte (eingebettete Objekte genannt) ihren ursprünglichen Zustand. Jedes Mal, wenn Sie ein eingebettetes Objekt bearbeiten, wird die ursprüngliche Anwendung aufgerufen, so dass die Bearbeitung in der Ursprungsumgebung des Elements vorgenommen werden kann. Zum Beispiel wird Excel aufgerufen, wenn Sie ein Excel-Arbeitsblatt bearbeiten wollen, das in ein Word-Dokument eingebettet ist. (Im Gegensatz zu DDE ist dieser Austausch zwischen der aktuellen und der ursprünglichen Anwendung für Benutzer dabei nicht sichtbar.) Die Sicherheitsprobleme sind offensichtlich. Wenn ein ActiveX-Steuerelement sich als ein Element ausgeben kann, dass von einer bestimmten Anwendung erzeugt worden ist, kann es den Start einer Instanz dieser Anwendung auslösen. Nachdem die Anwendung gestartet wurde, kann sie von der ActiveX- Komponente »ferngesteuert« werden. Das passiert transparent, d.h. für den Benutzer nicht sichtbar. Man kann folgendes Fazit ziehen: Lassen Sie kein ActiveX durch Ihre Firewall oder Ihren signierten oder unsignierten Code. (Sie können, wenn Sie wollen - obwohl ich Ihnen dringend davon abraten würde - der Person vertrauen, die den Code signiert hat.) Script-SprachenSchließlich gibt es noch die Script-Sprachen. Script-Sprachen werden ausschließlich in Web-Browser-Umgebungen verwendet. Es gibt zwei von Belang:
Wir wollen uns beide kurz ansehen. JavaScriptJavaScript wurde von der Netscape Communications Corporation für die Netscape-Navigator/Communicator- Umgebung entwickelt (und in geringerem Maße für andere Browser, die es unterstützen). JavaScript ist keine Compiler-Sprache, verwendet keine Klassen-Bibliotheken und wird im allgemeinen in HTML eingebettet (obwohl Server-seitiges JavaScript sich auch in *.JS- Quelldateien befinden kann). Eigenständige Anwendungen können mit JavaScript nicht entwickelt werden, aber man kann sehr komplexe Programme schreiben, die innerhalb der Netscape-Navigator-Umgebung laufen können. Bei den frühen Versionen von JavaScript und Navigator gab es einige ernste Sicherheitsprobleme. Ein Entwickler fand sogar heraus, wie man JavaScript verwenden konnte, um auf die Festplatte eines Benutzers zu schreiben. Die meisten dieser Probleme gab es in Navigator 2.0 (JavaScript 1.1) und früheren Versionen, und sie sind nicht mehr von Bedeutung. Die Sicherheitsprobleme von JavaScript waren in der Vergangenheit relativ unbedeutend. Zum Beispiel konnte folgendes passieren:
Leider wurde die Funktionalität von JavaScript stark erweitert. (JavaScript ist inzwischen eine umfangreiche, mächtige Sprache.) In den letzten Monaten sind einige ernste und weniger ernste Sicherheitsprobleme zum Vorschein gekommen. Einige davon sind:
VBScriptVBScript ist für den Internet Explorer das, was JavaScript für den Netscape Communicator ist. Der einzige größere Unterschied ist folgender: VBScript ist eine Untermenge einer vollständigen Programmiersprache, die normalerweise zur Erzeugung eigenständiger Anwendungen verwendet wird. VBScript ist im wesentlichen eine abgespeckte Version von Microsoft Visual Basic. Im allgemeinen bietet VBScript dieselbe (oder noch größere) Funktionalität wie JavaScript. Es ist zum Beispiel möglich, VBScript dazu zu verwenden, eine endlose Anzahl von Fenstern zu öffnen, den Browser zu blockieren oder Formulardaten abzufangen. Bei der Mehrzahl der bislang realisierten Angriffe wurde jedoch JavaScript verwendet. Abwehr von Gefahren durch Script-SprachenSkript-Sprachen stellen nur eine Gefahr dar, wenn Sie es zulassen. Wenn Ihre Netzwerkumgebung strenge Sicherheit erfordert, empfehle ich Ihnen, sowohl JavaScript als auch VBScript am Router zu filtern. Alternativ dazu können Sie auch einfach die Ausführung ihrer Anweisungen in Ihrem Browser deaktivieren. Eine dieser beiden Möglichkeiten sollten Sie jedoch unbedingt wählen - nur weil Sie den Skript-Quelltext in HTML sehen können, heißt das noch lange nicht, dass ein Skript schläft, bis Sie ihm ein Ereignis anbieten (wie das Klicken auf einen Button oder eine Grafik). Die meisten bösartigen Skripts werden schon beim Laden ausgeführt. Wenn Sie also einem wirklich bösartigen Skript begegnen, ist es auf jeden Fall schon zu spät für irgendwelche Abwehrmaßnahmen. ZusammenfassungMit wachsender Funktionalität des Web werden immer mehr Sprachen und Erweiterungen entwickelt werden. In mancher Hinsicht ist das eine wunderbare Sache. Schließlich strebt man das Ziel an, transparenten Zugriff zu allen Netzwerk- und Dateiressourcen auf der ganzen Welt zu haben. Das Problem dabei ist, dass es immer schwieriger wird, für wirkliche Sicherheit zu sorgen. Der harte Wettbewerb auf dem Markt hat zudem dazu geführt, dass die Überprüfung der Qualität der Produkte im Hinblick auf die Sicherheit vernachlässigt wurde. Das ist bislang nicht so schlimm gewesen, da noch niemand wirklich zu Schaden gekommen ist. Aber denken Sie z.B. einmal an das Online- Banking, das immer mehr genutzt wird. Vor kurzem wurde berichtet, dass eine Bank in Schottland ActiveX verwendet. Würden Sie, nachdem Sie dieses Kapitel gelesen haben, dort noch ein Konto eröffnen? |
Senden Sie E-Mail mit Fragen oder Kommentaren zu dieser Website an:
tos.computer@gmx.de
|