Sicherheit in SPAs
mit
Ausgangssituation
Sicherheitskonzept
Gängige Probleme
Ursache
Auswirkung
Test
Gegenmaßnahme
Philipp Burgmer
Software-Entwickler, Trainer
Fokus: Frontend, Web-Technologien
burgmer@w11k.de
w11k GmbH
Software Design, ...
HTTP
Frontend Backend
Statische
Dateien
Rohdaten
JSON
Web API (REST)
Business Layer
Datenbank
Framework
HTML + JS + CSS
Br...
Datenbanken (SQL | NoSQL) & Backend-Sprache
HTTP
JavaScript & HTML
Historisch betrachten
Vieles gewachsen
Nicht für heute ...
Öffentlicher und privater Bereich
Login -> Session
Benutzer-Rollen
Grundgedanke: Jeder sichert sich selbst ab
Client schüt...
Vorgelagert als extra Seite
Anwendung nur mit gültigem Login aufrufbar
Nicht eingeloggt: HTTP-Redirect auf Login
Eingelogg...
Berechtigungen über Rollen verwalten
Bereiche mit Rollen versehen
Im UI per Directive
An Route / State per resolve
BERECHT...
BERECHTIGUNGEN VERWALTEN
angular.module('app').constant('ResolveFunctions', {1
userRolesRequired: function (roles) {2
retu...
BERECHTIGUNGEN VERWALTEN
angular.module('app').service('UserService', function ($http, $q) {1
return {2
getUser: function ...
1. Injection
2. Broken Authentication and Session Management
3. Cross-Site Scripting
4. Insecure Direct Object References
...
The Open Web Application Security Project
Non-Profit Organisation
Finanziert über Mitgliedsbeiträge und Spenden
Existiert ...
Benutzereingaben nie trauen
Im Backend nie davon ausgehen, dass Request vom Client kommen
Verwendete Komponenten auf Secur...
Code-Minimierung / -Obfuscating
Verwendung von HTTPS
Berechtigungen im Client prüfen
Eingaben im Client validieren
UNZUREI...
CODE INJECTION
Java Code um SQL Abfrage zusammen zu bauen
URL-Aufruf des Angreifers
Ausgeführtes SQL
BEISPIEL: SQL
statement = "SELECT * ...
Daten aus Sprache A werden zu Code in Sprache B
Code wird dynamisch an einen Interpreter übergeben
Code enthält Benutzerei...
Manuell am Code
Verwendung von Interpretern ausfindig machen
Eingaben von Interpretern auf dynamische Teile untersuchen
Da...
Möglichst wenig Interpreter verwenden, besser APIs
Prepared-Statements
Stored-Procedures
Benutzereingaben nicht vertrauen
...
Sicherer Java Code um SQL Abfrage zusammen zu bauen
BEISPIEL: SQL
PreparedStatement pstmt = connection.prepareStatement("S...
BROKEN AUTHENTICATION AND SESSION
MANAGEMENT
Zugangsdaten oder Session können entwendet werden
Session kann geklaut werden
z.B. Session-ID in der URL, oft bei URL Rewr...
Passwörter stehen im Klartext in der Datenbank
Datenbank wird entwendet
Angreifer kann sich als jeder User einloggen
Sessi...
Login, Logout und Session Managemnt nicht selbst implementieren
Bewährte, gut getestete Biblotheken verwenden (OAuth?)
Ver...
Weniger Zustand im Server -> Bessere Skalierbarkeit
Gut: Session = Mapping Session ID -> User ID
Besser: keine Session im ...
Session-ID ist kein Random oder Hash
Session-ID enthält Zustand
User-ID
Login-Timestamp
XSRF-Token?
Base64 encoded
Session...
CROSS-SITE SCRIPTING
Ausprobieren ...
BEISPIEL
var source = $('#insecure-input');1
var text = source.val();2
var target = $('#insecure-output')...
Spezielle Art der HTML Injection
HTML-Injection wird ausgenutzt um anderen Benutzer Code unterzuschieben
Verschiedene Type...
Benutzereingaben immer escapen
Daten vom Server escapen
Sanitizer Biblothek verwenden
Kontext beachten in dem Wert verwend...
Angular escapt alle Data-Bindings automatisch
$sanitize Service um sicheres HTML-Subset ausgeben zu können
$sce Service um...
ANGULARJS BESPIEL
<input type="text" ng-model="text"/>1
<div ng-bind="text"></div>2
<div ng-bind-html="text"></div>3
32
CROSS-SITE REQUEST FORGERY
Aufruf von Business Logik ohne zusätzlichen Schutz
XSRF Attacke per XSS
BEISPIEL
http://example.com/app/transferFunds?amou...
Angreifer ruft URL mit den Rechten des Benutzers auf
Verschiedene Angriffsformen
Cross-Site-Scripting
Social-Engeneering /...
Login schickt Session-ID als Cookie mit httpOnly und secure
Login antwortet mit zusätzliches Token im Header ( X-XSRF-Toke...
HTTP-Interceptor Konzept
Interceptor für X-XSRF-Token
Speichert Token Arbeitsspeicher
Sendet Token bei jedem Request zur g...
Philipp Burgmer
burgmer@w11k.de
www.w11k.de
www.thecodecampus.de
Nächste SlideShare
Wird geladen in …5
×

Sicherheit in Single-Page-Web-Anwendungen

478 Aufrufe

Veröffentlicht am

Slides zu meinem Talk beim Entwicklertag 2015 in Karlsruhe.

# Zusammenfassung

Sicherheit von Web-Anwendungen ist ein heißes Thema. Obwohl seit Jahren aktuell, werden die Meldungen über erneute Lücken gefühlt eher schlimmer als besser. Der Trend zu Single-Page-Anwendungen bringt für uns Entwickler eine ganze Reihe neuer Herausforderungen in punkto Sicherheit mit sich, da immer mehr Funktionalität in den Browser verlagert wird und dadurch mehr Code in nicht vertrauenswürdiger Umgebung läuft.

In diesem Talk wir anhand von AngularJS gezeigt auf was man bei SPAs achten muss. Anhand von Code-Beispielen wird natürlich auch gezeigt wie man sich z.B. vor Cross-Site-Scripting, Cross-Site-Request-Forgery und Code-Injection schützt und welche Gefahren sonst noch so lauern.


# Kurz-Bio

Philipp Burgmer studierte an der Hochschule Karlsruhe Informatik und arbeitet als Entwickler, Berater und [Trainer](http://thecodecampus.de) für die [w11k GmbH](http://w11k.de). Er ist Experte für Webtechnologien und beschäftigt sich mit der Gestaltung und Optimierung von Benutzeroberflächen. Privat interessiert er sich für Klettern und DJing.

Veröffentlicht in: Software
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

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

Keine Downloads
Aufrufe
Aufrufe insgesamt
478
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
10
Aktionen
Geteilt
0
Downloads
5
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Sicherheit in Single-Page-Web-Anwendungen

  1. 1. Sicherheit in SPAs mit
  2. 2. Ausgangssituation Sicherheitskonzept Gängige Probleme Ursache Auswirkung Test Gegenmaßnahme
  3. 3. Philipp Burgmer Software-Entwickler, Trainer Fokus: Frontend, Web-Technologien burgmer@w11k.de w11k GmbH Software Design, Entwicklung & Wartung Consulting, Schulungen & Projekt Kickoff Web Anwendungen mit AngularJS Native Rich Clients mit Eclipse RCP ÜBER MICH 3
  4. 4. HTTP Frontend Backend Statische Dateien Rohdaten JSON Web API (REST) Business Layer Datenbank Framework HTML + JS + CSS Browser Rich Client im Browser Server liefert statische Dateien für den Client Server bietet API für Daten (REST, WebSocket) (JSON, XML) Backend weis nichts über verwendete Technologien im Client Client weis nichts über verwendete Technologien im Backend Stateful Client, Stateless Backend ARCHITEKTUR VON SPAs 4
  5. 5. Datenbanken (SQL | NoSQL) & Backend-Sprache HTTP JavaScript & HTML Historisch betrachten Vieles gewachsen Nicht für heute Verwendung gedacht TECHNOLOGIES 5
  6. 6. Öffentlicher und privater Bereich Login -> Session Benutzer-Rollen Grundgedanke: Jeder sichert sich selbst ab Client schütz UI Server schütz Datenzugriffe Jeder schützt seine verwendeten Technologien Alle schützen die Übertragung SICHERHEITSKONZEPT NAIV 6
  7. 7. Vorgelagert als extra Seite Anwendung nur mit gültigem Login aufrufbar Nicht eingeloggt: HTTP-Redirect auf Login Eingeloggt: HTTP-Redirect auf Anwendung Weniger Angriffsfläche: Nicht jeder sieht die Anwendung Schnelles Laden der ersten Seite Login als Route in Anwendung Einfacheres Handling Kein Zusätzlicher Request für Benutzer-Daten notwendig LOGIN 7
  8. 8. Berechtigungen über Rollen verwalten Bereiche mit Rollen versehen Im UI per Directive An Route / State per resolve BERECHTIGUNGEN VERWALTEN <li match-route="/admin.*" user-role-required="'ADMIN'">1 <a href="#!/admin/overview">Admin</a>2 </li>3 module.config(function($stateProvider, ResolveFunctions) {1 $stateProvider.state('admin', {2 url: '/admin', templateUrl: 'route/admin/admin.html', controller: 'AdminCtrl',3 resolve: { authorized: ResolveFunctions.userRolesRequired('ADMIN') }4 });5 });6 8
  9. 9. BERECHTIGUNGEN VERWALTEN angular.module('app').constant('ResolveFunctions', {1 userRolesRequired: function (roles) {2 return /* @ngInject */ function (UserService) {3 return UserService.hasRoles(roles);4 };5 }6 });7 9
  10. 10. BERECHTIGUNGEN VERWALTEN angular.module('app').service('UserService', function ($http, $q) {1 return {2 getUser: function () {3 // load user information from server and return promise4 },5 hasRoles: function (roles) {6 // get user then check if user has roles7 // return promise8 }9 };10 })11 10
  11. 11. 1. Injection 2. Broken Authentication and Session Management 3. Cross-Site Scripting 4. Insecure Direct Object References 5. Security Misconfiguration 6. Sensitive Data Exposure 7. Missing Function Level Access Control 8. Cross-Site Request Forgery 9. Using Components with Known Vulnerabilities 10. Unvalidated Redirects and Forwards Quelle: OWASP Top10 2013 TOP 10 SICHERHEITSPROBLEME 11
  12. 12. The Open Web Application Security Project Non-Profit Organisation Finanziert über Mitgliedsbeiträge und Spenden Existiert seit 2001 Stellt Informationen zu Sicherheitsthemen bereit detaillierte Beschreibungen und Erklärungen gängige Lösungsansätze OWASP 12
  13. 13. Benutzereingaben nie trauen Im Backend nie davon ausgehen, dass Request vom Client kommen Verwendete Komponenten auf Security-Updates prüfen Security testen punkspider.org: Suchmaschine für Sicherheitslücken BeEF - The Browser Exploitation Framework: Tool für Penetrationstests OWASP - Vulnerability Scanning Tools GENERELLE GEGENMASSNAHMEN 13
  14. 14. Code-Minimierung / -Obfuscating Verwendung von HTTPS Berechtigungen im Client prüfen Eingaben im Client validieren UNZUREICHENDE GEGENMASSNAHMEN 14
  15. 15. CODE INJECTION
  16. 16. Java Code um SQL Abfrage zusammen zu bauen URL-Aufruf des Angreifers Ausgeführtes SQL BEISPIEL: SQL statement = "SELECT * FROM users WHERE id = " + request.getParameter("id") + ";"1 http://example.com/user?id=42;UPDATE+USER+SET+TYPE="admin"+WHERE+ID=23;--1 SELECT * FROM users WHERE id = 42; UPDATE USER SET TYPE="admin" WHERE ID=23;--;1 16
  17. 17. Daten aus Sprache A werden zu Code in Sprache B Code wird dynamisch an einen Interpreter übergeben Code enthält Benutzereingaben (Formular-Daten, URL-Parameter, ...) Benutzereingaben werden nicht oder unzureichend überprüft An vielen Stellen möglich SQL HTML (z.B. bei Cross-Site-Scripting) Script-Sprachen mit eval-Funktion (JS, PHP) Dynamisches Laden von Code aus Dateien Shell / Command Execution CODE INJECTION 17
  18. 18. Manuell am Code Verwendung von Interpretern ausfindig machen Eingaben von Interpretern auf dynamische Teile untersuchen Datenfluss zurückverfolgen (Wo kommen dynamische Teile her?) Automatisiert Code Analyse Tools um Interpreter zu finden Peneration-Test-Tools finden häufig gemachte Fehler SCHWACHSTELLEN FINDEN 18
  19. 19. Möglichst wenig Interpreter verwenden, besser APIs Prepared-Statements Stored-Procedures Benutzereingaben nicht vertrauen Kontextuelles Escapen (HTML, JS, SQL) White-Listing GEGENMASSNAHMEN 19
  20. 20. Sicherer Java Code um SQL Abfrage zusammen zu bauen BEISPIEL: SQL PreparedStatement pstmt = connection.prepareStatement("SELECT * FROM users WHERE id = ?");1 pstmt.setInt(1, request.getParameter("id"));2 ResultSet rset = pstmt.executeQuery();3 20
  21. 21. BROKEN AUTHENTICATION AND SESSION MANAGEMENT
  22. 22. Zugangsdaten oder Session können entwendet werden Session kann geklaut werden z.B. Session-ID in der URL, oft bei URL Rewriting Kein Session-Timeout (öffentlicher PC) Vorhersagbare Session IDs Übertragung per unverschlüsselter Kommunikation Cross-Site-Scripting um Cookie zu entwenden SESSION MANAGEMENT 22
  23. 23. Passwörter stehen im Klartext in der Datenbank Datenbank wird entwendet Angreifer kann sich als jeder User einloggen Session-ID steht in URL BEISPIELE http://example.com/shoppingcart?sessionid=2685445411 23
  24. 24. Login, Logout und Session Managemnt nicht selbst implementieren Bewährte, gut getestete Biblotheken verwenden (OAuth?) Verschlüsselte Kommunikation Keine Passwörte speichern, Hash mit Salt Cross-Site-Scripting verhindern GEGENMASSNAHMEN 24
  25. 25. Weniger Zustand im Server -> Bessere Skalierbarkeit Gut: Session = Mapping Session ID -> User ID Besser: keine Session im Backend, Session ID enthält allen Zustand Im Backend benötigter Zustand wird bei jedem Request übertragen HERAUSFORDERUNG STATELESS BACKEND 25
  26. 26. Session-ID ist kein Random oder Hash Session-ID enthält Zustand User-ID Login-Timestamp XSRF-Token? Base64 encoded Session-ID wird gegen Manipulation und Nachahmung geschützt Verschlüsselung Signierung Message Authentication Code (z.B. HMAC) Nur auf dem Server bekannt STATEFUL SESSION-ID 26
  27. 27. CROSS-SITE SCRIPTING
  28. 28. Ausprobieren ... BEISPIEL var source = $('#insecure-input');1 var text = source.val();2 var target = $('#insecure-output');3 target.append(text);4 28
  29. 29. Spezielle Art der HTML Injection HTML-Injection wird ausgenutzt um anderen Benutzer Code unterzuschieben Verschiedene Type: Persistent / Non-Persistent, DOM-Based Benutzereingabe wird in HTML ausgegeben Ermöglicht Ausführen von Code Code-Ausführung übermittelt Daten an Angreifen (z.B. Cookies) Code ruft URL auf um Aktion mit Rechten des Benutzers auszuführen CROSS-SITE-SCRIPTING 29
  30. 30. Benutzereingaben immer escapen Daten vom Server escapen Sanitizer Biblothek verwenden Kontext beachten in dem Wert verwendet wird GEGENMASSNAHMEN 30
  31. 31. Angular escapt alle Data-Bindings automatisch $sanitize Service um sicheres HTML-Subset ausgeben zu können $sce Service um beliebiges HTML aus vertrauenswürdiger Quelle ausgeben zu können Detaillierte Erklärung ANGULARJS 31
  32. 32. ANGULARJS BESPIEL <input type="text" ng-model="text"/>1 <div ng-bind="text"></div>2 <div ng-bind-html="text"></div>3 32
  33. 33. CROSS-SITE REQUEST FORGERY
  34. 34. Aufruf von Business Logik ohne zusätzlichen Schutz XSRF Attacke per XSS BEISPIEL http://example.com/app/transferFunds?amount=1500&destinationAccount=46732432431 <img src="http://example.com/app/transferFunds?amount=1500&destinationAccount=attackersAcct#" width="0" height="0" /> 1 34
  35. 35. Angreifer ruft URL mit den Rechten des Benutzers auf Verschiedene Angriffsformen Cross-Site-Scripting Social-Engeneering / Unterschieben einer URL Cookies sind nicht sicher! Auch nicht mit httpOnly und secure Cookies können abgegriffen werden bzw. werden automatisch gesendet CROSS-SITE REQUEST FORGERY 35
  36. 36. Login schickt Session-ID als Cookie mit httpOnly und secure Login antwortet mit zusätzliches Token im Header ( X-XSRF-Token ) Token kann nur vom eigenen JS Code aus abgegriffen werden, der den Request gestartet hat Token muss danach vom eigenen Code explizit als Header mitgesendet werden Server vergleicht mitgesendetes Token mit erwartetem GEGENMASSNAHMEN 36
  37. 37. HTTP-Interceptor Konzept Interceptor für X-XSRF-Token Speichert Token Arbeitsspeicher Sendet Token bei jedem Request zur gleichen Domain mit Problem: Öffne Link in neuem Tab Server vergibt neues Token wenn gleiche IP ANGULARJS 37
  38. 38. Philipp Burgmer burgmer@w11k.de www.w11k.de www.thecodecampus.de

×