Secure .NET Development

Transcription

Autor: Martin Schagerl
Letzte Änderung am 10.07.2014
Version 1.1
Lexon e.U., Inh. Martin Schagerl, Holzing 52, A – 3254 Bergland
T: +43 / 676 / 7119622, E: [email protected], I: http://www.lexon.at
Kurzfassung
In dieser Arbeit werden Schwachstellen sowie Fehler aufgezeigt, welche beim Entwickeln von .NET
Anwendungen entstehen können. Um die Sicherheit von Applikationen zu erhöhen, werden entsprechende
Gegenmaßnahmen und Lösungen erarbeitet, welche sowohl theoretisch also auch praktisch vorgestellt
werden. Software Entwickler können die Ergebnisse für bestehende und für neue Projekte nutzen. Das
.NET Framework bietet grundsätzlich sehr viel Sicherheitsfeatures an, jedoch müssen diese richtig
implementiert und benutzt werden. Dadurch kann die Qualität einer Software gesteigert werden, wodurch
spätere Schäden verhindert werden können.
Typische Schwachstellen in Webapplikationen wie Cross-Site Scripting, SQL Injection oder Direct Object
References werden analysiert und durch .NET Features behoben. Auch für die Verwendung von WCF oder
ASP.NET Webservices werden Sicherheitsmechanismen präsentiert. Da das .NET Framework sehr gut in
das Betriebssystem integriert ist, wird gezeigt, wie auf den Zertifikatsspeicher zugegriffen wird und dies für
kryptografische Verfahren genutzt werden kann. Dazu werden sowohl symmetrische als auch
asymmetrische Algorithmen behandelt, um den Schutz von sensiblen Daten zu gewährleisten. Zusätzlich
wird das Thema Reverse Engineering aufgegriffen, damit Programmroutinen und hartcodierte
Informationen nicht aufgedeckt werden können. Aber auch Techniken zum Schützen von
Konfigurationsdaten wie beispielsweise dem ConnectionString werden besprochen.
Die Ergebnisse dieser Arbeit bieten einen guten Leitfaden zum sicheren Entwickeln und Bereitstellen von
.NET Anwendungen.
Abstract
This paper describes vulnerabilities and errors, which may occur in developing .NET applications. To
increase the security level of applications, techniques and solutions for preventing security leaks in software
products are presented. For better understanding, the theoretical aspects will be explained with the help of
additional examples. Software developers may use the results for existing and new .NET projects. Basically
the .NET framework offers a lot of security features, but they must be implemented and used in a correct
way. With the use of these features the quality of software can be increased and subsequent damages
prevented.
Typical vulnerabilities of web applications such as cross-site scripting, SQL injection or direct object
references will be analyzed and resolved with the help of built-in .NET features. The thesis also presents
mechanisms for WCF and ASP.NET web services. Due to the fact that the .NET framework is well
integrated into the operating system, this paper shows a way to use the Windows certificate store for
cryptographic tasks. To ensure the protection of sensitive data, symmetric and asymmetric algorithms will
be explained and implemented. Additionally the topic "reverse engineering" is picked up. By following the
result presented, uncovering of program routines and hardcoded information can be avoided. Additionally
there will be a discussion on techniques for protecting configuration data, such as connection strings.
All in all this thesis provides a best practice guide for developing and deploying secure .NET applications.
2
Inhaltsverzeichnis
1.
EINLEITUNG...................................................................................................................................... 6
1.1.
1.2.
1.3.
MOTIVATION UND RELEVANZ ................................................................................................................. 6
ZIELSETZUNG ....................................................................................................................................... 6
AUFBAU DER ARBEIT............................................................................................................................. 7
2.
FACHLICHES UMFELD VON .NET .................................................................................................. 8
2.1.
2.2.
2.3.
.NET ARCHITEKTUR ............................................................................................................................. 8
ENTITY FRAMEWORK .......................................................................................................................... 10
LINQ ................................................................................................................................................. 11
3.
WEB SECURITY .............................................................................................................................. 13
3.1.
3.1.1.
3.1.2.
3.1.3.
3.2.
3.2.1.
3.2.2.
3.2.3.
3.3.
3.4.
3.5.
3.6.
CROSS SITE SCRIPTING (XSS)........................................................................................................... 13
Reflected XSS .............................................................................................................................. 13
Stored XSS ................................................................................................................................... 15
DOM based XSS .......................................................................................................................... 17
SQL INJECTION .................................................................................................................................. 17
Unsichere Datenbankzugriffe ....................................................................................................... 17
Sichere Datenbankzugriffe ........................................................................................................... 19
Informationen einer Datenbank ermitteln ..................................................................................... 20
DIRECT OBJECT REFERENCE .............................................................................................................. 23
CROSS-SITE-REQUEST-FORGERY (CSRF) .......................................................................................... 25
AUTHENTIFIZIERUNG ........................................................................................................................... 28
ASP.NET W EB API ........................................................................................................................... 32
4.
WINDOWS COMMUNICATION FOUNDATION (WCF) .................................................................. 34
4.1.
4.2.
4.3.
ENDPOINTS ........................................................................................................................................ 34
SICHERHEITSMECHANISMEN ................................................................................................................ 37
WCF VS. ASP.NET W EB API............................................................................................................. 39
5.
KRYPTOGRAPHIE .......................................................................................................................... 40
5.1. SYMMETRISCHE VERFAHREN............................................................................................................... 40
5.1.1.
Diffie-Helman Protokoll ................................................................................................................. 44
5.2. ASYMMETRISCHE VERFAHREN............................................................................................................. 46
5.2.1.
Verschlüsselung ........................................................................................................................... 46
5.2.2.
Digital Signieren............................................................................................................................ 48
5.3. DIGITALE ZERTIFIKATE ........................................................................................................................ 50
5.3.1.
Verschlüsseln ............................................................................................................................... 51
5.3.2.
Digital Signieren............................................................................................................................ 53
6.
REVERSE ENGINEERING .............................................................................................................. 56
6.1.
GEGENMAßNAHMEN ............................................................................................................................ 58
7.
DEPLOYMENT ................................................................................................................................ 60
7.1. KONFIGURATIONSDATEN ..................................................................................................................... 60
7.1.1.
Clientanwendungen ...................................................................................................................... 60
3
7.1.2.
Webanwendungen ........................................................................................................................ 60
7.2. STRONG NAMES ................................................................................................................................. 61
7.3. CLICKONCE-BEREITSTELLUNG ............................................................................................................ 63
8.
KONZEPTIONIERUNG EINES SECURE CODING DEMONSTRATORS ...................................... 65
8.1.
8.2.
8.3.
W EB SECURITY .................................................................................................................................. 65
KRYPTOGRAPHIE ................................................................................................................................ 66
WCF ................................................................................................................................................. 67
9.
ZUSAMMENFASSUNG & AUSBLICK............................................................................................ 68
9.1.
W EITERE FEHLERQUELLEN ................................................................................................................. 68
Abbildungsverzeichnis
Abbildung 1: .NET Architektur ....................................................................................................................... 9
Abbildung 2: Aufbau von Entity Framework [13] ......................................................................................... 11
Abbildung 3: Webseite für Reflected XSS Angriff ....................................................................................... 14
Abbildung 4: Ergebnis eines Relected XSS Angriffs .................................................................................. 14
Abbildung 5: Eingabe für eine Stored XSS Attacke .................................................................................... 16
Abbildung 6: Ausführung eines Stored XSS Code ..................................................................................... 16
Abbildung 7: Nicht ausgeführte SQL Injection ............................................................................................ 18
Abbildung 8: Ausgeführte SQL Injection ..................................................................................................... 19
Abbildung 9: Blind SQL Injection - Datenbanknamen ermitteln .................................................................. 23
Abbildung 10: CSRF anfällige Webapplikation ........................................................................................... 25
Abbildung 11: Inhalt der CSRF präparierten Webseite ............................................................................... 27
Abbildung 12: Cookie durch die AntiForgeryToken() Funktion ................................................................... 28
Abbildung 13: WCF Kommunikation im Klartext ......................................................................................... 38
Abbildung 14: Schlüsselaustausch abhören ............................................................................................... 44
Abbildung 15: Benutzerzertifikatsspeicher .................................................................................................. 51
Abbildung 16: E-Mail Signatur überprüfen .................................................................................................. 54
Abbildung 17: Dekompilierte Applikation .................................................................................................... 57
Abbildung 18: Originaler Source Code ....................................................................................................... 57
Abbildung 19: Reverse Engineering nach Obfuscating .............................................................................. 59
Abbildung 20: Signieren einer .NET Bibliothek ........................................................................................... 62
Abbildung 21: Information einer Assembly setzen ...................................................................................... 63
Abbildung 22: Exception bei manipulierten Bibliotheken ............................................................................ 63
Abbildung 23: Applikation mittels ClickOnce bereitstellen .......................................................................... 64
Abbildung 24: Herkömmlicher Ablauf des Web Security Demonstrators ................................................... 66
Abbildung 25: Angriffsvektoren des Web Security Demonstrators ............................................................. 66
Listings
Listing 1: Herkömmliche SQL Abfrage ........................................................................................................ 11
4
Listing 2: LINQ Abfrage ............................................................................................................................... 12
Listing 3: Verhindern von gefährlichen Ausgaben in der View ................................................................... 15
Listing 4: Verhindern von gefährlichen Eingaben am Controller................................................................. 15
Listing 5: Unsicherer Datenbankzugriff ....................................................................................................... 18
Listing 6: Entity Framework - LINQ Abfrage ............................................................................................... 20
Listing 7: Nicht parametrisierte SQL Anweisung ........................................................................................ 20
Listing 8: Parametrisierte SQL Anweisung ................................................................................................. 20
Listing 9: Benutzerdefinierte Fehlermeldungen .......................................................................................... 21
Listing 10: Blind SQL Injection – Anzahl der Spalten ermitteln................................................................... 22
Listing 11: Berechtigung für Direct Object Reference überprüfen .............................................................. 24
Listing 12:HTML Code der CSRF anfälligen Webseite ............................................................................... 26
Listing 13: CSRF präparierte Webseite ...................................................................................................... 26
Listing 14: Implementieren der AntiForgeryToken() Funktion..................................................................... 27
Listing 15: HTML Code durch die AntiForgeryToken() Funktion ................................................................ 27
Listing 16: Attribut zum Überprüfen des CSRF Token ................................................................................ 28
Listing 17: Authorize Attribut ....................................................................................................................... 31
Listing 18: Implementierung der Forms Authentication .............................................................................. 31
Listing 19: OData - Anzahl der Datensätze einschränken .......................................................................... 33
Listing 20: OData - Operationen einschränken ........................................................................................... 33
Listing 21: Service Contract ........................................................................................................................ 35
Listing 22: WCF Endpoint (Service) ............................................................................................................ 36
Listing 23: WCF Endpoint (Client) ............................................................................................................... 36
Listing 24: WCF mit Transportsicherheit ..................................................................................................... 38
Listing 25: TCP Server für AES Kommunikation ........................................................................................ 41
Listing 26: TCP Client für AES Kommunikation .......................................................................................... 43
Listing 27: Diffie-Hellman Implementierung (Client) ................................................................................... 45
Listing 28: Diffie-Hellman Implementierung (Server) .................................................................................. 45
Listing 29: RSA Verschlüsselung (Server) .................................................................................................. 47
Listing 30: RSA Verschlüsselung (Client) ................................................................................................... 47
Listing 31: RSA Signatur erstellen .............................................................................................................. 48
Listing 32: RSA Signatur überprüfen .......................................................................................................... 49
Listing 33: Verschlüsseln mit Zertifikaten.................................................................................................... 52
Listing 34: Entschlüsseln mit Zertifikaten .................................................................................................... 53
Listing 35: Signatur mit einen Zertifikat erstellen ........................................................................................ 54
Listing 36: Signatur überprüfen ................................................................................................................... 55
Listing 37: Demonstrator: Start des gewünschten Verschlüsselungsalgorithmus ...................................... 67
Tabellenverzeichnis
Tabelle 1: Ablauf einer Forms Authentication [27] ...................................................................................... 30
Tabelle 2: Technologien von WCF [33, p. 7] .............................................................................................. 34
Tabelle 3: WCF Webservice vs. ASP.NET Web API [37] ........................................................................... 39
Tabelle 4: Funktionalitäten der Demo Webapplikation ............................................................................... 65
5
1. Einleitung
1.1.
Motivation und Relevanz
Heutzutage steht es sicherlich außer Frage, dass eine sichere Software von enormer Bedeutung ist.
Dennoch gibt es zahlreiche Sicherheitslücken in bestehenden sowie neuentwickelten Softwareprodukten.
Ein Grund dafür ist, dass die Entwicklung von sicherer Software mit Zeitaufwand und somit mit Kosten
verbunden ist. Da Kunden meist nur die korrekte Funktionalität und eventuell das Aussehen einer
Anwendung bewerten, werden Sicherheitsaspekte von Entwicklern häufig ignoriert. Diese
Kosteneinsparungen können je nach Größe und Art der Software einen enormen finanziellen Schaden
bedeuten. Um ein paar Zahlen zu nennen: Laut einer Studie mit 150 Organisationen, kostet alleine die
Sanierung einer einzelnen Schwachstelle durchschnittlich 300.000 $. [1] Im Jahr 2007 hat schlecht
entwickelte Software einen Schaden von 180 Milliarden Dollar in der USA angerichtet. [2] Neben diesen
hohen Kosten können Sicherheitslücken das Image eines Unternehmens zerstören, wenn beispielsweise
persönliche Daten bzw. Kreditkarteninformationen von Angreifern aufgedeckt werden.
Viele Unternehmen, Institute, Organisationen und öffentliche Einrichtungen investieren viel Geld in ihre ITInfrastruktur, ohne Rücksicht auf Softwaresicherheit zu nehmen. Ohne Frage haben Systeme wie
beispielsweise Firewalls ihre Berechtigung und können bestimmte Angriffe abwehren, jedoch sind diese
vollkommen nutzlos, wenn eine Softwareschwachstelle aktiv ausnutzbar ist. Eine gute Sicherheitspolitik ist
gegeben, wenn in allen IT-Bereichen (Infrastruktur, Software, Clients, usw.) ein hohes Sicherheitsniveau
erreicht wird.
Um eine sichere Software zu entwickeln, empfiehlt es sich, auf bestehende Frameworks zurückzugreifen,
welche bewährte Sicherheitskonzepte anbieten. Solche Frameworks machen Anwendungen nicht nur
sicherer, sondern beschleunigen zusätzlich ihre Entwicklung. Es kann nämlich auf viele Funktionalitäten
zurückgegriffen werden, ohne diese neu entwickeln zu müssen. Microsoft, einer der größten
Softwarehersteller der Welt, stellt dazu das .NET Framework für Entwickler/innen zur Verfügung. [3, p. 11]
Einer der großen Vorteile dieses Frameworks ist, dass es in unterschiedlichen Anwendungstypen
verwendet werden kann:
 Konsolenanwendungen
 Desktopanwendungen
 Webanwendungen
 Webservices
Dadurch können Entwickler einerseits mit einem Know-How viele unterschiedliche Anwendungen erstellen,
und andererseits kann ein Code in mehreren Applikationen wiederverwendet werden.
1.2.
Zielsetzung
Im Vergleich zu klassischen Programmiersprachen wie C oder C++ bietet das .NET Framework viel
Unterstützung bei der Entwicklung sicherer Applikationen. Trotzdem beinhalten .NET Applikationen
Sicherheitsschwachstellen, verursacht z.B. durch
6
 Verwendung unsicherer Aufrufe (z.B. Ausgabe ohne Codierung)
 unsichere Verwendung von Funktionen
 Fehler in der Logik (z.B. Integer Overflows)
 Aufrufe von Legacycode
 fehlerhafte Verwendung von Sicherheitsfunktionalität (z.B. Authentisierung, Autorisierung,
Verschlüsselung)
Das .NET Framework bietet jede Menge Sicherheitsfunktionalitäten an, welche jedoch nicht immer
automatisch zur Wirkung kommen, weil diese explizit von Programmierer/innen implementiert werden
müssen. Daher besteht trotz .NET die Möglichkeit, fatale Fehler zu machen, wodurch Sicherheitslücken
entstehen können. Aus diesem Grund ist es Aufgabe der Entwickler, die mitgelieferten Features richtig
einzusetzen, um Applikationen sicherer zu machen. In dieser Arbeit werden dazu typische Schwachstellen
von .NET Applikationen untersucht und diese mittels .NET Unterstützung behoben. Es wird gezeigt, was
bei den Sicherheitsfunktionen beachtet werden muss beziehungsweise welche Funktionen für welchen
Zweck geeignet sind.
Die konkrete Forschungsfrage dieser Arbeit lautet daher: Wie kann das .NET Framework sinnvoll genutzt
werden, um sichere, stabile und zukunftsorientierte Applikationen zu entwickeln?
1.3.
Aufbau der Arbeit
In Kapitel 2 wird ein fachlicher Einstieg geschaffen, damit die späteren Ansätze besser verstanden werden
können. Dabei wird ein Überblick über das Framework dargelegt und später verwendete Technologien
werden kurz angesprochen und erklärt.
Im Hauptteil wird veranschaulicht, wie das .NET Framework in den Bereichen Web Security, WCF,
Kryptographie und Deployment richtig eingesetzt werden sollte. Es werden häufige Entwicklungsfehler
aufgezeigt und dazu Best Practice Lösungen theoretisch sowie praktisch erläutert. Weiter wird im Hauptteil
der Punkt Reverse Engineering behandelt, um zu zeigen, wie einfach und gefährlich das Dekompilieren
von Anwendungen ist. Auch hierzu werden entsprechende Gegenmaßnahmen präsentiert. Damit
Anwendungen richtig bereitgestellt werden, wird ein kurzer Einblick in das Deployment von .NET
Applikationen gegeben.
Im letzten Kapitel werden die wichtigsten Punkte zusammengefasst und ein Ausblick gegeben.
7
2. Fachliches Umfeld von .NET
Das .NET Framework ist eine von Microsoft entwickelte Laufzeitumgebung, welche eine Sammlung von
Klassenbibliotheken und Programmschnittstellen enthält. Das Framework ist im vollen Umfang nur für
Windows verfügbar, jedoch gibt es Open-Source-Projekte wie Mono, welche es erlauben, .NET
Applikationen auch auf anderen Plattformen wie Linux auszuführen. [4] [5]
In den folgenden Kapiteln werden der Aufbau des Frameworks sowie .NET Technologien näher erläutert,
um die späteren Ansätze besser verstehen zu können.
2.1.
.NET Architektur
 Programmiersprachen
Bevor eine .NET Anwendung entwickelt wird, muss entschieden werden, welche Programmiersprache
eingesetzt werden soll. Das Framework wurde von Beginn an dafür entwickelt, dass Entwickler in
unterschiedlichen Programmiersprachen arbeiten können. Es kann im Prinzip jede Sprache verwendet
werden, für die es einen Language Compiler gibt, welcher die Hochsprache in die Common Intermediate
Language (CIL) übersetzen kann. Eine Liste aller Sprachen findet man unter http://www.itvisions.de/dotnet/produkte/sprachen.aspx
Die Wahl der Programmiersprache ist abhängig von den vorhandenen Programmierkenntnissen sowie
dem Einsatzbereich der zu erstellenden Anwendung. Bei Bedarf ist es auch möglich, mehrere Sprachen
in einer Anwendung zu kombinieren. [6] Alle hier gezeigten praktischen Beispiele werden mit der
Programmiersprache C# demonstriert, da mittels dieser Sprache alle Vorteile von .NET Framework
vollständig genutzt werden können.
Das .NET Framework ermöglicht die Zusammenarbeit zwischen den unterschiedlichen Sprachen,
wodurch ein Programmcode aufgerufen werden kann, der in einer anderen .NET Sprache geschrieben
worden ist. Zusätzlich können Klassen vererbt werden, die in anderen Sprachen entwickelt worden sind.
Dieser Vorteil wird durch die Common Language Specification sowie dem Common Type System (CTS)
ermöglicht. [7] Das Common Type System definiert, wie Datentypen deklariert, verwendet und in der
Common Language Runtime verwaltet werden. Dies sorgt für eine Vereinheitlichung der Datentypen,
damit diese in allen benutzten Sprachen interoperabel sind. [8]
 Anwendungstypen
