Embed Size (px)
Citation preview
Philipp BurgmertheCodeCampus / w11k GmbH
Sicherheit in SPAsmit
AusgangssituationSicherheitskonzeptGängige Probleme
UrsacheAuswirkungTestGegenmaßnahme
Philipp BurgmerSoftware-Entwickler, TrainerFokus: Frontend, [email protected]
w11k GmbHSoftware Design, Entwicklung & WartungConsulting, Schulungen & Projekt KickoffWeb-Apps, Mobil-Apps, Rich ClientsAngularJS, TypeScript, Eclipse RCP
ÜBER MICH
3
HTTPFrontend Backend
Statische Dateien
RohdatenJSON
Web API (REST)Business Layer
DatenbankFramework
HTML + JS + CSSBrowser
Rich Client im BrowserServer liefert statische Dateien für den ClientServer bietet API für Daten (REST, WebSocket) (JSON, XML)Backend weis nichts über verwendete Technologien im ClientClient weis nichts über verwendete Technologien im BackendStateful Client, Stateless Backend
ARCHITEKTUR VON SPAs
4
Datenbanken (SQL | NoSQL) & Backend-SpracheHTTPJavaScript & HTML
Historisch betrachtenVieles gewachsenNicht für heute Verwendung gedacht
TECHNOLOGIES
5
Öffentlicher und privater BereichLogin -> SessionBenutzer-RollenGrundgedanke: Jeder sichert sich selbst ab
Client schütz UIServer schütz DatenzugriffeJeder schützt seine verwendeten TechnologienAlle schützen die Übertragung
SICHERHEITSKONZEPTNAIV
6
Login vor Aufruf der AnwendungLogin innerhalb der Anwendung
Berechtigungen innerhalb der Anwendung
LOGIN
7
Server stellt sicherAnwendung nur mit gültigem Login aufrufbarOhne gültigen Login: HTTP-Redirect auf Login-SeiteNach erfolgreichem Login: HTTP-Redirect auf Anwendung
In AnwendungHTTP 401: Navigation zu Login-Seite
Weniger Angriffsfläche: Nicht jeder sieht die AnwendungSchnelles Laden der ersten SeiteImmer ganze Anwendung geschützt
LOGINVOR DER ANWENDUNG
8
Rein Client-seitiges Handling (für UI)Login-Formular als Route / State in AnwendungAjax-Request für LoginPrüfung auf gültigen Login
State-Change + Event-Handler $stateChangeErrorAPI-Requests + HTTP Interceptor
Weniger Request notwendigÖffentliche und geschützte Bereiche möglich
LOGININ DER ANWENDUNG
9
Berechtigungen über Rollen verwaltenBereiche mit Rollen versehenIm UI per Direktive
BERECHTIGUNGEN VERWALTENIN ANGULARJS
<ul class="menu">1
<li user-role-required="'ADMIN'">2
<a href="#!/admin">Admin</a>3
</li>4
</ul>5
10
An Route / State per resolve
BERECHTIGUNGEN VERWALTENIN ANGULARJS
angular.module('app').config(function() {1
$stateProvider.state('admin', {2
url: '/admin',3
templateUrl: 'route/admin/admin.html',4
resolve: {5
authorized: /* @ngInject */ function (UserService) {6
return UserService.hasRoles('ADMIN');7
}8
}});});9
11
1. Injection2. Broken Authentication and Session Management3. Cross-Site Scripting4. Insecure Direct Object References5. Security Misconfiguration6. Sensitive Data Exposure7. Missing Function Level Access Control8. Cross-Site Request Forgery9. Using Components with Known Vulnerabilities
10. Unvalidated Redirects and Forwards
Quelle: OWASP Top10 2013
TOP 10 SICHERHEITSPROBLEME
12
The Open Web Application Security ProjectNon-Profit OrganisationFinanziert über Mitgliedsbeiträge und SpendenExistiert seit 2001Stellt Informationen zu Sicherheitsthemen bereit
detaillierte Beschreibungen und Erklärungengängige Lösungsansätze
OWASP
13
Benutzereingaben nie trauenIm Backend nie davon ausgehen, dass Request vom Client kommenVerwendete Komponenten auf Security-Updates prüfenSecurity testen
punkspider.org: Suchmaschine für SicherheitslückenBeEF - The Browser Exploitation Framework: Tool für PenetrationstestsOWASP - Vulnerability Scanning Tools
GENERELLE GEGENMASSNAHMEN
14
Code-Minimierung / -ObfuscatingVerwendung von HTTPSBerechtigungen im Client prüfenEingaben im Client validieren
UNZUREICHENDE GEGENMASSNAHMEN
15
CODE INJECTION
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
17
Daten aus Sprache A werden zu Code in Sprache BCode wird dynamisch an einen Interpreter übergebenCode enthält Benutzereingaben (Formular-Daten, URL-Parameter, ...)Benutzereingaben werden nicht oder unzureichend überprüftAn vielen Stellen möglich
SQLHTML (z.B. bei Cross-Site-Scripting)Script-Sprachen mit eval-Funktion (JS, PHP)Dynamisches Laden von Code aus DateienShell / Command Execution
CODE INJECTION
18
Manuell am CodeVerwendung von Interpretern ausfindig machenEingaben von Interpretern auf dynamische Teile untersuchenDatenfluss zurückverfolgen (Wo kommen dynamische Teile her?)
AutomatisiertCode Analyse Tools um Interpreter zu findenPeneration-Test-Tools finden häufig gemachte Fehler
SCHWACHSTELLEN FINDEN
19
Möglichst wenig Interpreter verwenden, besser APIsPrepared-StatementsStored-Procedures
Benutzereingaben nicht vertrauenKontextuelles Escapen (HTML, JS, SQL)White-Listing
GEGENMASSNAHMEN
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
21
BROKEN AUTHENTICATION AND SESSIONMANAGEMENT
Zugangsdaten oder Session können entwendet werden
Session kann geklaut werdenz.B. Session-ID in der URL, oft bei URL RewritingKein Session-Timeout (öffentlicher PC)Vorhersagbare Session IDsÜbertragung per unverschlüsselter KommunikationCross-Site-Scripting um Cookie zu entwenden
SESSION MANAGEMENT
23
Passwörter stehen im Klartext in der DatenbankDatenbank wird entwendetAngreifer kann sich als jeder User einloggen
Session-ID steht in URL
BEISPIELE
http://example.com/shoppingcart?sessionid=2685445411
24
Login, Logout und Session Managemnt nicht selbst implementierenBewährte, gut getestete Biblotheken verwenden (OAuth?)Verschlüsselte KommunikationKeine Passwörte speichern, Hash mit SaltCross-Site-Scripting verhindern
GEGENMASSNAHMEN
25
Weniger Zustand im Server -> Bessere SkalierbarkeitGut: Session = Mapping Session ID -> User IDBesser: keine Session im Backend, Session ID enthält allen ZustandIm Backend benötigter Zustand wird bei jedem Request übertragen
HERAUSFORDERUNG
STATELESS BACKEND
26
Session-ID ist kein Random oder HashSession-ID enthält Zustand
User-IDLogin-TimestampXSRF-Token?Base64 encoded
Session-ID wird gegen Manipulation und Nachahmung geschütztVerschlüsselungSignierungMessage Authentication Code (z.B. HMAC)Nur auf dem Server bekannt
STATEFUL SESSION-ID
27
XSSCROSS-SITE-SCRIPTING
Ausprobieren ...
BEISPIELvar source = $('#insecure-input');1
var text = source.val();2
var target = $('#insecure-output');3
target.append(text);4
29
Spezielle Art der HTML InjectionHTML-Injection wird ausgenutzt um anderen Benutzer Code unterzuschiebenBenutzereingabe wird ohne Prüfung in HTML ausgegebenErmöglicht Ausführen von Code
AngriffeDaten auslesen und an Angreifen übermitteln (z.B. Session-Cookie)Code ruft URL auf um Aktion mit Rechten des Benutzers auszuführen (ähnlich wie XSRF)
CROSS-SITE-SCRIPTING
30
Benutzereingaben immer escapenDaten vom Server escapenSanitizer Biblothek verwendenKontext beachten in dem Wert verwendet wird
GEGENMASSNAHMEN
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önnenAusführliches Beispiel
ANGULARJS
32
ANGULARJSBESPIEL
<input type="text" ng-model="text"/>1
<div ng-bind="text"></div>2
<div ng-bind-html="text"></div>3
33
ng-bind und {{}} escaped alle HTML Sonderzeichenng-bind-html lässt ein sicheres Subset durch
ngSanitize : zusätzliches Modul mit erweitertem Sanitizer für sicheres SubsetMuss eigebunden werden für ng-bind-html , ansonsten Fehler auf Konsole
ANGULARJSNG-BIND-HTML
34
$sce Service stellt Methoden zum wrappen bereitJS, URL, HTML
$sce.trustAsHtml wrapt Text in ObjektObjekt markiert Text als sicheren Codeng-bind-html übernimmt ursprünglichen Text als Code in DOM
ANGULARJSSTRICT CONTEXTUAL ESCAPING
35
XSRFCROSS-SITE-REQUEST-FORGERY
Ausgangsituation: Benutzer in App eingeloggt (hat gültiges Session-Cookie)
Aufruf von Business Logik ohne zusätzlichen Schutz
XSRF Attacke per Social Engeneering
XSRF Attacke per XSS
BEISPIEL
http://example.com/app/transferFunds?amount=1500&destinationAccount=46732432431
<a href="http://bit.ly/xyz">Link zu einer "vertrauenswürdigen" Seite</a>1
<img src="http://example.com/app/transferFunds?amount=1500&destination=attacker" />1
37
Angreifer bringt Benutzer dazu URL aufzurufenRequest wird mit Rechten des Benutzers ausgeführtVerschiedene Angriffsformen
Cross-Site-ScriptingSocial-Engeneering / Unterschieben einer URL
Cookies allein sind nicht sicherFür Session-Cookie immer httpOnly und secure verwendenCookie kann nicht abgegriffen werden (per JS)Cookie wird aber immer gesendet (XSRF immer noch möglich)
Zusätzlicher Schutz notwendig
XSRF
38
ServerSchickt bei Login Session-ID als Cookie mit httpOnly und secureSchickt bei Login zusätzliches Token als Cookie XSRF-Token ohne httpOnly
ClientToken wird zwischengespeichert (JS Variable) und Cookie gelöschtToken wird bei jedem Request als Header mitgesendet
Server validiert bei jedem Request mitgesendetes Token
GEGENMASSNAHMEN
39
HTTP-Interceptor KonzeptInterceptor schon mit dabei
Ließt Cookie XSRF-TOKENSendet Header X-XSRF-TOKENNamen konfigurierbar
Problem: Öffne Link in neuem TabLösung: Server sendet Token noch mal bei GET api/login
ANGULARJS
40
