Christian Wenz Karsten Samaschke Uwe Baumann

Präsentation zum Thema: "Christian Wenz Karsten Samaschke Uwe Baumann"—  Präsentation transkript:

1 Christian Wenz Karsten Samaschke Uwe Baumann
Web Hacking Christian Wenz Karsten Samaschke Uwe Baumann

2 Was Sie erwartet Was ist Web Application Security?
Der (Anti-)Hacker-Grundkurs Wo lauern Gefahren? Was kann man dagegen tun? Weiterführende Informationen

3 Web Application Security
Sicherheit der Webapplikation Nicht Bugs des Webservers Sicherheitslücken, die durch potentiell unsicheren Code entstehen Unabhängig von der verwendeten Technologie (ASP, ASP.NET, JSP, PHP...)

4 Ein großes Problem Viele Lücken sind bekannt
Zahllose Whitepapers und Bücher Beispiel: „OWASP Top 10“ – Open Web Application Security Project Viele Entwickler wiegen sich dennoch in falscher Sicherheit Motto: „Wir verwenden SSL!“ „There is no patch for stupidity“ [SQLSecurity]

5 Ein typischer Web Shop…
Demo-Applikation mit Sicherheitslücken Finden wir die Lücken, die Hacker finden sie garantiert!

6 Hacker-Grundkurs: Wir kaufen billiger ein ...
Z.B. Eine Firewall für €1,00 Wir ermitteln Passwörter ... Wir verschaffen uns Administrator-Zugriff ...

7 Let‘s Hack!

8 „Never trust the Client!“
Howard‘s zwei Grundregeln [Howard] „Jede Eingabe ist destruktiv, solange nicht das Gegenteil bewiesen ist.“ „Daten müssen überprüft werden, da sie die Grenzen zwischen vertrauenswürdigen und nicht vertrauenswürdigen Umgebungen überschreiten.“

9 Einige bekannte Angriffe

10 Parametermanipulation
Cross Site Request Forgeries (CSRF) Angreifer verändert Übergabeparameter der Zielsite Daten in (verstecken) Formularfeldern, Querystrings Beispiel: Preisinformationen, Authorisierungsflags usw. Grundprinzip: Daten kommen per GET/POST an, also schreiben wir uns unser Formular selber!

11 Parametermanipulation: Abwehr
Keine relevanten Parameter zum Client schicken Session-Objekt verwenden Parameter verschlüsseln / hashen Beispiel für ASP.NET: Viewstate MAC (Message Authentication Code) Nur wenn unbedingt nötig verwenden! Andere Technologien: Standard-Verschlüsselungsalgorithmen verwenden

12 SQL Injection Angriff Angreifer schiebt der Site SQL-Code unter
Die Zielsite leitet den SQL-Code an die Datenbank weiter Möglich, wenn dynamische SQL-Strings generiert werden SQL-Code wird unter der Identität und mit den Rechten der Applikation ausgeführt Im Extremfall ist das Auslesen der gesamten Datenbank möglich

13 Advanced SQL Injection
Union Attack Eine zweite Anfrage wird an eine bestehende Anfrage „angehängt“ Abfrage von Systemtabellen möglich Unendliche Möglichkeiten für den Angreifer Drop Table Attack Angreifer kann ganze Tabellen mit einem kurzen Befehl löschen! Shell Attack (nur MS SQL Server) xp_cmdshell 'fdisk c:'

14 SQL Injection: Abwehr Kein dynamisches SQL verwenden
Auf keinen Fall dynamisches SQL verwenden Dynamisches SQL vermeiden Auch in Stored Procedures! Parameterisierte Abfragen verwenden Schneller und sicherer Code kann in einigen Technologien per Wizard erzeugt werden

15   Code (ASP.NET) 'Assign the SQLcommand
MyCommand.CommandType = CommandType.Text MyCommand.CommandText = _ "SELECT * FROM Products WHERE OrderCode='" & OrderCode & "'" 'Execute the command MyConnection.Open() Dim MyReader As SqlDataReader = MyCommand.ExecuteReader(CommandBehavior.CloseConnection) ' Assign the SQLcommand MyCommand.CommandType = CommandType.Text MyCommand.CommandText = _ "SELECT * FROM Products WHERE MyCommand.Parameters.Add(New System.Data.SqlDbType.VarChar, 10, "OrderCode")).Value = OrderCode ' Execute the command MyConnection.Open() Dim MyReader As SqlDataReader = MyCommand.ExecuteReader(CommandBehavior.CloseConnection) 

16 Code (PHP/MySQL)  <?php $db = mysql_connect('server', 'user', 'passwort'); $sql = sprintf( 'SELECT * FROM users WHERE username='%s' AND password='%s', $_POST['name'], $_POST['pwd']); $ergebnis = mysql_query($sql, $db); ?> <?php $db = mysql_connect('server', 'user', 'passwort'); $sql = sprintf( 'SELECT * FROM users WHERE username='%s' AND password='%s', mysql_real_escape_string($_POST['name']), mysql_real_escape_string($_POST['pwd'])); $ergebnis = mysql_query($sql, $db); ?>  *Überprüfung, ob $_POST gefüllt ist, entfällt aus Platzgründen

17 Prepared Statements (MySQLi)
<?php $db = mysqli_connect('server', 'user', 'passwort'); $sql = mysqli_prepare($db, 'SELECT * FROM users WHERE username=? AND password=?'); mysqli_stmt_bind_param( $sql, 'ss', $_POST['name'], $_POST['pwd']); mysqli_stmt_execute($sql); ?>  *Überprüfung, ob $_POST gefüllt ist, entfällt aus Platzgründen