Wie bereits unter 1.1 angesprochen, können mit dem .NET Framework unterschiedliche
Anwendungstypen wie Desktop Anwendungen, Konsolen Anwendungen, Web Anwendungen, Web
Services und Windows Services entwickelt werden. Je nach ausgewähltem Anwendungstyp, werden
die jeweiligen Bibliotheken aus der Framework Class Library zur Verfügung gestellt.
 Framework Class Library (FCL)
Die Framework Class Library (FCL) ist eine Sammlung von Klassen und Datentypen, welche .NET
Anwendungen zum Lesen und Schreiben von Dateien, Zugreifen auf Datenbanken, Entwerfen von
grafischen Benutzeroberflächen, Konsumieren von Web-Services usw. nutzen können. Die FCL stellt
dabei viele Funktionen der Win32-API in einfachen. NET Objekten dar, die von den .NET
Programmiersprachen verwendet werden können. [9]
8
 Common Intermediate Language (CIL)
Das .NET Framework arbeitet – genau wie die Programmiersprache Java - mit einer Zwischensprache.
Ein Compiler einer .NET Sprache erzeugt also keinen prozessorspezifischen Maschinencode, sondern
einen plattformunabhängigen Bytecode. Dieser Code wird Common Intermediate Language (CIL)
genannt – früher sprach man von der Microsoft Intermediate Language (MSIL). [10, pp. 1-2]
Erst zur Laufzeit wird der CIL-Code in einen Maschinencode (Native Code) umgewandelt. Der CIL-Code
wird dabei nicht wie bei Java interpretiert, sondern von einem sogenannten Just-in-Time-Compiler (JITCompiler) stückweise kompiliert und dann ausgeführt. Dabei berücksichtigt der JIT-Compiler
prozessorspezifische Optimierungsmöglichkeiten. Dadurch, dass nicht interpretiert, sondern vor der
Ausführung kompiliert wird und der JIT-Compiler sehr schnell arbeitet, ist der Performance-Verlust durch
die Intermediation sehr gering. [10, p. 2]
 Common Language Runtime
Die Ausführung einer .NET Anwendung setzt eine Laufzeitumgebung voraus, die sogenannte Common
Language Runtime (CLR). Die CLR stellt den JIT-Compiler und zahlreiche andere Dienste bereit, die
von allen .NET Programmiersprachen verwendet werden können. Dazu gehören zum Beispiel der
Garbage Collector, ein Exception Handling und ein Sicherheitssystem. [11]
Der Programmcode, der im Rahmen der CLR ausgeführt wird, heißt Managed Code (verwalteter Code).
Der restliche Code wird dann entsprechend Unmanaged Code (nicht-verwalteter Code) genannt.
Windows
Forms
Console
Framework
Class Library
Base
Class
Library
ADO.NET
Library
WPF,
WCF, …
Bytecode
Laufzeitumgeb
Ausführung
Language
Compiler
Anwendungst
Web
(MVC,
Service,
Common Intermediate Language
Common Language Runtime
Betriebssystem / Prozessor
Bytecode zu
Maschinecode
Sprach
C#, VBA, J#, F#, …
Common Language Specification
Common Type System
Abbildung 1: .NET Architektur
9
2.2.
Entity Framework
Übliche Client-Server Applikationen sowie Webanwendungen sind häufig mit einer Datenbank verbunden.
Bekannte Datenbanksysteme wie Oracle, MySQL und Microsoft SQL verwalten ihre Daten in Form von
Tabellen und Spalten (Relationaler Speicher), während in modernen Programmiersprachen die
Datenverwaltung mittels Klassen (Objektorientierter Speicher) durchführen wird. [12, p. 887] Um diese
beiden unterschiedlichen Speicherformen zu verbinden, können sogenannte Object-Relational Mapping
(ORM) Frameworks wie das Entity Framework (EF) verwendet werden.
Eine weitere häufige Anforderung an Anwendungen ist, dass mehrere unterschiedliche Datenbanksysteme
unterstützt werden müssen. Wird beispielsweise eine Applikation für mehrere Unternehmen entwickelt, so
kann nicht davon ausgegangen werden, dass jedes Unternehmen dieselbe Datenbank im Einsatz hat. Um
mit mehreren Datenbanken kompatibel zu sein, müssen Datenbankzugriffe üblicherweise mehrfach
geschrieben werden, da SQL Statements zwischen den Systemen unterschiedlich sind. Dies würde nicht
nur einen hohen Aufwand bedeuten, sondern auch eine Menge an Nachteile wie Unübersichtlichkeit,
Wartungsintensivität und Fehleranfälligkeit mit sich bringen. Auch hier kann das Entity Framework Abhilfe
schaffen: Das Framework unterstützt Microsoft SQL Server, Oracle, MySQL und DB2. [12, p. 885]
Das EF wurde erstmalig 2008 in das .NET Framework 3.5 integriert und seither stark weiterentwickelt. Seit
dem .NET Framework 4 wird es über den Package Manager von Visual Studio NuGet ausgeliefert:
http://www.nuget.org/packages/EntityFramework
Das Entity Framework kann in zwei verschieden Ansätzen verwendet werden:
 Code First: Für Anwendungen, für die es noch keine Datenbank gibt. Hier werden zuerst die Klassen
geschrieben, welche dann mittels ORM mit der Datenbank verbunden werden.
 Database First: Für Anwendungen, die auf eine bestehende Datenbank zugreifen. Hier werden die
Tabellen und Spalten der bestehenden Datenbank in Klassen konvertiert und mittels ORM verbunden.
Alle hier gezeigten praktischen Beispiele werden mit dem Code First Ansatz durchgeführt.
In der Abbildung 2 wird die Architektur von Entity Framework gezeigt: In der obersten Schicht befindet sich
die Anwendung, wo die Abfragen in einer datenbankunabhängigen Sprache wie LINQ (siehe 2.3) formuliert
werden. Die erstellten Statements werden dann vom Entity Client entgegengenommen und auf das Entity
Daten Model angewendet. Wenn der Bedarf besteht, auf die Datenbank zuzugreifen, wird die Abfrage an
den jeweiligen ADO.NET Provider weitergegeben. Je nach Datenbanksystem wird hier ein anderer
Provider verwendet, welcher dann die nativen SQL Befehle zur Datenbank sendet. [12, pp. 880, 881]
10
LINQ
Natives
SQL
Abbildung 2: Aufbau von Entity Framework [13]
2.3.
LINQ
Um Abfragen von der eingesetzten Datenquelle unabhängig zu machen, kann die sogenannten Language
Integrated Query (LINQ) eingesetzt werden. Hierbei handelt es sich um eine von Microsoft entwickelte
Abfragesprache, die den Zugriff auf Datenstrukturen vereinheitlicht. [14, p. 2] Dadurch macht es bei der
Entwicklung einer Anwendung keinen Unterschied, ob die Daten beispielsweise in einer Microsoft SQL
oder Oracle Datenbank gespeichert sind.
Im Unterschied zu herkömmlichen Datenbankabfragen, wo native SQL Anweisungen als String im Source
Code angegeben sind, werden LINQ Anweisungen in den Source Code eingebettet. Dadurch können
Fehler bereits beim Kompilieren und nicht erst zur Laufzeit festgestellt werden. [14, p. 14] So können Fehler
frühzeitig erkannt und behoben werden.
Beispiel einer Abfrage:
 Herkömmlich
1
SELECT * FROM Customers WHERE Country = 'Italy'
Listing 1: Herkömmliche SQL Abfrage
11
 LINQ
1
2
3
from c in Customers
where c.Country == "Italy"
select c;
Listing 2: LINQ Abfrage
Wenn man den Code aus Listing 1 und Listing 2 vergleicht, fällt auf, dass bei LINQ eine Ähnlichkeit zur
SQL Sprache besteht. Dadurch fällt es leichter, die neue Abfragesprache zu erlernen.
12
3. Web Security
Der Trend der letzten Jahre zeigt, dass Computer Applikationen häufig als Webapplikationen abgebildet
werden. Dadurch sind keine zusätzlichen Client-Installationen notwendig, die eingesetzte Anwendung ist
von überall erreichbar und Updates können zentral durchgeführt werden. Durch die hohe Verbreitung von
mobilen Geräten wie Smartphones und Tablets werden Webapplikationen weiter an Beliebtheit gewinnen,
da dadurch Anwendungen plattformunabhängig genutzt werden können.
In Gegensatz zu nativen Anwendungen können Webapplikationen in Kombination mit einem Cloud Dienst
bei hoher Auslastung automatisch auf mehrere Server skaliert werden, um alle Anfragen ohne Verzögerung
beantworten zu können. Dieser Vorgang wäre bei nativen Anwendungen nur mit sehr viel Aufwand möglich.
Da Webapplikationen bzw. Webservices in der Regel vom Internet zugänglich sind, haben
Sicherheitsmaßnahmen bei der Entwicklung höchste Priorität. Die hier erarbeiteten Sicherheitsaspekte
können sowohl für neue als auch für bestehende Webanwendungen übernommen werden.
Mit dem .NET Framework können sowohl Webanwendungen als auch Webservices erstellt werden. Bei
beiden Formen gibt es unterschiedliche Angriffspunkte, welche berücksichtigt werden müssen. Daher
werden in den nachfolgenden Unterkapiteln beide Formen behandelt.
3.1.
Cross Site Scripting (XSS)
Einer der häufigsten Angriffe auf Webapplikationen wird durch Cross Site Scripting (XSS) Attacken
durchgeführt. Diese Schwachstelle beruht auf einer fehlenden oder unzureichenden Überprüfung der Daten
vor der Ausgabe durch den Browser. Bei einem Angriff wird versucht, Script Code (z.B. JavaScript) an
einen Webserver zu senden, sodass der Schadcode beim nächsten Aufruf im Kontext des Opfers
ausgeführt wird. Im Gegensatz zu einer SQL Injection wird hier nicht die Datenbank der Webanwendung
angegriffen, sondern der Webserver bzw. der Client selbst. [15, p. 840] Dabei gibt es die drei nachfolgenden
XSS Möglichkeiten.
3.1.1. Reflected XSS
Hierbei handelt es sich um einen nicht-persistenten XSS Angriff, bei dem eine Benutzereingabe direkt vom
Server wieder zurückgeschickt wird. Da die Eingaben dabei nicht gespeichert werden, kann ein Code nur
einmal zur Ausführung kommen. [16]
Durch das nachfolgende Beispiel soll die Schwachstelle demonstriert werden:
 Auf einer Webseite gibt es eine Liste, welche durch einen Suchfilter eingeschränkt werden kann. Dabei
werden die eingegebenen Suchbegriffe zur Übersichtlichkeit wieder ausgegeben:
13
Abbildung 3: Webseite für Reflected XSS Angriff
 Beim Klicken auf den „Filter“ Button werden im Query String die Suchparameter angegeben:
http://<domain>/Mile?searchEventName=XSS&searchEventType=
 Um nun eine Reflacted XSS Attacke durchzuführen, könnte man einen Skript Code in den Query String
einfügen und diese präparierte URL per E-Mail versenden:
http://<domain>/Mile?searchEventName=<script>alert(“Reflected XSS
Attacke“);</script>&searchEventType=
 Der Aufruf dieses Links würde zum folgenden Ergebnis führen
Abbildung 4: Ergebnis eines Relected XSS Angriffs
Damit diese Schwachstelle in .NET Webapplikationen verhindert wird, müssen folgende Aktionen
durchgeführt werden:
 View
Um einen Inhalt vom Server auszugeben,
@Html.Raw(ViewBag.SearchInput)
wird
häufig
folgende
Form
verwendet:
Durch das @Html.Raw (...) wird der übergebene Inhalt eins zu eins an den Browser
weitergegeben, wodurch ein Browser einen Script Code interpretieren würde. Um dies zu verhindern,
14
muss der Inhalt kodiert werden, um
darstellbare HTML Tags zu ersetzen:
„<“  <
„>“  >
typische Zeichen eines Scripts, wie z.B „<“ oder „>“ durch
Dies kann durch folgenden Code erreicht werden:
1
<b>Results for:</b> @Html.Encode(ViewBag.SearchInput)
Listing 3: Verhindern von gefährlichen Ausgaben in der View
 Controller
Beim Controller darf auf keinen Fall das Methoden Attribut [ValidateInput(false)] gesetzt sein.
Wenn dieses Attribut nicht beziehungsweise auf True gesetzt ist, werden die übergebenen Parameter
auf Script Code überprüft. Sobald ein verdächtiger Inhalt übergeben wird, wird automatisch eine
Exception ausgelöst.
1
2
3
4
5
[ValidateInput(true)]
public ActionResult Index(string searchEventType, string searchEventName)
{
…
}
Listing 4: Verhindern von gefährlichen Eingaben am Controller
3.1.2. Stored XSS
Im Unterschied zur Reflected XSS wird bei der Stored XSS der Schadcode auf dem Webserver bzw. in der
Datenbank der Webapplikation gespeichert, wodurch er bei jeder Anfrage zurückgeliefert wird und zur
Ausführung kommen kann. [16] Da der Schadcode mehrmals zur Ausführung kommen kann, ist dieser
Angriff wesentlich gefährlicher als bei Reflected XSS.
Store XSS Attacken sind möglich, sobald eine Webapplikation Benutzerdaten entgegennimmt und ohne
Prüfung speichert und diese später wieder ausliefert.
Das nachfolgende Beispiel soll die Schwachstelle praktisch demonstrieren:
 Auf einer Webseite können Benutzereingaben an den Server gesendet werden. Hier wird in unserem
Fall ein einfacher JavaScript Code eingegeben und übermittelt.
15
Abbildung 5: Eingabe für eine Stored XSS Attacke
 Sobald die neuen Daten abgefragt werden, kommt der JavaScript Code zur Ausführung
Abbildung 6: Ausführung eines Stored XSS Code
Natürlich würde ein geschickter Angreifer anstelle des Öffnens eines Popup eine andere Aktion
durchführen, wie beispielsweise die Cookies auslesen. Dadurch könnte ein Angreifer beispielsweise die
Session eines anderen Benutzers übernehmen.
Um diese Schwachstelle in .NET Webapplikationen zu verhindern, müssen dieselben Gegenmaßnahmen
wie bei den Reflected XSS durchgeführt werden (siehe 3.1.1). Weiters müssen sichere Methoden für den
Datenbankzugriff verwendet werden (siehe 3.2.2)
 View
Alle Ausgaben kodieren. Dadurch werden Script Tags in HTML Tags umgewandelt und werden somit
nicht ausgeführt, sondern dargestellt.
 Controller
Auf keinen Fall das Attribut [ValidateInput(false)]
weglassen oder den Parameter auf True setzen.
setzen, sondern entweder das Attribut
16
3.1.3. DOM based XSS
Diese Attacke ist völlig unabhängig vom Webserver der Webseite. Daher können auch statische Webseiten
betroffen sein. Bei DOM based XSS wird der Schadcode direkt an den Client übergeben und dort zur
Ausführung gebracht, ohne eine Anfrage an den Webserver zu stellen. Dazu könnte beispielsweise der
Query String einer URL so verändert werden, dass ein Script Code im Kontext des Opfers ausgeführt wird.
[16]
Da es sich hierbei um eine Schwachstelle am Client handelt, gibt es von .NET keine Gegenmaßnahmen.
Um der Schwachstelle entgegen zu wirken, müssen alle am Client verarbeiteten Daten überprüft bzw.
kodiert werden.
3.2.
SQL Injection
Eine SQL Injection ist eine Attacke gegen Datenbank-basierte Applikationen. Erfolgreiche Angriffe können
es einem Angreifer ermöglichen, sich unerlaubt in eine Web-Applikation mit Zugriffsschutz einzuloggen,
private Informationen aus einer Datenbank zu entwenden oder Daten zu manipulieren. [17]
Der Angreifer versucht dabei, Benutzereingaben so zu formulieren, dass diese Eingaben die
Datenbankabfrage verändern, um eigene SQL Anweisungen an die Datenbank zu senden. Der Angriff wird
möglich, wenn Eingaben ohne Überprüfungen in die Abfragen übernommen werden.
3.2.1. Unsichere Datenbankzugriffe
Es gibt mehrere Möglichkeiten, um aus einer .NET Anwendung auf eine Datenbank zuzugreifen. Einige
sind jedoch bereits veraltet und sollten auf keinen Falls mehr benutzt werden.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// create and open SQL connection
var connection = new SqlConnection();
connection.ConnectionString =
ConfigurationManager.ConnectionStrings["ConnString"].ConnectionString;
connection.Open();
// generate select statement
string query = "SELECT m.Id, m.Name, m.Amount, m.IsAccepted, m.Comment,
e.Name, u.Username";
query += " FROM Miles m INNER JOIN EventTypes e on m.Type_Id = e.Id";
query += " INNER JOIN ApplicationUsers u on m.User_Id = u.Id";
List<string> whereStatements = new List<string>();
if (!IsAdmin)
whereStatements.Add("m.User_Id = " + <UserId> + "");
if (!string.IsNullOrEmpty(searchEventName))
whereStatements.Add("m.Name LIKE '%" + searchEventName + "%'");
17
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
if (!string.IsNullOrEmpty(searchEventType))
whereStatements.Add("m.Type_Id = '" + searchEventType + "'");
for (int i = 0; i < whereStatements.Count; i++)
{
if (i == 0)
query += " WHERE ";
else
query += " AND ";
query += whereStatements[i];
}
// execute select statement
SqlCommand command = new SqlCommand(query, connection);
SqlDataReader reader = command.ExecuteReader();
// process data
// ...
Listing 5: Unsicherer Datenbankzugriff
Im Beispiel von Listing 5 werden folgende Aktionen durchgeführt:
 Zeile 3 – 6: Die Datenbankverbindung wird instanziiert und mit den Verbindungsdaten konfiguriert,
welche aus der web.config ausgelesen werden. Weiteres wird die Verbindung zum Datenbankserver
geöffnet.
 Zeile 9 - 12: Das Select Statement wird zusammengestellt.
 Zeile 14 – 32: Es wird überprüft, ob ein Filter angegeben wurde. Wenn ja, wird ein entsprechendes
Where Statement zur SQL Anweisung hinzugefügt.
 Zeile 35: Es wird ein SqlCommand Objekt angelegt und mit der Datenbankverbindung sowie dem Select
Statement initialisiert.
 Zeile 36: Das Select Statement wird zur Datenbank gesendet und ausgeführt. Die zurückgelieferten
Daten werden im SqlDataReader Objekt abgespeichert.
Der Code von Listing 5 kann folgendermaßen angegriffen werden:
 Sobald die Seite aufgerufen wird, welche die SQL Anweisung von Listing 5 ausführt, werden nur die
eigenen Einträge angezeigt.
Abbildung 7: Nicht ausgeführte SQL Injection
18
 Nun kann ein Suchbegriff so formuliert werden, dass damit die SQL Anweisung manipuliert wird und
alle Einträge ausgibt. Es könnte beispielsweise nach irgendetwas' or 1=1 -– gesucht werden.
Dadurch würde die Variable „query“ von Listing 5 folgenden Inhalt bekommen:
SELECT m.Id, m.Name, m.Amount, m.IsAccepted, m.Comment, e.Name, u.Username
FROM Miles m INNER JOIN EventTypes e on m.Type_Id = e.Id INNER JOIN
ApplicationUsers u on m.User_Id = u.Id WHERE m.User_Id = 2 AND m.Name LIKE
'%irgendetwas' or 1=1--%'
Da die Zeichen „%‘" am Ende mittels „--" auskommentiert werden, werden diese nicht vom SQL Server
ausgeführt, wodurch es zu keinem Syntaxfehler kommt. Daher steht am Schluss der Anweisung 1=1,
was immer True liefert und somit auf jede Zeile zutrifft.
Abbildung 8: Ausgeführte SQL Injection
Damit ein solcher Angriff verhindert werden kann, muss der Zugriff auf die Datenbank geändert werden.
Dazu gibt es zwei Möglichkeiten, welche im nächsten Kapitel erklärt werden.
3.2.2. Sichere Datenbankzugriffe
Um in .NET Anwendungen mit einer Datenbank zu kommunizieren, wird seitens Microsoft das Entity
Framework empfohlen. [18] Wie unter 2.2 beschrieben bietet dieses ORM Framework nicht nur
sicherheitsrelevante Vorteile, sondern beschleunigt und erleichtert zusätzlich die Entwicklung. Um den
unsicheren Datenbankzugriff aus Listing 5 nun mit dem Entity Framework durchzuführen, muss folgender
Code geschrieben werden:
1
2
3
4
5
6
7
8
9
10
ApplicationDbContext context = new ApplicationDbContext();
IQueryable<Mile> miles = context.Mile.AsQueryable();
if (!string.IsNullOrEmpty(searchEventName))
miles = miles.Where(m => m.Name.Contains(searchEventName));
if (!string.IsNullOrEmpty(searchEventType))
miles = miles.Where(m => m.Type.Id.Equals(searchEventType));
if (!IsAdmin)
miles = miles.Where(m => m.User.Id.Equals(<UserId>));
return View(miles.ToList());
19
Listing 6: Entity Framework - LINQ Abfrage
Im Beispiel von Listing 6 werden folgende Aktionen durchgeführt:
 Zeile 1: Es wird eine Instanz von der Klasse ApplicationDbContext erzeugt. Diese Klasse ist von
