presentation

ASP.NET
Application Security
Uwe Baumann
Technologieberater
Developer Group
Microsoft GmbH
[email protected]
http://www.uwebaumann.de
Was Sie erwartet


Was ist Web Application Security?
Ein Wettbewerb


Bekannte Angriffe



Taugen Sie zum Webseiten-Hacker?
Wo lauern Gefahren?
Was kann man dagegen tun?
Weiterführende Infomationen
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...)
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]
„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.“
Der TechTalk Web Shop


Demo-Applikation
mit Sicherheitslücken
Ein kleine
Herausforderung:
Finden wir die
Lücken!
Die Aufgaben:

Kaufen Sie billiger ein ...




Z.B. Eine Firewall für €1,00
Ermitteln Sie Passwörter ...
Verschaffen Sie sich AdministratorZugriff ...
Versenden Sie Junkmail mit dem
Absender des Webshops ...
lab
„Thinking like a Hacker“
Einige bekannte Angriffe
Parametermanipulation

Angreifer verändert Übergabeparameter
der Zielsite


Daten in (verstecken) Formularfeldern,
Querystrings
Beispiel: Preisinformationen,
Authorisierungsflags usw.
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!
demo
Parametermanipulation
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
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!
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
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
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
demo
SQL Insertion
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
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
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?“
demo
Cross Site Scripting
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
Open Mail Relay: Abwehr

Validierung von Parametern


Keine frei wählbaren Empängeradressen
zulassen
Seite zum Mailversand ggf. hinter die
Autorisierungsgrenze verlegen
demo
Open Mail Relay
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
Exkurs: ASP.NET Authentication

Forms Authentication



User authentifiziert sich auf einer LoginSeite 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
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]
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
Weitere Tips
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.
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
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 [
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
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…
Weitere Informationen





[Q329290] Verschlüsselte web.config-Einträge:
http://support.microsoft.com/default.aspx?scid=kb;ENUS;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 07356-1890-9.
Buch als PDF File:
http://msdn.microsoft.com/library/default.asp?url=/library/enus/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/OWASPWebApplicati
onSecurityTopTen-Version1.pdf?download
[SQLSecurity] SQLSecurity.com
http://www.sqlsecurity.com
[SQLSecLock] SQLSecurity Checklist
http://www.sqlsecurity.com/DesktopDefault.aspx?tabindex=3&ta
bid=4
[AdvSQLInj] „Advanced SQL Injection In SQL Server
Applications“. Chris Anley.
http://www.nextgenss.com/papers/advanced_sql_injection.pdf
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=/Tec
hNet/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 Bulletins
http://www.microsoft.com/technet/treeview/default.asp?url=/tech
net/security/