Philipp BurgmertheCodeCampus / w11k GmbH

Sicherheit in SPAsmit

AusgangssituationSicherheitskonzeptGängige Probleme

UrsacheAuswirkungTestGegenmaßnahme

Philipp BurgmerSoftware-Entwickler, TrainerFokus: Frontend, Web-Technologienburgmer@w11k.de

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

Philipp Burgmerburgmer@w11k.de

www.w11k.dewww.thecodecampus.de