DBContext abgeleitet und verfügt über Informationen, wie die Datenbankverbindung, Metadaten des
Datenmodels sowie eine Änderungsverfolgung.
 Zeile 2: Es wird ein Queryable Object mit dem Type Mile erzeugt. Mithilfe dieses Objekts können
LINQ Abfragen erstellt werden. Hier werden noch keine Daten von der Datenbank abgefragt.
 Zeile 3 – 8: Es wird überprüft, ob ein Filter gesetzt wurde. Wenn ja, wird ein entsprechendes LINQ
Statement angegeben. Auch hier werden noch keine Daten von der Datenbank abgefragt.
 Zeile 10: Erst durch die Methode ToList() wird die SQL Anweisung ausgeführt und die Ergebnisse
werden zurückgeliefert.
Wenn man mit älteren .NET Frameworks (< 3.5 SP1) arbeitet, kann das Entity Framework nicht genutzt
werden. [19] Jedoch gibt es auch eine andere Technik zum Verhindern von SQL Injections: Anstatt die
Benutzereingaben direkt in die Anweisung einzufügen, kann die Klasse SqlParameter verwendet
werden. Dabei werden in der SQL Anweisung Variablen definiert, welche zu einem späteren Zeitpunkt
durch die entsprechenden Werte (Benutzereingaben) ersetzt werden. [20]
 Nicht parametrisiert
1
2
queryString = "SELECT * FROM Miles WHERE User_Id =‘" + userId + "‘ AND
Name LIKE ‘%" + name + "%‘"
Listing 7: Nicht parametrisierte SQL Anweisung
 Parametrisiert
1
2
3
4
queryString = "SELECT * FROM Miles WHERE Username=@ID AND Name LIKE
@NAME";
command.Parameters.AddWithValue("@ID", userId);
command.Parameters.AddWithValue("@NAME ", name);
Listing 8: Parametrisierte SQL Anweisung
In Listing 7 wird die SQL Anweisung mit einer Zeichenkettenoperation zusammengestellt, wodurch eine
SQL Injection möglich wird. Daher sollte die Anweisung mittels Parameter, wie in Listing 8 gezeigt, erstellt
werden. In den Zeilen 1 – 2 werden die beiden Variablen „ID“ und „Name“ gesetzt. In den Zeilen 3 – 4
werden diese dann durch die entsprechenden Werte ersetzt.
3.2.3. Informationen einer Datenbank ermitteln
Um komplexere SQL Injections durchführen zu können, muss das Schema der Zieldatenbank bekannt sein.
Das bedeutet, der Angreifer muss wissen, wie die Tabellen heißen, welche Spalten diese besitzen und wie
diese zusammenhängen (Relationen). Da dem Angreifer jedoch in den meisten Fällen das
20
Datenbankschema nicht
herauszufinden:
bekannt ist, wird versucht, dieses mit den nachfolgenden Methoden
 Analysieren von Fehlermeldungen
Bei dieser Methode werden fehlerhafte SQL Anweisungen generiert, um aussagekräftige
Fehlermeldungen zu produzieren. Anhand solcher Fehlermeldungen können Tabellennamen,
Spaltennamen oder Datentypen entnommen werden. Um dies bei .NET Webapplikationen zu
verhindern, sollte immer folgender Eintrag in der web.config vorgenommen werden:
1
2
3
4
5
6
7
8
9
10
<configuration>
<system.web>
<customErrors defaultRedirect="MyErrorPage.htm"
mode="RemoteOnly">
<error statusCode="500"
redirect="InternalError.htm"/>
</customErrors>
</system.web>
</configuration>
Listing 9: Benutzerdefinierte Fehlermeldungen
Dadurch wird bei einem Fehler eine benutzerdefinierte Fehlermeldung ausgegeben. Diese sollte keine
technischen Informationen enthalten, sondern nur darüber informieren, dass ein Fehler aufgetreten ist. Im
Listing 9 wird in der Zeile 3 die Webseite angegeben, welche diese Fehlermeldung enthält. In der Zeile 4
wir angegeben, dass benutzerdefinierte Fehlermeldungen nur für Remoteclients ausgegeben werden. So
werden ASP.NET-Fehlermeldungen weiterhin für den lokalen Host angezeigt, wodurch Administratoren
oder Entwickler die detaillierten Fehlermeldungen erhalten. Wie man in den Zeile 6 – 7 sehen kann, können
für bestimmte Fehlertypen unterschiedliche Fehlerseiten verwendet werden.
 Blind SQL
Wenn Webapplikationen entweder keine detaillierten Fehlermeldungen liefern, beziehungsweise bei
Fehlern gar keine Daten ausgeben (z.B. eine leere Liste), dann können Informationen mithilfe von Blind
SQL Injections ermittelt werden. Bei dieser Methode werden systematisch unterschiedliche Kombinationen
von Anweisungen ausprobiert und danach die Antworten ausgewertet. [21]
Wie in der Abbildung 8 zu sehen ist, konnte eine SQL Injection bereits erfolgreich durchgeführt werden.
Doch wir haben noch keine Informationen über die Datenbank selbst erhalten. Wenn wir zum Beispiel
wissen möchten, wie viele Spalten beim Filtern der Liste aus Abbildung 8 abgefragt werden, müssten wir
zunächst folgende Anfragen generieren:
21
Listing 10: Blind SQL Injection – Anzahl der Spalten ermitteln
Da die Daten ohne einer Fehlermeldung ausgegeben werden, wissen wir, dass die SQL Anweisung
erfolgreich durchgeführt worden ist. Daher fahren wir mit folgenden Anweisungen fort:
xyz'
xyz'
xyz'
xyz'
xyz'
xyz'
xyz'
order
order
order
order
order
order
order
by
by
by
by
by
by
by
2
3
4
5
6
7
8
--------
// Kein Fehler
// Kein Fehler
// Kein Fehler
// Kein Fehler
// Kein Fehler
// Kein Fehler
// Fehler
Wir wissen jetzt, dass die Abfrage aus sieben Spalten besteht. Diese Information benötigen wir für die
nachfolgenden Schritte.
Auf einer MS SQL Datenbank kann der aktuelle Datenbankname mit folgender Anweisung abgefragt
werden:
SELECT DB_NAME()
Da wir nun wissen, wie viele Spalten die Abfrage hat und wie wir den aktuellen Namen der Datenbank
auslesen, probieren wir die folgende Anweisung:
xyz' union all SELECT DB_NAME(),null,null,null,null,null, null -Mit UNION vereinen wir die Ausgabe der ersten und zweiten Abfrage, wobei die zweite Abfrage den
Datenbanknamen ausgibt. Da die Anzahl der Spalten bei beiden Abfragen ident sein muss, werden die
restlichen sechs Spalten mit null befüllt. Der Befehl lieferte jedoch leider eine leere Ausgabe. Der Grund
dafür könnte sein, dass die erste Spalte nicht für die Ausgabe verwendet wird (es handelt sich
wahrscheinlich um eine ID). Aus diesem Grund geben wir den Datenbanknamen in der zweiten Spalte aus:
xyz' union all SELECT null, DB_NAME(),null,null,null,null, null --
22
Abbildung 9: Blind SQL Injection - Datenbanknamen ermitteln
Wie in Abbildung 9 ersichtlich, konnte der Datenbankname erfolgreich ermittelt werden. Nun können eine
Reihe weitere Informationen abgefragt werden:
Alle Tabellennamen ermitteln:
xyz' union all SELECT null,name,null,null,null,null, null FROM
WebSecurity..sysobjects WHERE xtype = 'U' -Alle Spalten der Tabelle Miles ermitteln:
xyz' union all SELECT null,COLUMN_NAME,null,null,null,null, null FROM
information_schema.columns WHERE table_name = 'Miles' -Wie man sehen kann, hat man beinahe alle Möglichkeiten, um auf die Datenbank zuzugreifen. Es ist aber
auch möglich, Datensätze zu löschen oder zu verändern.
Alle Einträge aus der Tabelle Miles löschen:
xyz'; DELETE FROM Miles -Um alle diese Angriffe zu unterbinden, müssen die Datenbankzugriffe entweder parametrisiert oder mittels
Entity Framework durchgeführt werden. (siehe 3.2.2)
3.3.
Direct Object Reference
Bei Webanwendungen werden Referenzen/Verweise verwendet, um auf bestimmte Objekte zuzugreifen.
Dabei kann es sich um Dateien, Verzeichnisse oder Datenbankeinträge handeln. Bei einer Insecure Direct
Object Reference kann der Verweis auf diese Objekte vom Angreifer manipuliert werden, um so Zugriff auf
nicht berechtigte Inhalte zu bekommen.
Vor allem wenn Applikationen mit sensiblen Daten arbeiten, sind diese Attacken gefährlich. Konkret
verwenden Angreifer meist manipulierte IDs oder Pfadangaben, um etwa fremde Datensätze aus der
Datenbank auszulesen. [22]
23
Das nachfolgende Beispiel soll die Schwachstelle demonstrieren:
 In einer Webapplikation kann ein angemeldeter Benutzer eine Übersicht über alle seine getätigten
Transaktionen abrufen. Dazu wird folgende URL aufgerufen:
http://<domain>/Account/TransactionList/3
 An der URL lässt sich feststellen, dass im Query String der Wert 3 übergeben wird. In ASP.NET kann
ein Default Parameter definiert werden, wodurch nur mehr der Wert angegeben werden muss. Wenn
zum Beispiel „id“ als Default Parameter definiert wurde, dann würden die zwei nachfolgende Aufrufe
zum selben Ziel führen:
http://<domain>/Account/TransactionList/3
http://<domain>/Account/TransactionList?id=3
 Um eine Insecure Direct Object Reference Attacke durchzuführen, muss lediglich ein anderer Wert
übergeben werden. Wenn man dadurch Zugriff auf den Inhalt eines anderen Benutzers bekommt, so
war der Angriff erfolgreich. Beispiel für Aufruf:
http://<domain>/Account/TransactionList?id=4
Damit diese Schwachstelle in .NET Webapplikationen verhindert wird, sind folgende Mechanismen
möglich:
 Eindeutig identifizierbare Objekte sollten immer mit einem Globally Unique Identifier (GUID) adressiert
werden. Dabei handelt es sich um eine 128 Bit lange Zeichenfolge, wodurch es 2128 (= 340 Sextillionen)
Möglichkeiten gibt. [23] Die Wahrscheinlichkeit für eine Kollision ist somit sehr gering.
GUIDs werden üblicherweise im Format XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX dargestellt,
wobei jedes ‘X’ für einen hexadezimalen Wert (0-9 oder A-F) steht.
Dadurch würde der Aufruf folgendermaßen aussehen:
http://<domain>/Account/TransactionList?id= aa6cd0a0-fd0a-4fdd-8bb5dc155e1f3a59
 Zusätzlich sollte auf der Serverseite überprüft werden, ob der aktuelle Benutzer für die angefragte
