Zusammenfassung
Technische Sicherheitsmaßnahmen stellen den zentralen Aspekt der Anwendungssicherheit und damit auch dieses Buches dar. Die große Schwierigkeit besteht dabei zum einen darin, die richtigen Maßnahmen auszuwählen, zum anderen, diese korrekt umzusetzen.
Die einzige Hoffnung, die wir haben, um die Probleme der IT-Sicherheit in den Griff zu bekommen, besteht darin, Sichserheitsaspekte von Beginn an einzubauen, Gary McGraw, CTO, Cigital Inc.
This is a preview of subscription content, log in via an institution to check access.
Access this chapter
Tax calculation will be finalised at checkout
Purchases are for personal use only
Notes
- 1.
Laut Verizons Data Breach Report 2011, traten 11 % der bekannt gewordenen Datenlecks bei Webseiten auf, welche kürzlich nach PCI-DSS auditiert wurden (vergl. [6]).
- 2.
- 3.
- 4.
Selbst bei Einsatz eines ORM-Frameworks ist Interpreter Injection weiterhin potentiell möglich. Denn diese stellen APIs zur Verfügung, in denen sich grundsätzlich ebenfalls nicht validierte Benutzerparameter einbauen lassen. Im Fall von Hibernate betrifft dies etwa die Search-API. Wir sprechen hier dann auch allgemein von ORM Injection oder (ganz konkret im Fall von Hibernate) von HQL Injection (CWE 564). Auch diese Parameter sollten wir daher entsprechend enkodieren bevor sie in einem API-Aufruf verwendet werden.
- 5.
Eine Liste der in Firefox verwendeten Root-Zertifikate findet sich z. B. unter http://www.mozilla.org/projects/security/certs/included.
- 6.
Siehe hierzu das einleitende Kapitel zu Enkodierung (Abschn. 1.2.7). Ebenfalls lesenswert ist in diesem Zusammenhang das XSS Filter Evasion Cheat Sheet der OWASP (https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet), das SQL Injection Cheat Sheet auf ha.ckers.org (http://ha.ckers.org/sqlinjection/) sowie http://html5sec.org.
- 7.
Auch zu diesem Thema ist ein hilfreiches Cheat Sheet auf der Webseite der OWASP verfügbar (vergl. [46]).
- 8.
Aber Vorsicht: Die XSD-Validierungen können auch als Quelle für DoS-Angriffe genutzt werden, wenn das Schema nicht in sich geschlossen oder zu komplex ist.
- 9.
Denn in der Praxis ist dieses Verfahren keinesfalls so anonym wie es vielleicht auf den ersten Blick den Anschein macht. Schnell können hierbei Rückschlüsse auf eine natürliche Person gewonnen werden, etwa wenn sich ein Besucher von demselben System aus an einer Webanwendung anmeldet.
- 10.
Mit Evercookie (http://en.wikipedia.org/wiki/Evercookie) existiert sogar ein JavaScript-API, das alle hier genannten Verfahren transparent verwendet.
- 11.
Vollständige Zufälligkeit inkl. Sonderzeichen, Länge mindestens 20, besser 30 Zeichen sowie Umsetzung der Maßnahmen zur Speicherung kryptographischer Schlüssel (Abschn. 3.14.2).
- 12.
Bei priviligierten Accounts sollte stets eine höhere Stärke der Authentifizierung angestrebt werden, idealerweise durch Verwendung von Mehrfaktor-Authentifizierung (z. B. RSA-Token). Denn Passwörter alleine können „per Design“ immer nur eine eingeschränkte Schutzfunktion bieten.
- 13.
Wovon allerdings sehr stark abzuraten ist. Schließlich kann nicht ausgeschlossen werden, dass diese „Dienstleistungen“ mit einer kriminellen Motivation betrieben werden und darüber geknackte Passwörter zudem Aufschluss über deren Herkunft liefern können.
- 14.
PBKDF2 wird etwa von Truecrypt zur Speicherung der Passwörter verwendet und konnte nicht einmal vom FBI in einem Jahr Berechnungszeit geknackt werden (vergl. [67]).
- 15.
In mancher Literatur wird ein sogenannter „Double Submit Cookie“ empfohlen. Dabei wird die Session-ID zusätzlich zum Cookie in die URL geschrieben. Dieser Ansatz lässt sich sehr einfach implementieren, da er völlig ohne einen serverseitigen State auskommt. Allerdings ist er insofern falsch, als sensible Daten (nämlich die Session-ID) in die URL geschrieben werden, was ein Anti-Pattern darstellt.
- 16.
- 17.
Eine HTTP Origin bezeichnet laut RFC6454 die Kombination aus Protokoll, Host und Port, also z. B. "HTTPS" + "www.example.com" + "443".
- 18.
Obwohl OAuth ausschließlich ein Autorisierungsprotokoll ist, lässt sich darüber indirekt auch eine Authentifizierungsfunktion abbilden. Zum einen ist dies über die Integration des OpenID-Protokolls selbst möglich, zum anderen mittels einem Mechanismus, der als OAuth-Pseudo-Authentication bezeichnet wird und in Verbindung mit einem beliebigen Authentifizierungsdienst eingesetzt werden kann. An letzterem wird ein Benutzer (Konsument) implizit über OAuth-Tokens authentifiziert. Das lässt sich damit vergleichen, dass eine Person ihre Adresse gegenüber einem Dritten nicht über den Personalausweis nachweist, sondern einen Brief vorweist, der an die Adresse gesendet wurde. Der Brief entspricht einem OAuth-Token. OAuth klammert in diesem Fall das konkrete Verfahren aus und bezieht sich nur auf den zu erbringenden Nachweis (daher auch „Pseudo Authentication“).
- 19.
Mit „Access Tokens“ wurden im vorherigen Abschnitt alle möglichen zur Autorisierung einsetzbaren Tokens bezeichnet. In diesem Zusammenhang sind jedoch ausschließlich OAuth Access Tokens gemeint.
- 20.
Lodderstedt et Al. beschreiben als weitere Sicherheitsfunktion die Einrichtung eines Dienstes über den der Client einen Access Token jederzeit wiederrufen kann (vergl. [74]).
- 21.
Content-Security-Policy ist der vom W3C vorgegebene Standard. Ältere Browser unterstützen teilweise Subsets dieses Standards, die über die Header X-Content-Security-Policy (Firefox < 23 und IE > = 10) sowie X-WebKit-CSP (Chrome < 25) zusätzlich angegeben werden müssen. Von der Verwendung des letztgenannten Headers kann aufgrund der sehr eingeschränkten Verbreitung älterer Chrome-Versionen abgesehen werden.
- 22.
Mittels MIME Sniffing versucht ein Browser einen Datentyp auf Basis seines Inhaltes zu erkennen, wodurch es etwa möglich sein kann, dass Skriptcode in einer Textdatei ausgeführt wird.
- 23.
Der Begriff „Webservice“ ist als XML-Dienst definiert, der über das HTTP-Protokoll aufgerufen wird. Als „Webdienst“ sollen dagegen allgemein alle HTTP-basierten Schnittstellen verstanden werden, über die Prozesse miteinander kommunizieren.
- 24.
Ist dies nicht möglich, ist die Abwehr etwas komplizierter. Christian Schneider beschreibt ein mögliches Vorgehen in seinem Blog: http://www.christian-schneider.net/GenericXxeDetection.html.
- 25.
Durch Forward Secrecy lässt sich der für die Verschlüsselung einer HTTPS-Kommunikation verwendete Sitzungsschlüssel nicht direkt aus dem privaten Schlüssel berechnen. Dadurch lässt sich eine aufgezeichnete Kommunikation selbst dann nicht mehr entschlüsseln, wenn jemand in Besitz des privaten Schlüssels gelangen sollte. Dadurch wird eine deutlich höhere Sicherheit gewährleistet. Andererseits lässt sich die HTTPS-Kommunikation bei aktiviertem Forward Secrecy dann natürlich auch nicht mehr von zwischengeschalteten IDS/IPS-Systemen analysieren.
- 26.
Alternativ lässt sich der private Schlüssel zum SSL-Zertifikat auf dem WAF-System hinterlegen, mit dem dieses HTTPS-Verbindungen entschlüsseln und analysieren kann. Dies setzt voraus, dass Forward Key Secrecy nicht aktiviert ist, was der Sicherheit abträglich und daher nicht zu empfehlen ist.
Author information
Authors and Affiliations
Corresponding author
Rights and permissions
Copyright information
© 2015 Springer Fachmedien Wiesbaden
About this chapter
Cite this chapter
Rohr, M. (2015). Technische Sicherheitsmaßnahmen. In: Sicherheit von Webanwendungen in der Praxis. Edition <kes>. Springer Vieweg, Wiesbaden. https://doi.org/10.1007/978-3-658-03851-9_3
Download citation
DOI: https://doi.org/10.1007/978-3-658-03851-9_3
Published:
Publisher Name: Springer Vieweg, Wiesbaden
Print ISBN: 978-3-658-03850-2
Online ISBN: 978-3-658-03851-9
eBook Packages: Computer Science and Engineering (German Language)