ASP.NET Application Security

1. ASP.NET Application Security Uwe Baumann TechnologieberaterDeveloper GroupMicrosoft GmbH uwebaum@microsoft.comhttp://www.uwebaumann.de

2. Was Sie erwartet • Was ist Web Application Security? • Ein Wettbewerb • Taugen Sie zum Webseiten-Hacker? • Bekannte Angriffe • Wo lauern Gefahren? • Was kann man dagegen tun? • Weiterführende Infomationen

3. Web Application Security • Sicherheit der Webpplikation • 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. „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.“

6. Der TechTalk Web Shop • Demo-Applikation mit Sicherheits-lücken • Ein kleine Herausforderung:Finden wir die Lücken!

7. Die Aufgaben: • Kaufen Sie billiger ein ... • Z.B. Eine Firewall für €1,00 • Ermitteln Sie Passwörter ... • Verschaffen Sie sich Administrator-Zugriff ... • Versenden Sie Junkmail mit dem Absender des Webshops ...

8. lab „Thinking like a Hacker“

9. Einige bekannte Angriffe

10. Parametermanipulation • Angreifer verändert Übergabeparameter der Zielsite • Daten in (verstecken) Formularfeldern, Querystrings • Beispiel: Preisinformationen, Authorisierungsflags usw.

11. Parametermanipulation: Abwehr • Keine relevanten Parameter zum Client schicken • Session-Objekt verwenden • Parameter verschlüsseln / hashen • Beispiel: Viewstate MAC (Message Authentication Code) • Nur wenn unbedingt nötig verwenden!

12. demo Parametermanipulation

13. SQL Insertion 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

14. Advanced SQL Insertion • 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!

15. SQL Insertion: 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 per Wizard erzeugt werden

16. SQL Insertion: 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

17. Exkurs: Stringvalidierung • ASP.NET RegularExpressionValidator • Prüft Eingabe auf dem Client und auf dem Server • Kein Umgehen durch Manipulation des HTTP-Requests möglich • Überprüfung der Werte mit Page.Validate() für alle Controls, Control.Validate für einzelne Controls • Automatische Überprüfung, wenn CausesValidation der absendenen Schaltfläche gesetzt ist

18. demo SQL Insertion

19. Cross-Site Scripting (CSS) 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

20. CSS: 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

21. CSS: 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?“

22. demo Cross Site Scripting

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

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

25. demo Open Mail Relay

26. Exkurs: ASP.NET Authentication • Passport • Ein anderes Mal... • Windows Authentication • User authentifiziert sich mit seinem Windows-Account • Impersonation möglich, d.h. Webapplikation läuft unter dem Account des Users • Ideal für Adminstrationswebseiten

27. Exkurs: ASP.NET Authentication • Forms Authentication • User authentifiziert sich auf einer Login-Seite gegen einen beliebigen Store (meistens Datenbank) • Ein Session-Cookie wird auf dem Client gesetzt und bei jedem Request mitgesendet • Wer das Cookie besitzt, kann die Identität des betreffenden Benutzers annehmen

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

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

30. Weitere Tips

31. Datenbank absichern • 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.

32. web.config-Einträge verschlüsseln • Verfügbar ab VS.NET 2003 („Everett“) • Patch für VS.NET 2002 erhältlich • Ermöglicht verschlüsselte Einträge • Identity, Process Model, Connection String • Einträge werden in web.config referenziert • Wert wird in der Registry verschlüsselt gespeichert • Registry-Key ist durch eine ACL geschützt

33. 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 Anfroderungen für LPAs sind dokumentiert [

34. Microsoft Baseline Security Analyser 1.1 • Identifiziert problematische Konfigurationen • Prüft Updatelevel • Erstellt Reports • Macht Vorschläge • Gibt Informationen • Prüft Windows, IIS, SQL uvm. • Lokal und Remote

35. 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!

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

37. Vielen Dank! • Fragen kostet nichts…

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

39. 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/OWASPWebApplicationSecurityTopTen-Version1.pdf?download • [SQLSecurity] SQLSecurity.comhttp://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

40. 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 Analyserhttp://www.microsoft.com/technet/treeview/default.asp?url=/TechNet/Security/tools/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 Bulletinshttp://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/