Ressource berechtigt ist. Wenn der Zugriff nicht erlaubt ist, sollte der HTTP Code 403 (Forbidden)
zurückgeliefert werden.
Um beispielsweise in .NET sicherzustellen, dass eine Ressource nur für Benutzer mit der Admin Rolle
sowie für den eigenen Benutzer bereitgestellt wird, kann folgender Code angewendet werden:
1
2
3
if (!User.IsInRole(“admin“) && !User.Identity.GetUserId().Equals(id))
throw new HttpException((int)HttpStatusCode.Unauthorized,
„Forbidden");
Listing 11: Berechtigung für Direct Object Reference überprüfen
24
Die Variable „id“ enthält die ID für die angeforderte Ressource. In diesem Beispiel (Listing 11) wird hier
die ID eines Benutzers angegeben.
3.4.
Cross-Site-Request-Forgery (CSRF)
Eine Cross-Site-Request-Forgery (CSRF) ist eine weitere Angriffsmöglichkeit auf eine Webapplikation, um
Aktionen im Kontext einer anderen Person (Opfer) durchzuführen. Dabei nutzt ein Angreifer die Session
seines Opfers zum Senden von manipulierten Anfragen (POST Requests) an den Webserver. Um eine
solche Attacke erfolgreich auszuführen, muss also ein angemeldeter Benutzer dazu gebracht werden, die
präparierten Request an den Server zu schicken. [24] Dazu stehen folgende Möglichkeiten offen:
 Cross-Site-Scripting: Wenn eine Webanwendung eine XSS Schwachstelle besitzt, kann der Angreifer
ein HTML oder einen JavaScript Code einschleusen, welcher die entsprechenden POST Requests
durchführt. Der Code würde bei einer späteren Anfrage im Kontext des aufgerufenen Benutzers
ausgeführt werden. Nähere Informationen zu XSS können unter 3.1 nachgelesen werden.
 URL: Ist eine Webapplikation nicht XSS anfällig, so können die manipulierten Requests auch über eine
eigene Webseite bereitgestellt werden. Die Webseite muss nicht einmal Teil der betroffenen
Webapplikation sein, sondern kann unter einer anderen Adresse bzw. Domain bereitgestellt werden.
Die URL der präparierten Seite wird üblicherweise per E-Mail oder über Sozial Media verteilt. Im
Gegensatz zu XSS muss der Angreifer hier das Opfer aktiv dazu bringen, die Webseite aufzurufen.
 Lokale Schadsoftware: Wenn es möglich ist, eine Schadsoftware auf dem Computersystem des Opfers
zu installieren, welches Zugriff auf den Browser hat, kann die Attacke auch durch den installierten
Schadcode durchgeführt werden. Dieser muss den Browser dazu bringen, die präparierte Webseite
aufzurufen.
Das nachfolgende Beispiel soll die Schwachstelle praktisch demonstrieren:
 Auf einer Webseite können angemeldete Benutzer ihre gesammelten Meilen (Punkte) an andere
Benutzer übertragen. Die Meilen werden dann vom eigenen Kontostand abgebucht und beim anderen
Benutzer gutgeschrieben.
Abbildung 10: CSRF anfällige Webapplikation
25
 Um eine CSRF durchzuführen, muss ermittelt werden, welche Daten an den Webserver übertragen
werden. Dazu einfach den dazugehörigen HTML Code analysieren:
1
2
3
4
5
6
7
<form action="/Donation/Create" method="post">
<label>Amount</label>
<input id="Amount" name="Amount" type="text" value="0" />
...
</form>
Listing 12:HTML Code der CSRF anfälligen Webseite
Wie man in Listing 12 sehen kann, finden man im HTML Code alle notwendigen Informationen:
 an welche Adresse die Daten gesendet werden: <domain>/Donation/Create
 welche Daten übertragen werden: Alle input Tags innerhalb des form Tags
 Da nun alle notwendigen Informationen bekannt sind, kann eine eigene Webseite erstellt werden,
welche den POST Request schickt:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
<html>
<head>
<title>Invitation</title>
</head>
<body style="background-color:#EDECEC">
<image src="invitation.jpg" width="150" height="100" /><br />
<form action="<domain>/Donation/Create" method="post">
<input type="hidden" id="Amount" name="Amount" value="200" />
<input type="hidden" id="Receiver" name="Receiver " value="user2" />
<input type="submit" value="Show details" />
</form>
</body>
</html>
Listing 13: CSRF präparierte Webseite
 Zeile 8: Es wird eine Einladung als Grafik angezeigt. Dem Opfer soll dadurch vermittelt werden, dass
er sich auf einer Webseite befindet, wo er Informationen zu einer Einladung findet.
 Zeile 10 – 14: Die Daten für die Anfrage werden angegeben. Die Input Tags die den Type hidden
besitzen, werden nicht angezeigt. So fällt dem Opfer nicht auf, dass Daten mit seiner Identität versendet
werden.
Auf der Webseite ist nun der nachfolgende Inhalt (siehe Abbildung 11) zu sehen. Beim Klick auf „Show
details“ werden die Daten an den Webserver geschickt, wodurch sich der Benutzer „user2“ 200 Meilen
vom aktuellen eingeloggten Benutzer überträgt.
26
Abbildung 11: Inhalt der CSRF präparierten Webseite
Um dieser Schwachstelle Herr zu werden, muss im form Tag des POST Request ein Token angehängt
werden. Zusätzlich muss der idente Token auch in den Cookies abgespeichert werden. Sobald die Daten
an den Server gesendet werden, kann serverseitig überprüft werden, ob der Token im Formular und der
von den Cookies ident sind. Wenn ja, ist sichergestellt, dass die Daten nicht von einem Dritten geschickt
wurden. Um diesen Schutzmechanismus in einer .NET Webapplikation zu implementieren, sind die
folgenden Schritte notwendig: [25]
 View
Das Framework besitzt die Hilfsfunktion AntiForgeryToken(), welche am Client einen Token im
Formular sowie in den Cookies setzt. Die View muss dazu folgendermaßen erstellt werden:
1
2
3
4
5
6
@using (Html.BeginForm())
{
@Html.AntiForgeryToken()
...
}
Listing 14: Implementieren der AntiForgeryToken() Funktion
Durch diese Anweisung wird an den Client folgender HTML Code ausgeliefert:
1
2
3
4
<form action="/Donation/Create" method="post">
<input name="__RequestVerificationToken" type="hidden"
value="Jnr7YTsjVA11BrR3FOs5_fwiKKx3GsDongdLUfWDuwWJVvIz18nQ15_EBrsE35b79zNxF-NLFrcu16TYFd7ms5_GOQ-rVvXcFtu9-J--0Q1" />
Listing 15: HTML Code durch die AntiForgeryToken() Funktion
Zusätzlich wird folgender Token in den Cookies gesetzt:
27
Abbildung 12: Cookie durch die AntiForgeryToken() Funktion
 Controller
Um nun serverseitig zu überprüfen, ob der Token im Formular und der in den Cookies gleich ist, muss
bei der entsprechenden Methode das Attribut [ValidateAntiForgeryToken] gesetzt werden. Der
Methodenkopf würde folgendermaßen aussehen:
1
2
3
4
5
6
[HttpPost]
[ValidateAntiForgeryToken]
public ActionResult Create(CreateDonateViewModel donatemile)
{
...
}
Listing 16: Attribut zum Überprüfen des CSRF Token
Mit den beiden Attributen aus Listing 16 wird sichergestellt, dass es sich um einen POST Request
handeln muss, bei welchem der Token im Formular und in den Cookies gleich ist. Sollte der Token nicht
gesetzt bzw. korrekt sein, so wird eine Exception mit der Nachricht „A required anti-forgery token was
not supplied or was invalid” ausgelöst.
3.5.
Authentifizierung
Mit dem .NET Framework gibt es verschiedene Möglichkeiten, um einen Authentifizierungsprozess
durchzuführen. Dabei kümmern sich die mitgelieferten Bibliotheken standardmäßig um viele
sicherheitsrelevante Angelegenheiten, wie zum Beispiel das Erstellen von sicheren Cookies am Client. [26]
Beim Entwickeln von .NET Anwendungen sollte man immer auf die zur Verfügung stehenden Bibliotheken
zurückgreifen und nicht selbst den Authentifizierungsprozess entwickeln, da es sich hierbei um einen sehr
kritischen Vorgang handelt. Es müssen eine Reihe an Sicherheitsaspekten erfüllt werden, um resistent
gegen Angriffe zu sein. Da die mitgelieferten Bibliotheken auch von vielen anderen Entwicklern eingesetzt
werden, sind diese weit verbreitet und haben sich dadurch bewährt.
In .NET Anwendungen stehen mehrere unterschiedliche Authentifizierungsmöglichkeiten zur Verfügung.
Abhängig vom Speicherort der Zugangsdaten muss die passende Form gewählt werden. Dabei werden
folgende Möglichkeiten angeboten: [26]
 Individual Accounts
Diese Authentifizierungsart muss gewählt werden, wenn die Zugangsinformationen in einer eigenen
Datenbank gespeichert werden. Ein Benutzer kann sowohl mittels Benutzername und Passwort
registriert werden als auch über eine Anmeldung an einem externen Anbieter wie Facebook, Google,
28
Microsoft oder Twitter. Bei dieser Auswahl wird ASP.NET Identity (auch als
eingesetzt, welche alle notwendigen Methoden und Attribute bereitstellt.
ASP Membership)
 Organizational Accounts
Wenn die Benutzerdaten in Azure Active Directory oder Windows Server Active Directory gespeichert
sind, so muss die sogenannte Organizational Authentication gewählt werden. Dadurch können bereits
bestehende Benutzerdaten für den Zugriff auf eine Webapplikation verwendet werden.
 Windows Authentication
Diese Authentifizierungsform ist für eine Webapplikation im Intranet gedacht. Dabei wird ein SingleSign-On (SSO) vom lokal angemeldeten Windows Benutzer durchgeführt.
Da bei Webapplikationen am häufigsten die Individual Accounts verwendet werden, wird deren
Funktionalität hier genauer erläutert. Detaillierte Informationen über die anderen Formen können unter
http://www.asp.net/aspnet/overview/authentication-and-identity nachgelesen werden.
Beim Verwenden von Individual Accounts wird die ASP.NET Forms Authentication eingesetzt, bei welcher
der Authentifizierungsvorgang aus drei Komponenten besteht:
 User Agent (Browser)
 Forms Authentication Middleware
 Webapplikation
Sobald zum ersten Mal auf eine geschützte Ressource zugegriffen wird, wird der Benutzer auf die Login
Seite umgeleitet. Nachdem der Benutzer die Zugangsdaten eingegeben hat, werden diese von der
Anwendung überprüft und die User Claims erstellt, welche den Benutzernamen und die Rollen des
Benutzers enthalten. Danach werden diese von der Middleware verschlüsselt, kodiert und in ein Ticket
umgewandelt und als Cookie zum Client gesendet. Bei den nächsten Zugriffen wird dieses Ticket von der
Middleware verifiziert, zurück konvertiert und als HttpContext.User Objekt abgespeichert. Über dieses
Objekt kann in der Webapplikation auf den aktuellen Benutzer sowie dessen Rollenmitgliedschaft
zugegriffen werden. [27] Der Ablauf wird in der Tabelle 1 veranschaulicht.
User Agent (Browser)
Forms Authentication
Middleware
Webapplikation
1. Ressource wird aufgerufen
Get /Account/Manage
----------------------->
2. Response Status 401
Da die Ressource eine
Authentifizierung verlangt, wird der
HTTP Code 401 (Client
Unauthorized) zurückgeliefert
<------------401----------3. Die Middleware
konvertiert den HTTP
Code zu 302 (Redirect
29
found) und leitet den
Client zur Login Seite um
<-----------302---------4. Login Seite wird aufgerufen
GET /Account/Login?
ReturnUrl=/Account/Manage
----------------------->
5. Login Seite wird zurückgeliefert
<------------200----------6. Benutzername und
Passwort werden zum Server
gesendet
POST /Account/Login?
ReturnUrl=/Account/Manage
----------------------->
7. Die Webapplikation führt folgende
Aktionen durch
-überprüft die Credentials
- führt die Methode
IdentityAuthenticationManager.SignIn
aus
- leitet den Client auf die ReturnUrl
um
<------------301----------8. Die Middleware
konvertiert die User
Claims in einen Token
und setzt diesen als
Cookie beim Client
<-----------302---------9. Ressource erneut
anfordern, jedoch mit
gesetzten Token in den
Cookies
----------------------->
10. Die Middleware
überprüft und konvertiert
den Token zurück.
----------------------->
Webapplikation erkennt, dass
Benutzer authentifiziert ist und liefert
daher die Ressource zurück.
<------------200----------Tabelle 1: Ablauf einer Forms Authentication [27]
30
Der Vorgang für die Authentifizierung mit einem externen Provider wie Facebook, Google, Microsoft oder
Twitter ist ein klein wenig
anders als in Tabelle 1 gezeigt [27]. Der hierfür notwendige
Authentifizierungsprozess kann unter http://blogs.msdn.com/b/webdev/archive/2013/07/03/understandingowin-forms-authentication-in-mvc-5.aspx nachgelesen werden.
Um den Authentifizierungsprozess aus der Tabelle 1 zu implementieren, sind nur wenige Schritte
notwendig:
 Eine geschützte Ressource muss mit dem Attribut Authorize versehen werden. Dieses Attribut kann
sowohl auf eine Methode als auch auf einen Controller angewendet werden. Wenn nur eine bestimmte
Gruppe auf die Ressource zugreifen darf, so kann auch der Parameter Roles angegeben werden
(siehe Listing 17)
1
2
3
4
5
[Authorize(Roles = „admin“)]
public ActionResult ResetPassword(string id, MessageStates? message)
{
...
}
Listing 17: Authorize Attribut
 Nachdem der Benutzer die Zugangsdaten (Benutzername und Passwort) angegeben hat, müssen diese
überprüft werden. Sind diese korrekt, so werden die User Claims erstellt und der Benutzer angemeldet.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
var user = UserManager.Find(model.UserName, model.Password);
if (user != null)
{
var identity = UserManager.CreateIdentity(user,
DefaultAuthenticationTypes.ApplicationCookie);
AuthenticationManager.SignIn(new AuthenticationProperties() {
IsPersistent = isPersistent }, identity);
return RedirectToLocal(returnUrl);
}
else
{
ModelState.AddModelError("", "Invalid username or password.");
}
Listing 18: Implementierung der Forms Authentication
In Listing 18 werden folgende Aktionen durchgeführt:
 Zeile 1 - 2: Es wird überprüft, ob die Kombination von Benutzername und Passwort in der Datenbank
vorhanden ist. Damit das Objekt UserManager einen Zugriff auf die Datenbank hat, muss es zuvor
mit dem Entity Framework Kontext initialisiert werden.
 Zeile 4 – 5: Da der Benutzer gültige Zugangsdaten angegeben hat, werden die User Claims
abgefragt. Diese bestehen aus dem Benutzernamen und den dazugehörigen Rollen/Gruppen.
 Zeile 7 – 8: Die User Claims werden an die Middleware übergeben. Zusätzlich wird mitgeteilt, ob der
Benutzer die Checkbox „Angemeldet bleiben“ aktiviert hat.
31
 Zeile 10: Der Benutzer wird zur gewünschten Ressource geleitet.
 Zeile 14: Wenn der Benutzer ungültige Zugangsdaten eingegeben hat, wird eine entsprechende
Fehlermeldung zurückgeliefert.
3.6.
ASP.NET Web API
Bei ASP.NET Web API handelt es sich um ein typisches Webservice. Ein Webservice ist eine
Softwareanwendung, welche für die direkte Maschine-zu-Maschine (M2M) Kommunikation verwendet wird.
Dabei wird der Dienst von einem Webserver betrieben. Da der Zugriff über standardisierte Protokolle wie
HTTP und XML gesteuert wird, können solche Dienste für die Kommunikation in heterogenen Netzwerken
eingesetzt werden. [28] Häufig werden Webservices als Schnittstelle zwischen den Clients und einer
Datenbank verwendet, da hiermit ein Zugriff von unterschiedlichen Geräten auf eine Datenbank möglich
wird.
Webservices, vor allem solche, die in öffentlichen Netzen angeboten werden, sind einer Vielzahl von
Angriffen ausgesetzt. Insbesondere Angriffe, die die Verfügbarkeit von Systemen vollständig eliminieren
können, die sogenannten Denial-of-Service (DOS) Attacken, stellen eine große Gefahr dar. [29] Aber auch
durch unbefugte Zugriffe auf Webservices, welche als Schnittstellen zu sensiblen Daten fungieren, können
schwerwiegende Schäden entstehen. Daher müssen Maßnahmen wie Authentifizierung, Validierung und
DOS Abwehrmechanismen eingesetzt werden.
 Authentifizierung
Da .NET Webservices (Web API) im Aufbau sehr viele Gemeinsamkeiten mit .NET Webapplikationen
haben, kann auch der gleiche Authentifizierungsprozess verwendet werden. Daher können die
Informationen unter 3.5 auch für Web APIs angewendet werden.
 Validierung
Damit ein Webservice gegen manipulierte Eingabedaten geschützt ist, um beispielsweise gegen SQL
Injection resistent zu sein, können die gleichen Maßnahmen wie bei den Webapplikationen verwendet
werden: Um sich dagegen zu schützen, müssen sichere Datenbankzugriff verwendet werden (siehe
3.2.2). Das Einschleusen von Script Code kann durch das Attribut [ValidateInput(true)]
verhindert werden (siehe 3.1).
 DOS Protection
Bei einem verteilten DoS Angriff werden die Webserver von einer großen Anzahl von Rechnern mit
vielen Anfragen überflutet, wodurch die Server überlastet werden und dadurch Anfragen nicht oder nur
begrenzt beantworten können. Um dies zu vermeiden, könnte eine Firewall nur autorisierte IP Adressen
durchlassen, um die Anzahl der Anfragen zu minimieren. [29] Das funktioniert aber nicht immer, da
Webservices sehr oft für die Öffentlichkeit bereitgestellt werden. Daher müssen die angebotenen
Dienste so entwickelt werden, dass keine Überlast produziert werden kann.
ASP.NET Web APIs können in Kombination mit Open Data Protocol (OData) als REST-basierte
Datendienste fungieren. Dadurch können Ressourcen, welche über URIs (Uniform Resource Identifiers)
identifiziert werden und in einem Datenmodell definiert sind, mittels HTTP-Nachrichten veröffentlicht und
32
bearbeitet werden. [30] Dadurch ergibt sich der Vorteil, dass nicht für jeden Datenbankzugriff eine eigene
Methode geschrieben werden muss (GetAllProducts(), GetProductsById (…), GetProductsByName (…),
…). Um beispielsweise alle Produkte sortiert abzurufen, würde folgender Aufruf genügen:
http://<domain>/webservice.svc/products?$orderby=name
Im Webservice muss keine eigene Methode implementiert werden, da OData die übergebene Anweisung
in eine Datenbankabfrage konvertiert und das Ergebnis als JSON oder XML zurücksendet. Das Gefährliche
an dieser Art ist, dass Angreifer einen Webserver mit einer Reihe von komplexen Anweisungen schnell zu
einer hohen Auslastung bringen können. Würde es zum Beispiel 1 Million Produkte geben und die vorherige
Anfrage würde alle 500 Millisekunden gesendet werden, so würde der Server schnell an seine Grenzen
stoßen. Um dies zu vermeiden, können folgende Mechanismen implementiert werden: [31]
 Anzahl der Datensätze einschränken
Damit bei großen Datenmengen nicht alle Daten auf einmal an die Client übertragen werden, sollte man
Pagging verwenden, um die Daten stückweise auszuliefern. Mit dem nachfolgenden Attribut würden
maximal 100 Datensätze zurückgeliefert werden.
1
2
[Queryable(PageSize = 100)]
public IQueryable<Product> Get()
Listing 19: OData - Anzahl der Datensätze einschränken
 Nur bestimmte Operationen zulassen
Damit beispielsweise keine OrderBy Anweisungen gesendet werden können, sondern nur
zugelassene Operationen, müssen diese explizit erlaubt werden.
1
2
[Queryable(AllowedQueryOptions = AllowedQueryOptions.Filter |
AllowedQueryOptions.Top)]
public IQueryable<Product> Get()
Listing 20: OData - Operationen einschränken
Es gibt noch eine Menge weitere Einschränkungen wie zum Beispiel das Zulassen von bestimmte
Arithmetische Optionen. Diese können unter http://blogs.msdn.com/b/webdev/archive/2013/02/06/protectyour-queryable-api-with-validation-feature-in-asp-net-web-api-odata.aspx abgerufen werden.
33
4. Windows Communication Foundation (WCF)
Seit 2006 liefert Microsoft mit dem .NET Framework 3.0 die Windows Communication Foundation (WCF)
mit, wodurch es möglich wurde, verteilte Applikationen auf Basis von SOA (Service-oriented Architecture)
zu schreiben. Zuvor gab es dafür zwar auch schon Technologien wie .NET Remoting, Message Queuing
(MSMQ) oder Enterprise Services, jedoch konnten diese immer nur für bestimmte Anforderungen genutzt
werden. Daher vereinigte Microsoft mit WCF alle diese Technologien zu einem Guss, um ein zentrales
Framework für viele Situationen bereitzustellen. [32, pp. 327, 328] In der Tabelle 2 werden alle
zusammengefassten Technologien von WCF gezeigt.
Technologie
ASMX
Anforderung
Interoperable
Web Services
Binary .NET .NET
Communication
Distributed
Transactions,
etc.
.NET
Remoting
Enterprise
Services
WSE
System.
Messaging
System.
NET
X
WCF
X
X
X
X
Support für WS* Specifications
X
X
Queued
Messaging
X
X
RESTful
Communication
X
x
x
Tabelle 2: Technologien von WCF [33, p. 7]
4.1.
Endpoints
Um ein WCF Service zu veröffentlichen, muss ein sogenannter Endpoint eingerichtet werden. Dieser
besteht aus den drei Komponenten Address, Contract und Binding. Auch der Client benötigt diese
Informationen, um mit dem Service kommunizieren zu können. [32, p. 340]
 Address – Wo finde ich den Dienst?
Eine Adresse besteht aus dem Transport Protokoll, dem Maschinennamen, einem Port und einem Pfad.
Die Syntax einer Adresse lautet daher: Protokoll://<Maschinenname>[:port]/>Pfad zum
Service>
34
WCF unterstützt dabei mehrere Protokolle, welche je nach Anforderung eingesetzt werden können: [32,
pp. 340, 341]
 HTTP: das häufigste verwendete Protokoll, um auf ein WCF Service zuzugreifen. Ein Vorteil ist, dass
durch einen Browser auf das Service zugegriffen werden kann.
Adresse: http://<domain>/<Pfad zum Service>
 Named Pipes: Dieses Protokoll wird für Inter-Prozess oder In-Prozess Kommunikationen verwendet.
Adresse: net.pipe://example.com/Products/GetAllProducts
 TCP: ähnlich wie das HTTP Protokoll, kann jedoch nicht über einen Webbrowser aufgerufen werden.
Adresse: net.tcp://example.com/Products/GetAllProducts
 MSMQ: Message Queues haben den Vorteil, dass Daten kurzzeitig zwischengespeichert werden
können. Somit kann ein Server für kurze Zeit offline sein, da er die Daten nachträglich aus der Queue
empfängt. Bei diesem Protokoll gibt es keine Portangabe.
Adresse: net.msmq://example.com/Products/GetAllProducts
 Contract – Was wird zwischen dem Client und dem Service ausgetauscht? [34]
Contracts sind Interfaces und Datenstrukturen, die angeben, welche Operationen und Daten ein Service
anbietet. Es gibt drei Typen von Contracts:
 Service Contract: beschreibt eine Reihe zusammenhängender Operationen in einem gemeinsamen
Interface. Um eine Klasse als Service anzubieten, muss das Attribut [ServiceContract] gesetzt
werden. Zusätzlich muss jede Methode, welche veröffentlich werden soll, mit dem Attribut
[OperationContract] gekennzeichnet werden. (siehe Listing 21)
 Data Contract: Damit komplexe bzw. eigene Datentypen serialisiert werden können, muss bei der
entsprechenden Klasse und den gewünschten Properties das Attribut [DataContract] gesetzt
werden.
 Message Contract: Um mehr Kontrolle über die von WCF generierten SOAP Nachrichten zu
bekommen, können MessageContracts verwendet werden. Dazu muss über die Klasse das Attribut
[MessageContract] gesetzt werden. Die gewünschten Properties könnten dann entweder mit dem
Attribut [MessageBody] oder [MessageHeader] gekennzeichnet werden.
1
2
3
4
5
6
7
8
9
[ServiceContract]
public interface IRandomService
{
[OperationContract]
int GetRandomNumber();
[OperationContract]
int GetRandomNumberInRange(int min, int max);
}
Listing 21: Service Contract
 Binding – Wie kommuniziere ich mit dem Dienst?
35
Mit den Bindings wird festgelegt, wie ein Dienst mit der Außenwelt kommuniziert. Dabei werden Aspekte
wie die verwendete Kommunikationstechnik (HTTP, TCP, …), die Kodierung (Binär, Text, XML, …), die
eingesetzte Verschlüsselungstechnik und vieles mehr beschrieben. Da es sehr viele
Konfigurationsparameter
gibt,
können
vom
Framework
bereitgestellte
Bindings
wie
BasicHttpBinding, NetTcpBinding, usw. verwendet werden. [3, p. 104] Details über alle Bindings
können unter http://msdn.microsoft.com/en-us/library/ms730879(v=vs.110).aspx abgerufen werden.
Die Parameter Adress und Binding können sowohl im Quellcode also auch in einer Konfigurationsdatei
angegeben werden. Beim Verwenden einer Konfigurationsdatei ergibt sich der Vorteil, dass bei
Änderungen nicht neu kompiliert werden muss. [3, p. 104] Um einen Endpoint für das Service und den
Client zu erstellen, ist folgender Konfigurationseintrag notwendig:
Server
1
2
3
4
5
6
7
8
9
10
11
<system.serviceModel>
<services>
<service name="WcfService.RandomService">
<endpoint address="net.tcp://localhost:8732/Random"
binding="netTcpBinding" contract="WcfService.IRandomService"/>
<endpoint address="net.tcp://localhost:8733/mex"
binding="mexTcpBinding" contract="IMetadataExchange"/>
</service>
</services>
</system.serviceModel>
Listing 22: WCF Endpoint (Service)
In Listing 22 wird folgende Konfiguration festgelegt:
 Zeile 3: Die Klasse RandomService wird als Service veröffentlich. In dieser Klasse wurden die
Methoden des Service Contracts aus Listing 21 implementiert.
Zeile 4 – 5: Mit dem Endpoint wird festgelegt, dass die Kommunikation über TCP läuft. Die Konsumenten
könnten dabei alle Operationen nutzen, welche im Contract WcfService.IRandomService definiert
wurden. Zusätzlich wird noch die Adresse für den Dienst angegeben.
 Zeile 7 – 8: Dieser Endpoint ist für den Austausch von Metadaten notwendig. Der Endpoint ist nicht
zwingend für die Funktionalität notwendig, erleichtert aber die Entwicklung von WCF Diensten in Visual
Studio enorm.
Client
1
2
3
4
5
6
<client>
<endpoint address="net.tcp://localhost:8732/Random"
binding="netTcpBinding" contract="RandomService.IRandomService"/>
</client>
Listing 23: WCF Endpoint (Client)
36
In Listing 23 wird folgende Konfiguration festgelegt:
 Zeile 3 – 4: Um eine Verbindung mit dem WCF Service aus Listing 22 aufbauen zu können, muss am
Client der gleiche Endpoint angegeben werden.
Der große Vorteil von WCF ist nun, dass man zum Beispiel in nur einem Schritt die Übertragungstechnik
ändern kann, ohne den Code anpassen zu müssen. Soll die Kommunikation auf HTTP umgestellt werden,
so muss der Parameter netTcpBinding auf basicHttpBinding sowie das Protokoll in der Adresse
auf http:// geändert werden.
4.2.
Sicherheitsmechanismen
Einer der wichtigsten Punkte bei verteilten Anwendungen ist die Sicherstellung einer sicheren
Kommunikation. Gerade bei der Übertragung von sensiblen Daten über öffentliche Netze müssen Aspekte
wie Vertraulichkeit, Integrität und Authentizität gewährleistet werden. Bei WCF unterscheidet man dabei
zwischen der Transportsicherheit und der Nachrichtensicherheit.
Bei der Transportsicherheit wird der Übertragungskanal entweder mit SSL (Secure Socket Layer) oder
SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism) verschlüsselt. Da SSL durch den
Einsatz im World Wide Web sowie SPNEGO für Integrated Windows Authentication schon lange im Einsatz
sind, haben sich diese Technologien bereits bewährt. Bei der Nachrichtensicherheit wird die Nachricht
selbst verschlüsselt und signiert. [3, pp. 105, 106] Dazu bietet WCF die verschiedenen WS-* Klassen wie
WS-Security, WS-Trust und WS-SecureConversation an. [33, p. 10]
Es kann auch ein Mix von Transportsicherheit und Nachrichtensicherheit durchgeführt werden. So wird
zum Beispiel die Nachricht verschlüsselt, signiert und anschließend über einen SSL Port übertragen, ohne
nochmals verschlüsselt zu werden. Die Verschlüsselung mittels Transportsicherheit wird im Gegensatz zur
Nachrichtensicherheit Stream-basiert durchgeführt. Daher sollte aus Performance Gründen die Chiffrierung
mittels Transportsicherheit realisiert werden. [3, p. 106]
Da die vom WCF bereitgestellten Bindings zum Teil standardmäßig keine Sicherheitsparameter setzen,
muss dies durch weitere Konfigurationsschritte manuell durchgeführt werden. Beim Verwenden von
basicHttpBinding ohne weitere Einstellungen werden keine Sicherheitsmechanismen verwendet. In
der Abbildung 13 wurde die Kommunikation mit einem Sniffer abgehört, um die ausgetauschten Daten
auszulesen. Werden nun beispielsweise Kreditkarteninformationen ausgetauscht, so wäre das eine fatale
Sicherheitslücke. Um dies zu beheben, kann die Flexibilität von WCF genutzt werden: Es muss lediglich
die Konfiguration der Bindings erweitert werden und diese im Endpoint mit dem Parameter
bindingConfiguration verknüpft werden. (siehe Listing 24)
37
Abbildung 13: WCF Kommunikation im Klartext
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<services>
<service name="WcfService.RandomService">
<endpoint address="https://10.0.0.29:8735/Math"
bindingConfiguration="customBinding" binding="basicHttpBinding"
contract="WcfService.IRandomService" />
</service>
</services>
<bindings>
<basicHttpBinding>
<binding name="customBinding">
<security mode="Transport" />
</binding>
</basicHttpBinding>
</bindings>
Listing 24: WCF mit Transportsicherheit
Wie in den Zeile 9 – 15 von Listing 24 zu sehen ist, wurde eine benutzerdefinierte Binding erstellt. In dieser
wurden die Parameter für eine Transportsicherheit gesetzt. Dieses Binding ET1(ur)-14(de)4( )25(e)-9s TJE6ETBdadefit
38
4.3.
WCF vs. ASP.NET Web API
WCF Dienste können als Webservice, Stand-Alone Applikation oder Windows Service betrieben werden.
Nun bietet das .NET Framework allerdings auch die ASP.NET Web API (siehe 3.6) zum Entwickeln von
Webservices an. Welche Technologie sollte nun zum Entwickeln eines Webservices verwendet werden?
WCF gilt als sehr mächtiges Framework, da durch die zahlreichen Konfigurationsmöglichkeiten sehr viele
Anforderungen abgedeckt werden können. Dadurch ist es aber auch komplexer als ein einfaches ASP.NET
Webservice. Und genau hier liegt auch der größte Unterschied: ASP.NET Webservices sind im Gegensatz
zu WCF klein, leichtgewichtig und einfach in Betrieb zu nehmen. [37] Um besser entscheiden zu können,
welche Technologie am besten eingesetzt werden soll, werden in der Tabelle 3 die Features
gegenübergestellt:
WCF
Mehrere Übertragungsprotokolle (HTTP, TCP,
UDP)
Mehrere Kodierungsmöglichkeiten (Text, MTOM
und Binär)
Unterstützt WS-* Standards wie Reliable
Messaging, Transactions oder Message Security
Unterstützt Request-Reply, One Way und Duplex
message exchange
Mit .NET Framework mitgeliefert
ASP.NET Web API
Nur HTTP als Übertragungsprotokoll
Daten werden üblicherweise mittels XML oder
JSON serialisiert
Es werden Basis Protokolle und Formate wie
HTTP, SSL, JSON und XML verwendet. Es gibt
keine Unterstützung für höhere Protokolle wie
Reliable Messaging oder Transactions
HTTP basiert auf Request/Response
Ebenfalls im .NET Framework enthalten, ist
jedoch Open Source
Tabelle 3: WCF Webservice vs. ASP.NET Web API [37]
ASP.NET Web API wird sehr stark weiterentwickelt, da leichtgewichtige Dienste durch die starke
Verbreitung von mobilen Geräten immer mehr an Bedeutung gewinnen. Daher sollte man bei neuen
Projekten die ASP.NET Web API bevorzugen, wenn diese alle Anforderungen erfüllen kann.
39
5. Kryptographie
In diesem Kapitel geht es um kryptografische Konzepte in .NET. Kryptographie ist die Lehre von der Verund Entschlüsselung. Dadurch können vertrauliche Daten über unsichere Netze wie beispielsweise das
Internet übertragen werden, ohne dass diese von unberechtigten Personen gelesen werden können. Um
dies zu erreichen, werden Verschlüsselungsalgorithmen oder Chiffriercodes auf die Daten angewendet,
welche aus mathematischen Funktionen zur Ver- und Entschlüsselung bestehen. Die Sicherheit der
verschlüsselten Daten ist dabei von der Stärke des Verschlüsselungsalgorithmus und der Geheimhaltung
sowie der Länge des Schlüssels abhängig. [38, p. 3]
In der modernen Kryptographie werden folgende Ziele verfolgt, um Informationen zu schützen: [39, pp. 14]
 Vertraulichkeit: Nur berechtigte Personen dürfen Zugriff auf den Inhalt von Nachrichten bekommen.
 Integrität: Es muss für den Empfänger nachprüfbar sein, dass er die Nachricht unversehrt erhalten hat.
 Authentizität: Die Identität des Absenders einer Nachricht soll für den Empfänger nachprüfbar sein.
 Verbindlichkeit: Ein Absender einer Nachricht soll seine Urheberschaft später nicht verleugnen können.