18 SQL Injection: Abwehr (2)
Minimale Rechte für die Applikation vergeben Schützt vor dem Supergau LPAs (Low Privilege Accounts) zur Applikationsausführung und auf der Datenbank anlegen Applikation darf nicht Owner der Datenbanktabelle sein

19 Cross-Site Scripting (XSS) Angriff
Angreifer zwingt die Zielsite zur Anzeige von Skriptcode Unendliche Möglichkeiten für den Angreifer Ausführen von schädlichem Code Umleitung auf andere Site Ausspionieren von Cookies <script language="JavaScript"><!-- location.href=" //--></script>

20 XSS: Abwehr Validierung von Parametern
Auf potentiell unsichere Zeichen und Tags prüfen „<script>“ etc.)  Eingaben mit HtmlEncode() umwandeln ASP.NET 1.1 nimmt Überprüfung automatisch vor und generiert Fehler (abfangen!) ASP.NET 1.0 verlangt manuelle Überprüfung PHP: htmlspecialchars() Java: selbst schreiben

21 XSS: Fallen Keine „Reparaturversuche“ unternehmen
Frage lautet: „Was ist illegal?“ „Escaping“ (Verdoppeln) von Hochkommata Suchen nach speziellen Zeichen wie < etc. Besser: Definition der legalen Zeichen Frage lautet: „Was ist legal?“ Dynamische Ausgaben prüfen Ein AAAAAAAAAA…A zerstört jedes Design Abhilfe in PHP: wordwrap()

22 Open Mail Relay Angriff
Angreifer sendet Mail über die Zielsite Möglich, wenn die Zielsite die Mailempfänger als Eingabeparameter akzeptiert Angreifer kann Versand automatisieren, um Spam zu verschicken Allgemein riskant: Formular-Mailversand Wird zurzeit gerne von Spammern verwendet Eingabevalidierung

23 Open Mail Relay: Abwehr
Validierung von Parametern Keine frei wählbaren Empfängeradressen zulassen Seite zum Mailversand ggf. hinter die Autorisierungsgrenze verlegen

24 Replay-Angriff Angreifer „klaut“ Session-Cookie
Möglich durch XSS-Angriff, Abfangen der HTTP-Kommunikation, Social Engineering, Umgebungsvariable HTTP_REFERER Cookie enthält die Session-ID eines Users Angreifer kann sich als dieser User „tarnen“ [Finnel]

25 Replay-Angriff: Abwehr
Kommunikation über SSL (HTTPS) Nachteil: Sehr hoher Rechenaufwand IIS 6: Bessere Unterstützung von SSL Hardwarelösungen Cross-Site-Scripting ausschließen Session an IP-Adresse binden HTTP_REFERER-Check (nicht in jedem Webbrowser )

26 Weitere Tipps

27 Datenbank absichern MSSQL: Trusted Connections verwenden
Verwendet NTLM zwischen Applikation und SQL Server Kein Klartextpasswort im Connection String Leider nur für SQL Server möglich Verwendung von IPSec erwägen Verschlüsselung von Kommunikation zwischen Applikationsserver und Datenbankserver uvm. SQL Server Best Practices Analyzer 1.0 [SQLBPA]

28 Low Privilege Account (LPA)
So viele Rechte wie nötig, so wenig wie möglich Bestimmte Rechte sind zur Applikationsausführung nötig Alle anderen Rechte sollten nur nach weiser Überlegung gewährt werden Genaue Anforderungen für LPAs sind dokumentiert [Finnel]

29 Microsoft Baseline Security Analyzer 2.0
Identifiziert problematische Konfigurationen Prüft Updatelevel Erstellt Reports Macht Vorschläge Gibt Informationen Prüft Windows, IIS, SQL uvm. Lokal und Remote

30 IIS Lockdown Tool 2.1 Deaktiviert nicht genützte Features
Rollenbasiert, z.B. Webserver, Messaging etc. URLScan filtert potentiell unsichere HTTP-Requests Filterregeln frei konfigurierbar ASP.NET Debugging: [Q310588] beachten!

31 Microsoft Security Bulletins
Wichtigste Ressource für Security Patches „Hätten wir nur früher reagiert...!“ Code Red SQL Slammer

32 Vielen Dank! Fragen kostet nichts ... Eine geknackte Website schon!
Besser paranoid als offline ™

33 Weitere Informationen
[Q329290] Verschlüsselte web.config-Einträge: [Wintellect] Wintellect ASP.NET FAQ (mit vielen Security-Fragen) [Finnel] “Patterns and Practices: Building Secure ASP.NET Applications”. Lynn Finnel (ed.). Microsoft Press, ISBN Buch als PDF File: [Howard] „Sichere Software programmieren“. Michael Howard, David LeBlanc. Microsoft Press, ISBN X. [Basiura] „Professional ASP.NET Security“. Russ Basiura et al. Wrox Press, ISBN

34 Weitere Informationen
[OWASP] The Open Web Application Security Project [OWASPTop10] „The 10 Most Critical Web Application Vulnerablity“ [SQLSecurity] SQLSecurity.com [SQLSecLock] SQLSecurity Checklist [AdvSQLInj] „Advanced SQL Injection In SQL Server Applications“. Chris Anley. [SQLBPA] Microsoft SQL Server 2000 Best Practices Analyzer 1.0 Beta

35 Weitere Informationen
[QDefense] „AdCycle AdCycle SQL Command Insertion Vulnerability” (Beispiel für SQL Injection) [MBSA] Microsoft Baseline Security Analyser [Q310588] “PRB: Security Toolkit Breaks ASP.NET Debugging in Visual Studio .NET” [MSSec] Microsoft Security Bulletins