5.1.
Symmetrische Verfahren
Bei symmetrischen Verschlüsselungen wird für die Ver- und Entschlüsselung ein einziger Schlüssel
benötigt, d.h. sowohl der Absender als auch der Empfänger müssen denselben Schlüssel besitzen. Dieses
Verschlüsselungssystem ist sehr schnell. Der Nachteil ist jedoch der Schlüsselaustausch: Bekommt ein
Angreifer bei der Schlüsselverteilung Zugriff auf den Schlüssel, so kann er alle Daten entschlüsseln. Daher
sollte die symmetrische Verschlüsselung nur eingesetzt werden, wenn eine der folgenden Gegebenheiten
zutrifft: [38, p. 3]
 Es werden nur lokale Daten verschlüsselt, welche nicht übertragen werden.
 Es wird ein sicheres Protokoll für den Schlüsselaustausch verwendet, wie z.B. Diffie-Hellman.
 Die symmetrische Verschlüsselung wird in Kombination mit einer asymmetrischen Verschlüsselung
durchgeführt.
Für symmetrische Verschlüsselungen stehen bekannte Algorithmen wie
 Advanced Encryption Standard (AES) oder auch Rijndael-Algorithmus: Schlüssellänge 128, 192 oder
256 Bit
 Data Encryption Standard (DES): Schlüssellänge 56 Bit
 Tripple-DES: Schlüssellänge 112 Bit
zur Verfügung.
In dem nachfolgenden Beispiel wird der AES als Verschlüsselungsalgorithmus verwendet. Es wird eine
Client-Server Anwendung erstellt, wo Nachrichten vom Client verschlüsselt an den Server gesendet
werden. Bei Bedarf können auch andere Algorithmen eingesetzt werden. Beachten Sie jedoch, dass
Schlüssel mit weniger als 100 Bit bei symmetrischen Verfahren als nicht sicher eingestuft werden.
40
Server
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
static void Main(string[] args)
{
try
{
TcpListener tcpListener = new TcpListener (IPAddress.Parse
("127.0.0.1"), 8001);
tcpListener.Start();
Socket socket = tcpListener.AcceptSocket();
NetworkStream nStream = new NetworkStream(socket);
StreamReader reader = new StreamReader(nStream);
byte[] iv = Convert.FromBase64String(reader.ReadLine());
byte[] key = Convert.FromBase64String(reader.ReadLine());
while (true)
{
string msg = streamreader.ReadLine();
Console.WriteLine("Received: " + DecryptData(msg, iv, key));
}
reader.Close();
nStream.Close();
socket.Close();
tcpListener.Stop();
}
catch (Exception e)
{
Console.WriteLine("Error..... " + e.StackTrace);
}
}
public static string DecryptData(string input, byte[] iv, byte[] key)
{
MemoryStream tmpStream = new MemoryStream();
RijndaelManaged aes = new RijndaelManaged();
CryptoStream cs = new CryptoStream(tmpStream,
aes.CreateDecryptor(key, iv), CryptoStreamMode.Write);
byte[] data = Convert.FromBase64String(input);
cs.Write(data, 0, data.Length);
cs.FlushFinalBlock();
return Convert.ToBase64String(tmpStream.ToArray());
}
Listing 25: TCP Server für AES Kommunikation
Im Listing 25 werden folgende Aktionen durchgeführt:
41
 Zeile 5 - 7: Der TCP Port 8001 wird geöffnet.
 Zeile 9: Es wird auf einen Verbindungsaufbau eines Clients gewartet. Sobald eine Verbindung aufgebaut
wird, wird ein Socket erzeugt.
 Zeile 11 – 12: Es wird ein Übertragungskanal erstellt, über welchen die gesendet Daten vom Client
gelesen werden.
 Zeile 14 – 15: Der Server erwartet in den ersten beiden Nachrichten den Initialisierungsvektor (IV) und
den Schlüssel, die für die nachfolgende Entschlüsselung verwendet werden sollen.
 Zeile 17 – 21: Die gesendeten Daten werden eingelesen und mit dem zuvor erhaltenen IV und Schlüssel
entschlüsselt und ausgegeben.
 Zeile 23 – 26: Der Übertragungskanal und die Verbindung werden geschlossen.
 Zeile 36: Es wird eine Instanz vom Objekt MemoryStream erstellt, welche zum Zwischenspeichern der
entschlüsselten Daten benötigt wird.
 Zeile 37: Es wird eine Instanz vom Objekt RijndaelManaged erstellt, welche zum Entschlüsseln der
Daten benötigt wird.
 Zeile 39 – 40: Es wird eine Instanz vom Objekt CryptoStream erstellt, durch welche die Daten
entschlüsselt werden. Als Parameter müssen der Zielort und der Entschlüsselungsalgorithmus
angegeben werden.
 Zeile 42 – 44: Die Daten werden in ein Byte Array umgewandelt und durch den erstellten
CryptoStream geschickt. Erst durch die Methode Flush() werden die Daten dann entschlüsselt in
den MemoryStream geschrieben.
 Zeile 46: Nun können die entschlüsselten Daten aus dem MemoryStream ausgelesen und
zurückgeliefert werden. Da die Daten als Byte Array abgespeichert wurden, müssen diese zuvor noch
in ein String Element konvertiert werden.
Client
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
static void Main(string[] args)
{
try
{
TcpClient tcpclnt = new TcpClient();
tcpclnt.Connect("127.0.0.1", 8001);
NetworkStream nStream = tcpclnt.GetStream();
StreamWriter writer = new StreamWriter(nStream);
byte[] iv = aes.IV;
byte[] key = aes.Key;
writer.WriteLine(Convert.ToBase64String(iv));
writer.WriteLine(Convert.ToBase64String(key));
writer.Flush();
while (true)
{
Console.Write("Enter the string to be transmitted : ");
writer.WriteLine(EncryptData(Console.ReadLine(), iv, key));
writer.Flush();
}
42
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
reader.Close();
nStream.Close();
socket.Close();
tcpclnt.Close();
}
catch (Exception e)
{
Console.WriteLine("Error..... " + e.StackTrace);
}
}
public static string EncryptData(string input, byte[] iv, byte[] key)
{
MemoryStream tmpStream = new MemoryStream();
CryptoStream cs = new CryptoStream(tmpStream,
aes.CreateEncryptor(key, iv), CryptoStreamMode.Write);
byte [] data = Convert.FromBase64String(input);
cs.Write(data, 0, data.Length);
cs.FlushFinalBlock();
return Convert.ToBase64String(tmpStream.ToArray());
}
Listing 26: TCP Client für AES Kommunikation
Im Listing 26 werden folgende Aktionen durchgeführt:
 Zeile 5 - 3: Es wird eine Verbindung zum Server aufgebaut.
 Zeile 8 – 9: Es wird ein Übertragungskanal erzeugt, über welchen die Daten zum Server gesendet
werden.
 Zeile 11 – 13: Der Initialisierungsvektor (IV) und der Schlüssel werden erstellt. Diese werden für die
nachfolgende Verschlüsselung verwendet. Um zufällige Werte zu erhalten, werden diese mit dem
RijndaelManaged Objekt erstellt.
 Zeile 15 – 17: Die generierten Werte werden an den Server gesendet. Erst durch die Methode Flush()
werden die Daten tatsächlich übertragen.
 Zeile 19 – 24: Die eingegebenen Daten werden verschlüsselt und an den Server gesendet.
 Zeile 26 – 29: Der Übertragungskanal und die Verbindung werden geschlossen.
 Zeile 39: Es wird eine Instanz vom Objekt MemoryStream erstellt, welche zum Zwischenspeichern der
verschlüsselten Daten benötigt wird.
 Zeile 40: Es wird eine Instanz vom Objekt RijndaelManaged erstellt, welche zum Verschlüsseln der
Daten benötigt wird.
 Zeile 42 – 43: Es wird eine Instanz vom Objekt CryptoStream erstellt, durch welche die Daten
verschlüsselt werden. Als Parameter müssen der Zielort und der Entschlüsselungsalgorithmus
angegeben werden.
 Zeile 45 – 47: Die Daten werden in ein Byte Array umgewandelt und durch den erstellten
CryptoStream geschickt.
43
 Zeile 49: Nun können die verschlüsselten Daten aus dem MemoryStream ausgelesen und
zurückgeliefert werden. Da die Daten als Byte Array abgespeichert wurden, müssen diese zuvor noch
in ein String Element konvertiert werden.
Die Nachrichten werden zwar verschlüsselt vom Client zum Server gesendet, jedoch wurde zuvor der
Schlüssel in Klartext ausgetauscht. Konnte ein Angreifer beispielsweise durch Sniffen den Schlüssel und
den Initialisierungsvektor abgreifen (siehe Abbildung 14), so könnte er alle übertragenen Daten
entschlüsseln.
Abbildung 14: Schlüsselaustausch abhören
In der Abbildung 14 wird in der Client Applikation der generierte Schlüsselt ausgelesen. Zeitgleich wurde
das Sniffing Programm Wireshark gestartet, um alle Netzwerkaktivitäten abzuhören. Wie man erkennen
kann, konnte der generierte Schlüssel unverfälscht ermittelt werden. Um dies zu vermeiden, kann
beispielsweise das Diffie-Hellman Protokoll eingesetzt werden.
5.1.1. Diffie-Helman Protokoll
Beim Diffie-Helman Protokoll handelt es sich um den ersten Verschlüsselungsalgorithmus, in dem diskrete
Logarithmen in einem endlichen Feld verwendet werden. Es wurde 1976 von Martin Hellman und Whitfield
Diffie erfunden. [38, p. 70] Das Ziel dieses Algorithmus ist ein sicherer Schlüsselaustausch über ein
unsicheres Kommunikationsmedium. Um dies zu erreichen, müssen folgende Schritte durchgeführt
werden. [39, p. 29]
 Beide Teilnehmer generieren eine Primzahl p und eine natürliche Zahl g. Da diese Zahlen nicht geheim
bleiben müssen, können sie über einen unsicheren Kanal ausgetauscht werden.
44
 Beide Teilnehmer erzeugen jeweils geheim zu haltende Zufallszahlen a bzw. b, welche nicht übertragen
werden.
 Nachdem p und g ausgetauscht wurden, berechnen die Teilnehmer A = ga mod p bzw. B = gb mod p.
Danach wird A und B ausgetauscht.
 Nun können beide Teilnehmer den gemeinsamen Schlüssel berechnen: K = Ba mod p bzw. K = Ab mod
p
Um dieses Verfahren in einer .NET Anwendung zu implementieren, können mitgelieferte Bibliotheken
verwendet werden. Dazu wird das Beispiel aus Listing 25 und Listing 26 folgendermaßen erweitert:
Client
1
2
3
4
5
6
7
8
9
10
11
ECDiffieHellmanCng dh = new ECDiffieHellmanCng();
dh.HashAlgorithm = CngAlgorithm.Sha256;
byte[] publicKey = dh.PublicKey.ToByteArray();
writer.WriteLine(Convert.ToBase64String(publicKey));
writer.Flush();
byte[] srvPublicKey = Convert.FromBase64String (reader.ReadLine());
byte[] key = dh.DeriveKeyMaterial(CngKey.Import(srvPublicKey,
CngKeyBlobFormat.EccPublicBlob));
Listing 27: Diffie-Hellman Implementierung (Client)
Server
1
2
3
4
5
6
7
8
9
10
11
byte[] clientPublicKey = Convert.FromBase64String(reader.ReadLine());
ECDiffieHellmanCng dh = new ECDiffieHellmanCng();
dh.HashAlgorithm = CngAlgorithm.Sha256;
byte[] publicKey = dh.PublicKey.ToByteArray();
writer.WriteLine(Convert.ToBase64String(publicKey));
writer.Flush();
byte[] key = dh.DeriveKeyMaterial(CngKey.Import(clientPublicKey,
CngKeyBlobFormat.EccPublicBlob));
Listing 28: Diffie-Hellman Implementierung (Server)
Im Beispiel von Listing 27 und Listing 28 wird ein Diffie-Hellman Schlüsselaustausch auf Basis von
elliptischen Kurven durchgeführt. Dabei werden folgende Schritte abgearbeitet: [40]
 Client und Server generieren jeweils ein Schlüsselpaar für den Diffie-Hellman Schlüsselaustausch.
 Client und Server konfigurieren jeweils dieselben Parameter der Key Derivation Function (KDF). Eine
KDF ist ein deterministischer Algorithmus, um einen Schlüssel aus einem geheimen Wert abzuleiten.
 Client und Server tauschen den öffentlichen Schlüssel aus.
45
 Client und Server nutzen den öffentlichen Schlüssel des jeweils anderen für die Generierung des
gemeinsamen Schlüssels.
5.2.
Asymmetrische Verfahren
Bei asymmetrischen Systemen werden zur Ver- und Entschlüsselung unterschiedliche Schlüssel
verwendet, die mathematisch miteinander verbunden sind. Dadurch vereinfacht sich das Problem des
Schlüsselaustauschs. Nur der Dechiffrierschlüssel muss geheim gehalten werden, der Chiffrierschlüssel
kann dagegen öffentlich bekannt sein. Diese Verschlüsselungsart wird auch als Public-Key Verfahren
bezeichnet. [3, p. 58]
Die Verschlüsselung ist jedoch aufwendiger und daher langsamer, da bei asymmetrischen Verfahren
längere Schlüssel (mindestens 2048 Bits) als bei symmetrischen Verfahren (mindestens 128 Bits)
verwendet werden und die mathematische Generierung eines Schlüsselpärchens zusätzliche
Rechenleistung in Anspruch nimmt. Aus diesem Grund werden häufig hybride Systeme eingesetzt: [41]
Die Verschlüsselung der eigentlichen Daten erfolgt symmetrisch mithilfe eines Session Schlüssels. Dieser
Schlüssel wird für jede Übertragung generiert, asymmetrisch verschlüsselt und an die eigentliche Nachricht
angehängt. So erhält man die Vorteile beider Systeme: Geschwindigkeit und Sicherheit.
Das erste praktisch eingesetzte asymmetrische kryptographische Verfahren war der 1977 entwickelte RSA.
Der Name ist eine Ableitung von den Erfindern: Ronald Rivest, Adi Shamir und Leonard Adleman. Der
RSA ist inzwischen zum de-facto-Standard für die Public-Key Verschlüsselung geworden und ist somit das
bekannteste und verbreitetste asymmetrische Verfahren. Die Sicherheit des RSA Algorithmus basiert auf
der Faktorisierungsannahme: Die Zerlegung einer großen Zahl in ihre Primfaktoren ist sehr aufwändig,
während das Erzeugen einer Zahl durch Multiplikation von Primzahlen recht einfach ist. [42, pp. 84, 85] Der
RSA kann zusätzlich zur Verschlüsselung auch für Digitale Signaturen verwendet werden. Dadurch können
die Integrität, Authentizität und Verbindlichkeit gewährleistet werden.
5.2.1. Verschlüsselung
Um asymmetrische Verschlüsselungen in .NET Anwendungen zu implementieren, kann die Klasse
RSACryptoServiceProivder vom Namespace System.Security.Cryptography verwendet
werden. Im nachfolgenden Beispiel wird vom Server ein öffentlicher Schlüssel an den Client übertragen.
Alle darauffolgenden Daten werden vom Client mit dem öffentlichen Schlüssel verschlüsselt und mit dem
privaten Schlüssel entschlüsselt. Die Vorgänge für die TCP Verbindung können aus dem Beispiel von
Listing 25 und Listing 26 entnommen werden.
Server
1
2
3
4
5
RSACryptoServiceProvider rsa = new RSACryptoServiceProvider(1024);
writer.WriteLine(Convert.ToBase64String(rsa.ExportCspBlob(false)));
writer.Flush();
46
6
7
8
9
10
11
12
13
14
while (true)
{
string secureContent = streamreader.ReadLine();
byte[] decryptBytes = rsa.Decrypt (Convert.FromBase64String(
secureContent), false);
Console.WriteLine("Received: " + Encoding.UTF8.GetString (
decryptBytes));
}
Listing 29: RSA Verschlüsselung (Server)
 Zeile 1: Es wird eine Instanz der Klasse
gewünschten Schlüssellänge initialisiert.
RSACryptoServiceProvider erstellt und mit der
 Zeile 3 – 4: Die RSA Parameter inklusive des öffentlichen Schlüssels werden mit der Methode
ExportCspBlob ausgelesen und an den Client gesendet.
 Zeile 6 – 14: Nachrichten vom Client werden empfangen, entschlüsselt und ausgegeben. Da die Instanz
von RSACryptoServiceProvider den privaten Schlüssel hält, kann einfach die Methode Decrypt
aufgerufen werden.
Client
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
byte[] publicKey = Convert.FromBase64String(reader.ReadLine());
RSACryptoServiceProvider rsa = new RSACryptoServiceProvider();
rsa.ImportCspBlob(publicKey);
while (true)
{
byte[] message = rsa.Encrypt(Encoding.UTF8.GetBytes(
Console.ReadLine()), false);
streamwriter.WriteLine(Convert.ToBase64String (message));
streamwriter.Flush();
}
Listing 30: RSA Verschlüsselung (Client)
 Zeile 1: Die RSA Parameter inklusive des öffentlichen Schlüssels werden vom Server empfangen.
 Zeile 3 – 4: Es wird eine Instanz der Klasse RSACryptoServiceProvider erstellt und die
empfangenen Parameter werden importiert. Dadurch ist der öffentliche Schlüssel für die spätere
Entschlüsselung bekannt.
 Zeile 6 – 15: Die Daten werden von der Konsole eingelesen, verschlüsselt und an den Server gesendet.
47
5.2.2. Digital Signieren
Wie bereits erwähnt, können Daten mithilfe von asymmetrischen Verfahren signiert werden, um die
Datenintegrität und die Identität des Absenders überprüfen zu können. Eine digitale Unterschrift hat
dieselbe Aufgabe wie eine Unterschrift von Hand, hat jedoch den Vorteil, dass sie nahezu fälschungssicher
ist und außerdem den Inhalt der Informationen und die Identität des Unterschreibenden bescheinigt [38, p.
11]
Auch beim digitalen Signieren wird ein Schlüsselpaar, also ein öffentlicher und ein privater Schlüssel
erzeugt. Um eine Nachricht zu signieren, muss der Sender zuerst einen Hashwert der zu sendenden
Information generieren. Eine Hashfunktionen generiert aus einer beliebig großen Eingabe eine
Zeichenfolge fixer Länge. Der Hashwert wird danach mit dem privaten Schlüssel verschlüsselt und an die
Nachricht angehängt. Der Empfänger erstellt ebenfalls einen Hashwert über die erhaltene Nachricht ohne
die Signatur. Zusätzlich entschlüsselt er die Signatur und vergleicht die beiden Werte. Bei einer
Übereinstimmung weiß man, dass die Nachricht nicht verändert wurde. [39, pp. 11-12] Um die Identität
feststellen zu können, muss das Schlüsselpaar einer Person zugeordnet werden. Dazu werden
üblicherweise Zertifikate verwendet, mit denen vertrauenswürdige Stellen diese Zuordnung bestätigen
(siehe 5.3).
In .NET Applikationen kann zum Signieren wieder die Klasse RSACryptoServiceProvider benutzt
werden, welche folgende Methoden bereitstellt: [3, p. 93]
 SignData: Diese Methode generiert einen Hashwert von den übergebenen Daten und signiert diesen.
Als Parameter muss dazu der gewünschte Hash-Algorithmus übergeben werden.
 SignHash: Diese Methode signiert einen übergebenen Hashwert. Die Methode kommt zum Einsatz,
wenn der Hashwert separat berechnet werden soll.
 VerifyData: Diese Methode überprüft eine mit SignData erstellte Signatur.
 VerifyHash: Diese Methode überprüft eine mit SignHash erstellte Signatur.
Client:
1
2
3
4
5
6
7
8
9
10
11
12
byte[] message = Encoding.UTF8.GetBytes („Inhalt eines Dokuments“);
byte[] signature = rsa.SignData(message, new
SHA1CryptoServiceProvider());
rsa.Clear();
byte[] publicKey = rsa.ExportParameter (false);
// Send public key + message + signature to the server
Listing 31: RSA Signatur erstellen
In Listing 31 werden folgende Schritte durchgeführt:
48
 Zeile 1: Die zu signierende Nachricht wird in ein Byte Array umgewandelt
 Zeile 3: Erzeugen einer RSACryptoServiceProvider Instanz samt Schlüsselpaar
 Zeile 5 – 6: Erzeugen der Signatur: Es wird zuerst ein Hash mithilfe des SHA1 Algorithmus der Nachricht
generiert, welcher dann mit dem privaten Schlüssel signiert wird.
 Zeile 8: Vertrauliche Daten werden gelöscht.
 Zeile 10: Der öffentliche Schlüssel wird exportiert, da dieser dem Empfänger zur Verfügung gestellt
werden muss.
 Zeile 12: Die Daten (öffentlicher Schlüssel, Signatur und die Nachricht) werden an den Empfänger
übermittelt. Um Daten beispielsweise via TCP Verbindung zu versenden, könnten die Schritte den
Beispielen in Listing 25 und Listing 26 entnommen werden.
Server:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
byte[] publicKey = // Receive public key from client
byte[] message = // Receive message from the client
byte[] signature = // Receive signature from client
rsa.importParameters(publicKey);
boolean isSignatureCorrect = rsa.VerifyData(message, new
SHA1CryptoServiceProvider(),signature);
rsa.Clear();
if (isSignatureCorrect)
{
...
}
else
{
...
}
Listing 32: RSA Signatur überprüfen
 Zeile 1: Die Daten (öffentlicher Schlüssel, Signatur und die Nachricht) werden empfangen und
abgespeichert.
 Zeile 5 - 6: Es wird eine Instanz der Klasse RSACryptoServiceProvider erstellt und der
empfangenen Schlüssel importiert. Dadurch ist der der öffentliche Schlüssel für die Verifizierung der
Signatur bekannt.
 Zeile 8 – 6: Die Signatur und die erhaltene Nachricht werden verglichen. Dadurch kann festgestellt
werden, ob der Inhalt verändert wurde.
 Zeile 11: Vertrauliche Daten werden gelöscht.
 Zeile 13 – 20: Je nachdem, ob die Signatur korrekt war, können die gewünschten Aktionen durchgeführt
werden.
49
5.3.
Digitale Zertifikate
Ein digitales Zertifikat kann mit einem Personalausweis in elektronischer Form verglichen werden: Bei
einem Personalausweis bestätigt eine vertrauenswürdige Stelle wie zum Beispiel das Meldeamt, dass die
Unterschrift auf dem Ausweis auch tatsächlich zu der Person gehört, deren Daten und Bild sich auf dem
Ausweis befinden. Bei einem Zertifikat bestätigen vertrauenswürdige Stellen wie beispielsweise GlobalSign
die Echtheit von Angaben. [43]
Digitale Zertifikate enthalten Informationen wie den Namen des Inhabers, dessen öffentlichen Schlüssel,
eine Gültigkeitsdauer und den Namen der Zertifizierungsstelle. Diese Informationen werden in einer ASN.1
(Abstract Syntax Notation One) codierten binären Datei abgespeichert. Um Zertifikate zwischen
unterschiedlichen Systemen auszutauschen, muss anstelle der binären Datei ein standardisiertes Format
verwendet werden. Hierzu hat sich das Form X.509 durchgesetzt, welches in RFC 3280 beschrieben ist.
[39, p. 18]
Beim Austausch von Zertifikaten wird gewöhnlich zwischen zwei Formaten unterschieden:
 .cer
Hier handelt es sich um ein signiertes X.509 Zertifikat, welches den öffentlichen Schlüssel und
zusätzliche Daten wie beispielsweise die Zertifizierungsstelle enthält. Dieses wird gewöhnlich an den
Kommunikationspartner gesendet, damit dieser die Daten mit dem öffentlichen Schlüssel verschlüsseln
kann.
 .pfx (Personal Information Exchange)
Hier handelt es sich um ein Zertifikat und den dazugehörigen privaten Schlüssel. Solche Dateien sind
sehr vertraulich und werden normalerweise zum Importieren von Schlüsselpaaren auf einem Server
verwendet.
Um ein Zertifikat zu erhalten, gibt es zwei Möglichkeiten: [44]
 Wenn das Zertifikat für Internet Szenarien verwendet wird, wird es in den meisten Fällen von einer
vertrauenswürdigen Zertifizierungsstelle (CA) angefordert. Solche Zertifikate sind zwar mit Kosten
verbunden, haben aber den Vorteil, dass bekannte Browser und Betriebssysteme diese Zertifikate als
vertrauenswürdig einstufen.
 Wenn das Zertifikat nur für Intranet Szenarien verwendet wird, kann eine eigene Zertifizierungsstelle
eingerichtet werden, welche auf dem Client als vertrauenswürdig eingestuft wird. Dadurch können
Zertifikate selbst erstellt werden. Solche Zertifikate werden auch für B2B Anforderungen eingesetzt.
In
.NET
wird
das
Zertifikat
durch
die
Klasse
X509Certificate2
im
System.Security.Crytography.X509Certificates Namensraum repräsentiert. Auf Zertifikate
kann entweder über den Windows-Zertifikatsspeicher oder über eine Datei (.cer, .pfx) zugegriffen werden.
Mithilfe des Zertifikatsspeichers könnten Zertifikate und ihre dazugehörigen privaten Schlüssel auf
verschiedenen Geräten wie z. B. Festplatten, USB-Tokens oder Smartcards gespeichert werden. Der
Speicher abstrahiert dabei den physikalischen Speicherort, wodurch immer auf die gleiche Weise
zugegriffen werden kann, egal wo das Zertifikat schlussendlich gespeichert ist. Dabei gibt es auf einem
Windows System immer zwei Speichertypen: [3, pp. 205, 206]
50
 Benutzerzertifikatsspeicher: Dieser wird nur für den jeweils angemeldeten Benutzer verwendet und
kann mit dem Befehl certmgr.msc aufgerufen werden.
 Computerzertifikatsspeicher: Dieser Speicher wird von Windows Computerkonten wie NETZWERK,
LOKALER DIENST und LOKALES SYSTEM verwendet. Zusätzlich können damit Zertifikate oder
Schlüssel für mehrere Konten gemeinsam bereitgestellt werden.
Wie in Abbildung 15 veranschaulicht, ist der Speicher in verschiedene Unterelemente unterteilt: Es gibt
beispielsweise einen Container mit dem Namen „Eigene Zertifikate“, in dem eigenen Zertifikate, welche
einen zugeordneten privaten Schlüssel haben verwaltet werden. Ein anderer Container mit den Namen
„Vertrauenswürdige Stammzertifizierungsstellen“ enthält die Zertifikate aller Zertifizierungsstellen, denen
vertraut wird. [3, pp. 205, 206]
Abbildung 15: Benutzerzertifikatsspeicher
5.3.1. Verschlüsseln
Da nun alle theoretischen Fakten erklärt wurden, wird im nachfolgenden Beispiel mittels einer Client-Server
Applikation das Ver- und Entschlüsseln mit Zertifikaten gezeigt. Die Client Applikation verschlüsselt die
Daten, wodurch auf diesem System das Zertifikat mit dem öffentlichen Schlüssel (.cer) installiert sein muss.
Der Server muss zum Entschlüsseln der Daten einen Zugriff auf den privaten Schlüssel (.pfx) haben. In
diesem Beispiel wurde das Zertifikat sowohl am Client als auch am Server im Benutzerzertifikatsspeicher
unter „Eigene Zertifikate“ gespeichert. Die Schritte zum Senden und Empfangen über einen TCP Port
können dem Beispiel aus Listing 25 und Listing 26 übernommen werden.
Client:
51
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
X509Store store = new X509Store(StoreName.My, StoreLocation.CurrentUser);
store.Open(OpenFlags.ReadOnly);
X509Certificate2Collection certs = Store.Certificates.Find(
X509FindType.FindByIssuerDistinguishedName, "CN=testing.com", true);
X509Certificate2 cert = null;
if (col.Count > 0)
cert = col[0];
else
return;
while (true)
{
byte[] input = Encoding.UTF8.GetBytes(Console.ReadLine());
ContentInfo plainMessage = new ContentInfo(input);
EnvelopedCms encryptMessage = new EnvelopedCms(plainMessage);
encryptMessage.Encrypt(new CmsRecipient(cert));
writer.WriteLine(Convert.ToBase64String(encryptMessage.Encode()));
writer.Flush();
}
Listing 33: Verschlüsseln mit Zertifikaten
 Zeile 1 – 2: Der Container “Eigene Zertifikate” im Benutzerzertifikatsspeicher wird geöffnet.
 Zeile 4 – 5: In dem geöffneten Container wird nach allen gültigen Zertifikaten gesucht, welche von
“testing.com” herausgegeben wurden. Im ersten Parameter kann eine Reihe von Suchtypen wie Serial
Nummer, öffentlicher Schlüssel, usw. angegeben werden. Der zweite Parameter gibt den
dazugehörigen Suchwert an. Im letzten Parameter wird spezifiziert, dass nur gültige Zertifikate gesucht
werden sollen.
 Zeile 7 – 11: Es wird überprüft, ob ein Zertifikat gefunden wurde. Wenn nicht, so wird das Programm
beendet.
 Zeile 15 – 16: Die Daten werden von der Konsole eingelesen und in ein Byte Array konvertiert.
 Zeile 18: Es wird eine ContentInfo Instanz erzeugt und mit dem Klartext initialisiert. Dies ist
notwendig, da dieses Objekt eine Datenstruktur für Cryptographic Message Syntax (CMS) darstellt.
CMS ist ein weit verbreitetes Format für kryptographische Nachrichten. [45]
 Zeile 19 - 20: Es wird eine EnvelopedCms Instanz erzeugt, welches die verschlüsselten Daten
repräsentiert. Zum Verschlüsseln benötigt das Objekt den Klartext in Form einer ContentInfo Klasse,
welche beim Instanziieren an den Konstruktor übergeben wird. Die Methode Encrypt führt die
Verschlüsselung durch. Als Parameter wird ein Zertifikat mit dem öffentlichen Schlüssel in Form einer
CmsRecipient Klasse übergeben. Intern werden die Daten mit einem zufällig generierten Session Key
symmetrisch verschlüsselt. Der Session Key wird dann mit dem öffentlichen Schlüssel verschlüsselt.
Die zugelieferten Daten enthalten die verschlüsselte Nachricht sowie Informationen über den
öffentlichen Schlüssel, damit beim Entschlüsseln der dazugehörige private Schlüssel zugeordnet
werden kann. [3, p. 215]
 Zeile 22 – 23: Die verschlüsselte Nachricht wird an den Server gesendet
52
Server
1
2
3
4
5
6
7
8
9
10
11
while (true)
{
Byte[] message = Convert.FromBase64String(reader.ReadLine());
EnvelopedCms decryptedMessage = new EnvelopedCms();
decryptedMessage.Decode(message);
decryptedMessage.Decrypt();
Console.WriteLine("Received: " + Encoding.UTF8.GetString(
decryptedMessage.ContentInfo.Content));
}
Listing 34: Entschlüsseln mit Zertifikaten
 Zeile 3: Die verschlüsselten Daten vom Client werden empfangen und in ein Byte Array umgewandelt.
 Zeile 5 – 5: Die chiffrierten Nachrichten werden mithilfe des EnvelopedCms Objekts entschlüsselt. Wie
man sehen kann, muss hierzu kein Zertifikat angegeben werden. Da die verschlüsselten Daten auch
den öffentlichen Schlüssel enthalten, kann die Klasse intern nach dem dazugehörigen privaten
Schlüssel suchen. Voraussetzung ist natürlich, dass das Zertifikat mit dem privaten Schlüssel am
System installiert wurde.
 Zeile 9 – 10: Die entschlüsselten Daten werden in der Konsole ausgegeben.
5.3.2. Digital Signieren
Wie bereits unter 5.2.2 erwähnt, werden Signaturen verwendet, um Daten gegen Manipulation zu schützen.
Dazu wurde bereits ein praktisches Beispiel gezeigt, indem die Daten mit einem SHA1 Hash Algorithmus
und RSA Verschlüsselung signiert wurden. Der Empfänger konnte durch die Signatur überprüfen, ob die
Daten während der Übertragung verändert wurden. Jedoch konnte der Empfänger nicht sicherstellen, ob
der Kommunikationspartner auch wirklich der ist, für den er sich ausgibt (Prüfung der Identität). Bei
sensiblen Tätigkeiten wie dem Senden und Empfangen von Geschäftsnachrichten (E-Mails) oder Online
Banking muss sichergestellt sein, dass auch wirklich mit dem geglaubten Gegenüber kommuniziert wird.
Um dies zu gewährleisten, können digitale Zertifikate verwendet werden. Möchte eine Person Dokumente
oder E-Mails digital unterschreiben, so müssen folgende Schritte durchgeführt werden:
 Die Person muss bei einer Zertifizierungsstelle (Certification Authority, CA) um ein Zertifikat zum
digitalen Signieren ansuchen.
 Bevor die CA ein Zertifikat ausstellt, muss die Identität mittels Personalausweis überprüft werden.
 Nachdem die Identität bestätigt wurde, wird ein Zertifikat mit einem öffentlichen und einem privaten
Schlüssel für den Nutzer erstellt.
 Beim Senden einer E-Mail oder eines Dokuments fügt der Absender eine digitale Signatur hinzu.
53
 Durch die digitale Signatur kann der Empfänger den öffentlichen Schlüssel auslesen. Dadurch kann er
bei der verantwortlichen CA überprüfen, ob es sich tatsächlich um den angegebenen Absender handelt.
 Bei diesem Prozess wird vorausgesetzt, dass der Empfänger der verantwortlichen CA vertraut.
Abbildung 16: E-Mail Signatur überprüfen
In der Abbildung 16 wird die Signatur einer E-Mail überprüft. Dabei soll festgestellt werden, dass die E-Mail
Adresse [email protected] auch wirklich zu der Identität Patrick Riedl gehört. Wie man im dazugehörigen
Zertifikat sieht, wurde von der CA GlobalSign die Identität für Herrn Patrick Riedl bestätigt.
Das Signieren mit Zertifikaten in .NET funktioniert ähnlich wie das Ver- und Entschlüsseln mit Zertifikaten
(siehe 5.3.1). Der einzige Unterschied ist, dass anstelle der Klasse EnvelopedCms nun die Klasse
SignedCms verwendet wird. Um das Beispiel von Listing 33 und Listing 34 mit einer Signatur zu erweitern,
müssen folgende Anpassungen durchgeführt werden:
Client:
1
2
3
4
5
6
ContentInfo content = new ContentInfo(input);
SignedCms signedMessage = new SignedCms(content);
signedMessage.ComputeSignature (new CmsSigner(cert));
byte[] signedBytes = signedMessage.Encode();
// Encrypt und transfer signedByte to the server
Listing 35: Signatur mit einen Zertifikat erstellen
54
 Zeile 1: Die eingelesenen Daten werden nun vor dem Verschlüsseln signiert. Dazu wird wieder eine
Instanz von ContentInfo erstellt, um die Daten in einer CMS Datenstruktur abzuspeichern.
 Zeile 2 – 3: Um die Daten zu signieren, wird eine Instanz von SignedCms erstellt, welche die signierten
Daten repräsentiert. Zum Signieren benötigt das Objekt den Klartext in Form einer ContentInfo
Klasse, welche beim Instanziieren an den Konstruktor übergeben wird. Die Methode
ComputeSignature generiert den Hashwert und verschlüsselt diesen mit dem privaten Schlüssel.
Als Parameter wird daher ein Zertifikat mit dem privaten Schlüssel in Form einer CmsSigner Klasse
übergeben.
Server:
1
2
3
4
5
6
7
// Decrypt received data
SignedCms signedMessage = new SignedCms();
signedMessage.Decode(encryptedMessage.ContentInfo.Content);
signedMessage.CheckSignature(false);
foreach (SignerInfo signer in signedMessage.SignerInfos)
Console.WriteLine("Aussteller " + signer.Certificate.IssuerName.Name);
Listing 36: Signatur überprüfen
 Zeile 1: Die Daten werden empfangen und müssen mit dem privaten Schlüssel entschlüsselt werden.
(siehe Listing 34) Erst danach kann eine Integritätsprüfung durchgeführt werden.
 Zeile 3: Um nun die Signatur und das Zertifikat zu überprüfen, wird die Klasse SignedCms verwendet.
Um eine Überprüfung zu starten, müssen zuvor die CMS/PKCS #7 Daten deserialisiert werden.
 Zeile 4: Nun können die Signatur und das Zertifikat überprüft werden. Möchte man nur die Signatur
überprüfen, so muss der Parameter true übergeben werden. Tritt bei der Validierung ein Fehler auf,
so wird eine Exception ausgelöst.
 Zeile 5 – 6: Über das SignedCms Objekt kann auch auf das dazugehörige Zertifikat zugegriffen
werden. Zum Demonstrieren wird hier der Aussteller des Zertifikats ausgegeben.
55
6. Reverse Engineering
Beim Reverse Engineering wird versucht, einen kompilierten Code in den originalen Quellcode zurück zu
bringen. Dadurch können Angreifer eine Menge an Informationen gewinnen: Es können logische Abläufe,
eingesetzte Methoden oder sensible Informationen wie hartcodierte Passwörter ausgelesen werden.
Zusätzlich kann durch Reverse Engineering das Know-How gestohlen werden, wodurch ein großer
Schaden entstehen kann. [46]
Das Dekompilieren von Unmanaged Code wie C/C++ Anwendungen ist sehr schwierig, da beim
Kompilieren der Maschinencode generiert wird. Bei Managed Applikationen wie .NET ist es hingegen sehr
einfach, da nur ein Zwischencode (MSIL) erzeugt wird, welcher dann vom Just-in-time Compiler in den
Maschinencode übersetzt wird. (siehe 2.1) Da der MSIL Code sehr gut dokumentiert ist, gibt es einige
Tools, mit denen eine .NET DLL (Dynamic Link Library) oder eine EXE (Executable) rückwärtskompiliert
werden kann. [47] Dazu werden sowohl kommerzielle als auch kostenlose Programme angeboten:
 JetBrains dotPeek: kostenloser .NET Decompiler
 Dotnet IL Editor (DILE): kostenlos – ermöglicht das Dekompilieren und Debuggen von .NET
Anwendungen
 ILSpy: kostenloser und Open Source Decompiler
 Redgate .NET Reflector: kommerziell - ermöglicht das Dekompilieren und Debuggen von .NET
Anwendungen
Um nun eine .NET Anwendung zu dekompilieren, muss lediglich eines der genannten Tools geöffnet und
die gewünschte Datei (.dll oder .exe) ausgewählt werden.
56
Abbildung 17: Dekompilierte Applikation
Abbildung 18: Originaler Source Code
57
Wenn man die Abbildung 17 und Abbildung 18 vergleicht, kann man erkennen, dass durch das
Dekompilieren der originale Code ohne große Unterschiede ermittelt werden konnte. So konnten
beispielsweise die Zugangsdaten für die SQL Verbindung ausgelesen werden.
6.1.
Gegenmaßnahmen
Um Applikationen vor Reverse Engineering zu schützen, können sogenannte Obfuscating Techniken
eingesetzt werden. Dadurch wird ein gut lesbarer Quellcode in einen schwer lesbaren Code umgewandelt.
[48] Es gibt zwar keine 100%ige Sicherheit gegen das Dekompilieren, jedoch kann man es durch
Obfuscating einem Angreifer so schwer machen, damit der Aufwand zum Cracken so hoch ist, dass es
nicht mehr interessant ist. Obfuscator führen folgende Operationen durch: [49]
 Symbole umbenennen
Um Informationen wie die Namen von Variablen, Funktionen oder Klassen zu schützen, werden diese
Benennungen in nichts aussagende Namen umgewandelt. Dadurch können Programmroutinen von einem
Angreifer nicht nachvollzogen werden.
 Verschlüsselung von Zeichenketten
Wie in Beispiel von Abbildung 18 zu sehen ist, werden innerhalb des Quellcode die Zugangsdaten zu einer
Datenbank angegeben. Um solche Daten zu schützen, werden Zeichenketten während des Obfuscatings
verschlüsselt.
 Verschlüsselung von Ressourcen
Anwendungen haben in der Regel unterschiedliche Ressourcen wie Grafiken oder Konfigurationsdateien
eingebunden. Um auch diese vor unerlaubten Zugriffen zu schützen, können diese verschlüsselt werden.
 Schutz gegen Reflection
Decompiler nutzen häufig Reflections, um Informationen über eine .NET Anwendung zu gewinnen. Durch
Obfuscating kann eine Applikation so verändert werden, dass beim Benutzen von Reflections ein Fehler
ausgelöst wird.
Je nach eingesetztem Tool für den Obfuscating Prozess werden oftmals noch weitere Features angeboten.
Die meisten Obfuscator sind zwar nicht kostenlos, bieten aber dafür jede Menge an Features zum
Absichern einer Applikation. Zum professionellen Einsatz gehören Tools wie Crypto Obfuscator for .NET
(von LogicNP Software) oder Dotfuscator for .NET (von PreEmptive). Wenn man zum Beispiel den
Obfuscator „Crypto Obfuscator for .NET“ auf das Beispiel von Abbildung 18 anwendet, so würde nach dem
Dekompilieren folgendes Ergebnis erzeugt:
58
Abbildung 19: Reverse Engineering nach Obfuscating
Wie man in der Abbildung 19 sehen kann, wurde der Quellcode so verschleiert, dass weder die Namen für
Variablen oder Funktionen noch der Inhalt der Variablen ersichtlich sind.
59
7. Deployment
7.1.
Konfigurationsdaten
Häufig hat man das Problem, dass zwar grundsätzlich sichere Software eingesetzt wird, jedoch
Konfigurationsdateien mit Zugangsdaten unverschlüsselt abgespeichert werden. Dadurch sind die
Sicherheitsmechanismen der Software überflüssig, da so der Zugriff auf Daten bzw. Dienste auch
außerhalb der Software möglich wird.
Beim Absichern einer Konfiguration muss zwischen Clientanwendungen und Webanwendungen
unterschieden werden: Bei Clientanwendungen muss die Konfiguration auf jedem Computer vorhanden
sein, wo die Anwendung gestartet wird. Dies ist bei Webanwendungen nicht notwendig, da die Applikation
zentral auf einer Maschine (Webserver) läuft.
7.1.1. Clientanwendungen
Kommuniziert eine Clientanwendung (z.B. Desktopapplikation) mit einer Datenbank oder einem
Webservice, so muss die Applikation über die entsprechenden Verbindungsdaten verfügen. Heikle
Informationen wie Zugangsdaten sollten dabei auf keinen Fall im Klartext gespeichert werden, da
ansonsten ein Benutzer die Berechtigungen der Software umgehen kann.
Um dies zu gewährleisten, gibt es zwei Möglichkeiten: Entweder die sensiblen Daten werden in der
Applikation hartcodiert angegeben oder die Konfigurationsdatei wird verschlüsselt. Entscheidet man sich
für den ersten Ansatz, so sollte die Applikation unbedingt vor Reverse Engineering Attacken geschützt
werden (siehe Kapitel 6). Beim zweiten Ansatz ist die Schwierigkeit, dass die Applikation den Schlüssel
zum Entschlüsseln benötigt. Da dieser in den meisten Fällen auch hartcodiert angegeben wird, sollte auch
hier die Applikation gegen das Dekompilieren geschützt werden.
7.1.2. Webanwendungen
Bei Webanwendungen ist dieser Vorgang etwas einfacher, da die Konfiguration und die Applikation zentral
abgelegt sind. Um die Sicherheit der Webanwendung zu erhöhen, können sensible Daten in der web.config
verschlüsselt werden. [50] Sollte ein Angreifer Zugriff auf die Konfigurationsdatei bekommen, so wäre
dieser völlig nutzlos, da er die Daten nicht entschlüsseln könnte.
Die Verschlüsselung wird üblicherweise mit einem bereitgestellten Verschlüsselungsmechanismus
durchgeführt. Dazu kann entweder der RsaProtectedConfigurationProvider oder der
DpapiProtectedConfigurationProvider verwendet werden, wobei standardmäßig der RSA
Algorithmus eingesetzt wird. Beim zweiten Provider wird mithilfe der DPAPI (Data Protection API) verund
entschlüsselt. Die DPAPI ist Bestandteil eines Windows Betriebssystem, welches die Aufgabe der
Schlüsselverwaltung übernimmt. Bei Bedarf kann auch ein eigener Provider entworfen und verwendet
werden. [51]
60
Bei jeder Installation des .NET Frameworks wird ein RSA Key Container mit dem Namen
NetFrameworkConfigurationKey mitinstalliert. In diesem befindet sich ein öffentlich/privates
Schlüsselpaar, welches für die Ver- und Entschlüsselung der Konfigurationsabschnitte verwendet wird. [52]
Da dieser Schlüssel bei jeder Installation unterschiedlich ist, kann die Konfiguration nur auf der gleichen
Maschine verwendet werden. Besteht der Bedarf, auf mehreren Maschinen dieselbe verschlüsselte
Konfiguration zu verwenden, so kann ein eigener Container generiert und auf andere Maschinen importiert
werden. [53] Damit aus einer Webanwendung direkt auf die verschlüsselte Konfiguration zugegriffen
werden kann, muss die „Application Pool Identity“ der Webapplikation eine Leseberechtigung für den
entsprechenden Container haben. [51] Dies kann mit Befehl aspnet_regiis durchgeführt werden,
welcher unter C:\Windows\Microsoft.NET\Framework\<Version> zu finden ist:
1
aspnet_regiis -pa "<Name des Container>" "<Benutzername>"
Um Daten in der Konfiguration zu verschlüsseln, muss keine einzige Zeile Code geschrieben werden, da
der gesamte Prozess mit der Konsole durchgeführt werden kann. Dazu muss wieder der Befehl
aspnet_regiss verwendet werden, welcher als Parameter den gewünschten Abschnitt in der
Konfiguration sowie den Name der Webapplikation benötigt:
1
aspnet_regiis -pe "<Konfigurationsabschnitt>" -app "<Webapplikation>"
Um beispielsweise den ConnectionString der Webapplikation „SecureWebapplication“ zu verschlüsseln,
muss der folgende Befehl ausgeführt werden:
1
aspnet_regiis.exe -pe "connectionStrings" -app "SecureWebapplikation"
Möchte man den ConnectionString nachträglich ändern, so muss der Konfigurationsabschnitt zuerst
entschlüsselt und danach entsprechend angepasst werden. Danach kann die Verschlüsslung erneut
durchgeführt werden:
1
7.2.
aspnet_regiis.exe -pd "connectionStrings" -app "SecureWebapplikation"
Strong Names
Bei größeren Softwareprojekten werden Abläufe oder Routinen häufig in Bibliotheken wie DLLs (Dynamic
Link Library) ausgelagert, da diese später in anderen Projekten wiederverwendet werden können. Solche
Bibliotheken werden zur Laufzeit von der jeweiligen Applikation geladen. Würde es einem Angreifer
gelingen, eine Bibliothek so zu manipulieren, dass zusätzlich zum ursprünglichen Code auch noch ein
Schadcode ausgeführt wird, so wäre die Applikation kompromittiert. Um dies zu verhindern, können
Komponenten mit einem sogenannten Strong Name signiert werden. [54] Durch einen Strong Name erhält
eine Komponente eine global eindeutige Identität, welche aus einem Namen (z.B. Name der Bibliothek),
der Version und Kulturinformation sowie einem öffentlichen Schlüssel und einer digitalen Signatur besteht.
[55]
61
Ein Strong Name kann mithilfe des Visual Studio sehr einfach erstellt werden. Dazu sind folgende Schritte
durchzuführen:
 die Eigenschaften des Projekts aufrufen (Rechtsklick auf das Projekt – Eigenschaften/Properties)
 in der linken Spalte den Menüpunkt “Signierung/Signing” auswählen
 die Option “Assembly signieren/Sign the assembly” setzen - Zusätzlich muss ein Key File angegeben
werden, welches den privaten und öffentlichen Schlüssel enthält. Bei Bedarf kann der Schlüssel auch
hier erzeugt werden.
Abbildung 20: Signieren einer .NET Bibliothek
 Die Version und Kulturinformationen können unter “Anwendung – Assembly Informationen” angegeben
werden.
62
Abbildung 21: Information einer Assembly setzen
 Nachdem die Bibliothek erstellt worden, kann diese in andere Applikationen eingebunden werden. Wird
die eingebundene Komponente manipuliert, wird folgende Exception ausgelöst:
Abbildung 22: Exception bei manipulierten Bibliotheken
7.3.
ClickOnce-Bereitstellung
ClickOnce wurde von Microsoft entwickelt und dient zum Verteilen von .NET Anwendungen (WinForms,
WPF) über das Netzwerk. [56] Klein- oder Mittelunternehmen besitzen häufig keine Systeme für Software
Rollouts, wodurch das Verteilen und die Wartung von Applikationen sehr mühsam ist.
Mit ClickOnce kann ein Link bereitgestellt werden, über den sich die Benutzer eine Applikation selbst
installieren können. Dieser benötigt keine Administrationsberechtigungen, da die Anwendung in einem
Benutzerverzeichnis installiert wird. Dadurch kann die Anwendung nur vom aktuellen Benutzer genutzt
werden. Ein weiteres Feature von ClickOnce ist der mitgelieferte Aktualisierungsprozess. Bei jedem Start
einer ClickOnce Anwendung wird überprüft, ob eine neue Version bereitsteht. Wenn ja, wird die alte Version
automatisch deinstalliert und die neue installiert. [56] So können Updates rasch und unkompliziert
ausgerollt werden.
Um eine Anwendung mithilfe von ClickOnce bereitzustellen, müssen folgende Schritte durchgeführt
werden:
 in Visual Studio in die Projekteigenschaften der gewünschten Applikation wechseln
 auf der linken Seite den Menüpunkt „Veröffentlichen/Publish“ auswählen
63
Abbildung 23: Applikation mittels ClickOnce bereitstellen
Informationen zu den Optionen können unter
 http://openbook.galileocomputing.de/visual_csharp_2010/visual_csharp_2010_30_002.htm#mjaa7397
d5ca453f2628726d80fab473f3
 http://msdn.microsoft.com/de-de/library/142dbbz4(v=vs.90).aspx
nachgelesen werden.
Mit ClickOnce werden auch sicherheitstechnische Aspekte wie die Signierung von Anwendungs- und
Bereitstellungsmanifesten unterstützt. Details dazu können unter http://msdn.microsoft.com/enus/library/zfz60ccf(v=vs.80).aspx abgerufen werden.
64
8. Konzeptionierung eines Secure Coding Demonstrators
Im Zuge dieser Arbeit wurde ein .NET Demonstrator entwickelt, um die gezeigten Schwachstellen und
Lösungen auch in Schulungen bzw. Trainings präsentieren zu können.
8.1.
Web Security
Es wurden zwei Webapplikationen entwickelt, welche typische Anwendungsfälle wie Benutzeranmeldung
oder benutzerspezifische Datenverwaltung abbilden. Beide Applikationen besitzen zwar das gleiche Design
und dieselben Funktionalitäten, jedoch wurden bei einer Anwendung die hier beschriebenen Best Practice
Ansätze verwendet. Bei der Anderen wurden auf jegliche Sicherheitsfunktionalitäten verzichtet. Durch ein
ausgeklügeltes Demo-Szenario können die Benutzer die unsichere Anwendung Schritt für Schritt angreifen
und somit unberechtigt Zugriff auf Daten erlangen.
Die Applikation demonstriert ein Portal zum Verwalten von Meilen, wobei die Meilen für ein Prämienmodell
á la Miles and More verwendet werden. Meilen können von Mitarbeitern beantragt werden, indem sie einen
Event Eintrag erstellen. Dieser Eintrag besteht aus einem Eventname und Eventtyp (z.B. Buch gelesen,
Schulung teilgenommen, Wiki-Eintrag geschrieben). Die gesammelten Meilen können dann entweder
gegen Produkte eingetauscht oder an andere Benutzer übertragen werden. Ist der angemeldete Benutzer
Mitglied der Administrator-Rolle, so können administrative Funktionen, wie das Verwalten von Benutzern,
von Produkten, usw. ausgeführt werden. In der Tabelle 4 werden alle Funktionen der Anwendung
aufgelistet.
Funktion
Meilen beantragen
Meilen inklusive Status abrufen
Meilen bearbeiten und entfernen
Status von Meilen vergeben
Meilen an andere Benutzer übertragen
Produkte erstellen, bearbeiten und entfernen
Produkte kaufen
Gekaufte Produkte auflisten
Eventtypen erstellen, bearbeiten und entfernen
Benutzer erstellen und entfernen
Passwort zurücksetzen
Übersicht über alle Meilen-Transaktionen abrufen
Berechtigung
Mitarbeiter, Administrator
Mitarbeiter: nur die eigenen Meilen
Administrator: alle Meilen
Mitarbeiter: nur die eigenen Meilen
Administrator: alle Meilen
Administrator
Administrator
Mitarbeiter: nur die eigenen Produkte
Administrator: alle Produkte
Administrator
Administrator
Mitarbeiter: nur das eigene Passwort
Administrator: alle Passwörter
Tabelle 4: Funktionalitäten der Demo Webapplikation
Um die unsichere Webapplikation nun anzugreifen, können folgende Schritte durchgeführt werden:
 Login: Da unsichere Datenbankzugriffe implementiert wurden, kann hier eine SQL Injection
durchgeführt werden.
65
 Erstellen von Meilen: Da die eingegebenen Daten eins zu eins in die Datenbank übernommen werden,
kann man hier eine XSS Attacke anwenden.
 Auflisten der Meilen: Die aufgelisteten Meilen können mithilfe eines Suchfilters eingeschränkt werden.
Dieser Filter kann für eine SQL Injection missbraucht werden, um beispielsweise Daten von anderen
Benutzern abzufragen. Weiters können Details der Datenbank mittels Blind SQL Injection ermittelt
werden.
 Übertragen von Meilen: Mittels einer CSRF Attacke kann sich ein Angreifer Meilen von seinem Opfer
auf sein Konto übertragen.
 Abrufen der Meilen-Transaktionen: Um die Transaktionsliste von einem anderen Benutzer
anzuzeigen, kann eine Direct Object References Schwachstelle ausgenutzt werden.
Login
Meilen
beantragen
Meilen
abrufen
Meilen
einlösen/übertragen
Transaktionen
abrufen
Abbildung 24: Herkömmlicher Ablauf des Web Security Demonstrators
Login
SQL Injection
Meilen
beantragen
XSS Attacke
Meilen
abrufen
Blind SQL
Injection
Meilen
einlösen/übertragen
CSRF Attacke
Transaktionen
abrufen
Direct Object
Reference Attacke
Abbildung 25: Angriffsvektoren des Web Security Demonstrators
8.2.
Kryptographie
Der Demonstrator für die vorgestellten kryptografischen Techniken besteht aus einer Client und einer
Server Anwendung, welche über einen TCP Port kommunizieren. Für jede Verschlüsselungsart wurde eine
eigene Klasse implementiert, wobei jede Klasse die Methode Start() besitzt. Dadurch können in
Schulungen die Verschlüsselungsarten einfach und schnell präsentiert werden, weil nur die gewünschte
Klasse instanziiert und die Start Methode ausgeführt werden muss. Wie man in Listing 37 sieht, werden
die gerade nicht benötigten Verschlüsselungsalgorithmen auskommentiert, damit nur die gewünschte
Verschlüsselung zum Einsatz kommt. Am Server muss natürlich auch die dazu passende Methode
aufgerufen werden.
1
2
3
4
5
6
7
SymmetricClient symmetricClient = new SymmetricClient();
SymmetricDhClient symmetricDhClient = new SymmetricDhClient();
AsymmetricClient asymmetricClient = new AsymmetricClient();
CertificateClient certEncryptClient = new CertificateClient();
// symmetricClient.Start();
// symmetricDhClient.Start();
66
8
9
// asymmetricClient.Start();
certEncryptClient.Start();
Listing 37: Demonstrator: Start des gewünschten Verschlüsselungsalgorithmus
Da die Kommunikation über TCP läuft, kann ein Netzwerk Sniffer verwendet werden, um die
ausgetauschten Daten zu analysieren.
8.3.
WCF
Gleich wie bei dem Demonstrator für Kryptographie wurde auch für WCF eine Client/Server Applikation
entwickelt. Dadurch können die ausgetauschten Daten mithilfe eines Netzwerk Sniffer nachvollzogen
werden. Somit kann man demonstrieren, dass bei einer unsicheren Endpoint Konfiguration die Daten im
Klartext übertragen werden.
67
9. Zusammenfassung & Ausblick
Anhand dieser Arbeit kann erkannt werden, dass das .NET Framework eine sehr mächtige
Laufzeitumgebung ist, welche eine Menge an Sicherheitsfeatures mitliefert. Es wurde gezeigt, wie typische
Webschwachstellen wie beispielsweise Cross-Site-Scripting oder SQL Injection mittels .NET Framework
verhindert werden können. Weiters wurde gezeigt, wie die Kommunikation mit ASP.NET Webservices und
WCF Anwendungen sicher umgesetzt werden kann. Auch das Thema Kryptographie wurde detailliert
behandelt. Dazu wurden .NET Bibliotheken sowohl theoretisch als auch praktisch vorgestellt, um Daten zu
verschlüsseln, entschlüsseln und signieren. Zu guter Letzt wurde auch ein Einblick in Reverse Engineering
und sicheres Deployment gegeben, um fertige Anwendungen sicher bereitstellen zu können.
Das Thema wird weiterhin von Bedeutung sein, gerade weil vor kurzem wieder neue .NET Features
vorgestellt wurden: ASP.NET (ASP vNext) enthält weitere Cloud Optimierung und läuft nun neben Windows
auch auf Linux und Mac OS. Dazu könnten in weiteren Arbeiten die angebotenen Sicherheitslösungen für
Cloud Anwendungen untersucht werden. Auch die Unterstützung von Cross-Device Entwicklung wurde
weiter verbessert, wodurch der gleiche Code auf unterschiedlichen Geräten wie Phone, Tablet, Desktop
und Xbox verwendet werden kann. Dazu wäre interessant zu erforschen, inwieweit auch
Sicherheitsfeatures geräteübergreifend eingesetzt werden können.
Das .NET Framework wird sich auch in Zukunft rasant weiterentwickeln, um Entwickler bei den neuen IT
Trends zu unterstützen. Aus diesem Grund kann diese Arbeit als Grundlage für die Entwicklung von
sicheren .NET Applikationen oder weitere wissenschaftliche Arbeiten zu diesem Thema verwendet werden.
9.1.
Weitere Fehlerquellen
Trotz der vielen vorgestellten Maßnahmen kann nicht garantiert werden, dass erfolgreiche Attacken auf
eine Anwendung unmöglich sind. Durch die rasante technische Entwicklung werden täglich neue
Angriffsmöglichkeiten entdeckt, wodurch Sicherheitsmechanismen ausgehebelt werden können.
Läuft eine Webapplikation beispielsweise auf einem veralteten Webserver, so könnte ein Angreifer
Sicherheitslücken des Servers ausnutzen, um unberechtigt auf die Daten der Anwendung zuzugreifen. Aus
diesem Grund sollten Systeme wie das Betriebssystem, das Datenbanksystem oder der Webserver immer
mit den aktuellsten Sicherheitspatches vorsorgt werden. Es ist auch zu beachten, dass eine
Webanwendung mit einem eingeschränkten Benutzerkonto ausgeführt werden sollte. Dadurch kann ein
Angreifer bei einer erfolgreichen Attacke nur beschränkt Aktionen am betroffenen System ausführen.
Bei größeren Softwareprodukten werden meist auch externe Bibliotheken von unterschiedlichen
Herstellern verwendet. Diese sollten regelmäßig auf Updates geprüft werden, um Fehler und
Sicherheitslücken rasch zu beheben. Externe Bibliotheken für das .NET Framework werden häufig über
NuGet veröffentlicht, wodurch eine einfache Paketverwaltung in Visual Studio ermöglicht wird.
Zuletzt muss noch gesagt werden, dass menschliche Fehler und Missbräuche nicht außer Acht gelassen
werden dürfen. Es kommt immer wieder vor, dass vertrauliche Daten von internen Mitarbeitern an
Außenstehende weiterverkauft werden. Dadurch können Konkurrenzunternehmen oder kriminelle
Organisationen Zugriff auf geheime Daten erlangen und diese für unerwünschte Zwecke gebrauchen.
Daher sollten alle Unternehmen lückenlose Verträge besitzen, um gegen solche Verstöße rechtlich
vorgehen zu können.
68
Literaturverzeichnis
[1 R. Siciliano, „infosec ISLAND,“ Wired Business Media, 22 April 2011. [Online]. Available:
] http://www.infosecisland.com/blogview/13075-Software-Security-Incidents-Cost-an-Average300000.html. [Zugriff am 03 April 2014].
[2 D. Rice, Geekonomics: The Real Cost of Insecure Software, Boston: Addison-Wesley Professional,
] 2008.
[3 S. Zahedani, Sichere Software mit Microsoft .NET entwickeln, Frankfurth am Main: Software & Support
] Verlag GmbH, 2007.
[4 Microsoft,
„Overview
of
the
.NET
Framework,“
] http://www.microsoft.com/net. [Zugriff am 04 04 2014].
Microsoft,
[Online].
Available:
[5 Xamarin , „mono,“ Xamarin , [Online]. Available: http://www.mono-project.com. [Zugriff am 04 04 2014].
]
[6 Microsoft Corporation, „Programmiersprachen,“ Microsoft Corporation, [Online].
] http://msdn.microsoft.com/de-de/library/aa292164(v=vs.71).aspx. [Zugriff am 7 4 2014].
Available:
[7 ITWissen,
„CTS
(common
type
system),“
ITWissen,
[Online].
Available:
] http://www.itwissen.info/definition/lexikon/CTS-common-type-system.html. [Zugriff am 8 4 2014].
[8 Microsoft Corporation, „Common Type System,“ Microsoft Corporation, [Online]. Available:
] http://msdn.microsoft.com/en-us/library/vstudio/zcx1eb1e(v=vs.100).aspx. [Zugriff am 7 4 2014].
[9 Microsoft Corporation, „.NET Framework Class Library,“ Microsoft Corporation, 12 2009. [Online].
] Available: http://msdn.microsoft.com/en-us/library/vstudio/ms229335(v=vs.90).aspx. [Zugriff am 9 6
2014].
[1 W. Fischereder, „The Common Intermediate Language (CIL),“ [Online]. Available: http://www.ssw.uni0] linz.ac.at/Teaching/Lectures/Sem/2003/reports/Fischereder/Fischereder.pdf. [Zugriff am 9 6 2014].
[1 Microsoft Corporation, „Common Language Runtime (CLR),“ Microsoft Corporation, [Online]. Available:
1] http://msdn.microsoft.com/de-de/library/8bs2ecf4(v=vs.110).aspx. [Zugriff am 9 6 2014].
[1 A. Adya, J. A. Blakeley, S. Melnik, und S. Muralidhar, „Anatomy of the ADO.NET Entity Framework,“ in
2] SIGMOD '07, Beijing, China, 2007.
[1 „ADO.NET Entity Framework Architecture,“ 9 4 2012. [Online]. Available: http://csharp3] guide.blogspot.co.at/2012/05/adonet-entity-framework-architecture.html. [Zugriff am 9 04 2014].
[1 P. Pialorsi und M. Russo, Introducing Microsoft Linq, Redmond, WA, USA: Microsoft Press, 2007.
4]
[1 D. Fox, „Cross Site Scripting (XSS),“ DuD - Datenschutz und Datensicherheit, Nr. 11, 11 2012.
5]
[1 OWASP Foundation, „Cross-site Scripting (XSS),“ OWASP Foundation, 22 4 2014. [Online]. Available:
6] https://www.owasp.org/index.php/Cross-site_Scripting_(XSS). [Zugriff am 9 6 2014].
[1 OWASP Foundation, „SQL Injection,“ OWASP Foundation, 12 4 2014. [Online]. Available:
7] https://www.owasp.org/index.php/SQL_Injection. [Zugriff am 9 6 2014].
[1 Microsoft Corporation, „ADO.NET Data Providers,“ Microsoft Corporation, [Online]. Available:
8] http://msdn.microsoft.com/en-us/data/dd363565. [Zugriff am 12 6 2014].
[1 Microsoft Corporation,
„Version History,“
Microsoft Corporation,
9] http://msdn.microsoft.com/en-us/data/jj574253.aspx. [Zugriff am 12 6 2014].
[Online].
Available:
69
[2 J. Meier, A. Mackman, B. Wastell und Prashant, „Protect From SQL Injection in ASP.NET,“ Microsoft
0] Corporation,
5
2005.
[Online].
Available:
http://msdn.microsoft.com/enus/library/ff648339.aspx#paght000002_step3. [Zugriff am 28 4 2014].
[2 OWASP Foundation, „Blind SQL Injection,“ OWASP Foundation, 26 8 2013. [Online]. Available:
1] https://www.owasp.org/index.php/Blind_SQL_Injection. [Zugriff am 3 5 2014].
[2 OWASP Foundation, „Insecure Direct Object Reference Prevention Cheat Sheet,“ OWASP
2] Foundation, 18 04 2010. [Online]. Available: https://www.owasp.org/index.php/Top_10_2007Insecure_Direct_Object_Reference. [Zugriff am 28 4 2014].
[2 E. Lippert, „GUID guide,“ Fabulous Adventures In Coding, 30 4 2012. [Online]. Available:
3] http://blogs.msdn.com/b/ericlippert/archive/2012/04/30/guid-guide-part-two.aspx. [Zugriff am 28 4
2014].
[2 OWASP Foundation, „Cross-Site Request Forgery (CSRF),“ OWASP Foundation, 9 11 2013. [Online].
4] Available: https://www.owasp.org/index.php/CSRF. [Zugriff am 20 4 2014].
[2 W. Mike, „Preventing Cross-Site Request Forgery (CSRF) Attacks,“ Microsoft Corporation, 12 12 2012.
5] [Online].
Available:
http://www.asp.net/web-api/overview/security/preventing-cross-site-requestforgery-(csrf)-attacks. [Zugriff am 4 5 2014].
[2 T. Dykstra, „Creating ASP.NET Web Projects in Visual Studio 2013,“ Microsoft Corporation, 9 9 2013.
6] [Online]. Available: http://www.asp.net/visual-studio/overview/2013/creating-web-projects-in-visualstudio#auth. [Zugriff am 15 5 2014].
[2 H. Sun, „Understanding OWIN Forms authentication in MVC 5,“ Microsoft Corporation, 3 7 2013.
7] [Online]. Available: http://blogs.msdn.com/b/webdev/archive/2013/07/03/understanding-owin-formsauthentication-in-mvc-5.aspx. [Zugriff am 5 5 2014].
[2 Microsoft Corporation, „ASP.NET Web API,“ Microsoft Corporation, [Online].
8] http://msdn.microsoft.com/en-us/library/hh833994(v=vs.108).aspx. [Zugriff am 9 6 2014].
Available:
[2 M. Cretzman und T. Weeks, „Best Practices for Preventing DoS/Denial of Service Attacks,“ Microsoft
9] Corporation, [Online]. Available: http://technet.microsoft.com/en-us/library/cc750213.aspx. [Zugriff am
12 6 2014].
[3 Microsoft Corporation, „Open Data Protocol,“
0] http://www.odata.org/. [Zugriff am 5 5 2014].
Microsoft
Corporation,
[Online].
Available:
[3 H. Ge, „Protect your Queryable API with the validation feature in ASP.NET Web API OData,“ Microsoft
1] Corporation,
6
2
2013.
[Online].
Available:
http://blogs.msdn.com/b/webdev/archive/2013/02/06/protect-your-queryable-api-with-validationfeature-in-asp-net-web-api-odata.aspx. [Zugriff am 12 6 2014].
[3 J. Liberty und H. Alex, Programming .NET 3.5, Sebastopol: O'Reilly Media, Inc, 2008.
2]
[3 D. Chappell, „Introducing Windows Communication Foundation,“ 1 2010. [Online]. Available:
3] http://download.microsoft.com/download/C/2/5/C2549372-D37D-4F55-939A74F1790D4963/Introducing_WCF_in_NET_Framework_4.pdf. [Zugriff am 12 5 2014].
[3 Microsoft Corporation, „WCF Essentials: Contracts,“ Microsoft Corporation, [Online]. Available:
4] http://msdn.microsoft.com/en-us/library/ff183866.aspx. [Zugriff am 12 6 2014].
[3 Microsoft Corporation, „How to: Use a Custom User Name and Password Validator,“ Microsoft
5] Corporation, [Online]. Available: http://msdn.microsoft.com/en-us/library/aa702565(v=vs.110).aspx.
[Zugriff am 12 6 2014].
[3 Microsoft Corporation, „How to: Use the ASP.NET Membership Provider,“ Microsoft Corporation,
6] [Online]. Available: http://msdn.microsoft.com/en-us/library/ms731049(v=vs.110).aspx. [Zugriff am 12
6 2014].
70
[3 Microsoft Corporation, „WCF and ASP.NET Web API,“ Microsoft Corporation, [Online]. Available:
7] http://msdn.microsoft.com/en-us/library/jj823172(v=vs.110).aspx. [Zugriff am 13 5 2014].
[3 Network Associates International BV., „Einführung in die Kryptographie,“ 24 12 1999. [Online].
8] Available: ftp://ftp.pgpi.org/pub/pgp/6.5/docs/german/IntroToCrypto.pdf. [Zugriff am 6 5 2014].
[3 A. Beutelspacher, J. Schwenk und K.-D. Wolfenstetter, Moderne Verfahren der Kryptographie,
9] Wiesbaden: Vieweg+Teubner Verlag | Springer Fachmedien Wiesbaden GmbH 2010 , 2010.
[4 Microsoft Corporation, „ECDiffieHellmanCng Class,“ Microsoft Corporation, [Online]. Available:
0] http://msdn.microsoft.com/en-us/library/system.security.cryptography.ecdiffiehellmancng.aspx. [Zugriff
am 08 05 2014].
[4 Bundesamt für Sicherheit in der Informationstechnik, „Asymmetrische Verschlüsselung,“ Bundesamt
1] für
Sicherheit
in
der
Informationstechnik,
[Online].
Available:
https://www.bsi-fuerbuerger.de/BSIFB/DE/SicherheitImNetz/Verschluesseltkommunizieren/Grundlagenwissen/Asymmetri
scheVerschluesselung/asymmetrische_verschluesselung_node.html. [Zugriff am 12 6 2014].
[4 F. Bourseau und D. Fox, „Vorzüge und Grenzen des RSA-Verfahrens,“ Datenschutz und
2] Datensicherheit, pp. 84-89, 2002.
[4 GlobalSign, „PersonalSign-Zertifikate,“ GlobalSign, [Online]. Available: https://www.globalsign.com/de3] de/personalsign/. [Zugriff am 9 6 2014].
[4 K. K. Panday , „Various SSL/TLS Certificate File Types/Extensions,“ Microsoft Corporation, 4 11 2010.
4] [Online]. Available: http://blogs.msdn.com/b/kaushal/archive/2010/11/05/ssl-certificates.aspx. [Zugriff
am 12 6 2014].
[4 D. Baier, „Unterstützen von Zertifikaten in Anwendungen mit .NET Framework 2.0,“ 3 2007. [Online].
5] Available: http://msdn.microsoft.com/de-de/magazine/cc163454.aspx. [Zugriff am 10 5 2014].
[4 S. Tahiri, „Demystifying Dot NET Reverse Engineering,“ 24 10 2012. [Online]. Available:
6] http://resources.infosecinstitute.com/demystifying-dot-net-reverse-engineering-part-1-bigintroduction/. [Zugriff am 9 6 2014].
[4 T. Patton, „Reverse engineering your .NET applications,“ 17 5 2013. [Online]. Available:
7] http://www.techrepublic.com/blog/software-engineer/reverse-engineering-your-net-applications/.
[Zugriff am 12 6 2014].
[4 G. Torok und B. Leach, „Thwart Reverse Engineering of Your Visual Basic .NET or C# Code,“ Microsoft
8] Corporation,
12
2003.
[Online].
Available:
http://msdn.microsoft.com/enus/magazine/cc164058.aspx#S3. [Zugriff am 12 6 2014].
[4 LogicNP Software, „8 Ways To Protect And Obfuscate Your .Net Code Against Reverse-Engineering
9] Using
Crypto
Obfuscator,“
LogicNP
Software,
[Online].
Available:
http://www.ssware.com/articles/protect-and-obfuscate-your-dotnet-code-against-reverse-engineeringusing-crypto-obfuscator.htm. [Zugriff am 12 6 2014].
[5 Microsoft Corporation, „Overview of Protected Configuration,“ Microsoft Corporation, [Online].
0] Available: http://msdn.microsoft.com/en-us/library/hh8x3tas(v=vs.100).aspx. [Zugriff am 12 6 2014].
[5 Microsoft Corporation, „Encrypting Configuration Information Using Protected Configuration,“ Microsoft
1] Corporation, [Online]. Available: http://msdn.microsoft.com/en-us/library/53tyfkaw(v=vs.100).aspx.
[Zugriff am 17 5 2014].
[5 J.
Roberts,
„Protected
Configuration,“
Blayd
Software,
2] http://www.blayd.co.uk/article.aspx?pageid=1012. [Zugriff am 12 6 2014].
[Online].
Available:
[5 Microsoft Corporation, „Importing and Exporting Protected Configuration RSA Key Containers,“
3] Microsoft
Corporation,
[Online].
Available:
http://msdn.microsoft.com/enus/library/yxw286t2(v=vs.100).aspx. [Zugriff am 12 6 2014].
[5 Microsoft Corporation, „Strong-Named Assemblies,“ Microsoft Corporation, [Online]. Available:
4] http://msdn.microsoft.com/en-us/library/wd40t7ad(v=vs.110).aspx. [Zugriff am 12 6 2014].
71
[5 Microsoft Corporation, „Signierung mit starken Namen für verwaltete Anwendungen,“ Microsoft
5] Corporation,
11
2007.
[Online].
Available:
http://msdn.microsoft.com/dede/library/h4fa028b(v=vs.90).aspx. [Zugriff am 19 5 2014].
[5 Microsoft Corporation, „Übersicht über die ClickOnce-Bereitstellung,“ Microsoft Corporation, 11 2007.
6] [Online]. Available: http://msdn.microsoft.com/de-de/library/142dbbz4(v=vs.90).aspx. [Zugriff am 19 5
2014].
[5 S. Sanderson, „Prevent Cross-Site Request Forgery (CSRF) using ASP.NET MVC’s
7] AntiForgeryToken()
helper,“
1
9
2008.
[Online].
Available:
http://blog.stevensanderson.com/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnetmvcs-antiforgerytoken-helper/. [Zugriff am 4 5 2014].
[5 S. Hongye, „Understanding OWIN Forms authentication in MVC 5,“ Microsoft Corporation, 7 3 2013.
8] [Online]. Available: http://blogs.msdn.com/b/webdev/archive/2013/07/03/understanding-owin-formsauthentication-in-mvc-5.aspx. [Zugriff am 28 05 2014].
[5 V. Raja und K. J. Fernandes, Reverse Engineering - An Industrial Perspective, London: Springer
9] Verlag, 2008.
72

Secure .NET Development

Transcription

Similar documents

Intrusion Prevention: Neue Trends aus den USA