1. Web-Technology
Lecture 11

2. Household issues Midterm Assignment 3 Course evaluation on Caracal
Has been graded
If you have a question about your grade / want to review your answer
to me
Assignment 3
Deadline has been slightly extended
Last time
Course evaluation on Caracal
Between and

3. Exam When: 13-4-2018 at 8.30-10.30; EDUC-BETA Where: EDUC-BETA Retake:
EDUC-ALFA
The exam is closed-book
Closed-slides
Closed-notes
Closed-laptop
Closed-phone
Closed-neighbour
You can use scratch paper, of course
Paper and pens/pencils will not be provided
Grading
30% of the course grade

4. More deadlines 15/04/2017: Assignment 3 submission
23/04/2017: Assignment 3 grades are posted
23/04/2017: Final Exam grades are ed to you
25/04/2017: Deadline for grades to be disputed
27/04/2017: Course grades are entered into Osiris

5. Materials for exam preparation
Lecture Slides
Reading page

6. Topics: a look back (..and a bit forward)
Lecture 7
Web app architecture;
Intro to Node.js
Lecture 8
Stateful Web
Cookies
Lecture 9
Express.js,
Web Databases
Lecture 10
AJAX
Lecture 11
Security
Lecture 12
Adaptive Web
Lecture 13
Semantic Web
Lecture 14
Social Web
Lecture 15
Security - II

7. WebApp Security

8. OWASP Top Ten 2017 1: Injection
2004
2007
2013
2017
OWASP Top Ten 2017
1: Injection
2: Broken Authentication and Session Management
3: Sensitive Data Exposure
4: XML External Entities (XXE)
5: Broken Access Control
6: Security Misconfiguration
7: Cross-Site Scripting (XSS)
8: Insecure deserialization
9: Using Components with Known Vulnerabilities
10: Insufficient logging and monitoring

9. A3-2017: Sensitive Data Exposure

10. A3-2017: General info Sensitive data must be protected
financial info
health info
Identity info
Passwords
If your app collects such data it must be protected,
you are liable (General Data Protection Regulation – GDPR)
Data can be exposed when
Stored
Transferred
Exposed means
It exists in plain text or
It is encrypted using old/weak technology

11. A3-2017: Examples of attack
Initial target - user
Initial target - app

12. A3-2017: Protection

13. A4-2017: XML External Entities (XXE)

14. A4-2017: XML External Entities (XXE)
XML standard allows the use of DTDs (Document Type Definitions)
DTDs are meant to define expected structure of XML documents
One interesting feature of DTDs is the ability to define Entities as shortcuts for strings
<!ENTITY YN ‘”YES”’ >
<!ENTITY WhatHasSaid “He said &YN; “ >
Would resolve to He said “Yes”
<!ENTITY f “foo” >
<!ENTITY foobar “&f;bar” >
<element>&foobar;</element>
Would put foobar in the element “element”

15. A4-2017: Classic XXE
Other flavors:
Port scanning
Directory listing …

16. A4-2017: Denial of service XXE
Works based on the expansion property of XML entities
For example, this simple 1 Kb file expand into 3Gb of memory on the server:

17. A4-2017: How to protect
When possible, use less complex data formats such as JSON
Patch or upgrade all XML processors and libraries in use by the application or on the underlying operating system
Disable XML external entity and DTD processing in all XML parsers in the application
Implement positive ("whitelisting") server-side input validation, filtering, or sanitization to prevent hostile data within XML documents, headers, or nodes

18. A6-2017: Security misconfiguration
Missing appropriate security hardening across any part of the application stack:
unnecessary features enabled (e.g. unnecessary ports, services, pages, accounts, or privileges),
using default credentials,
leaving files unprotected on public servers,
error handling reveals stack traces,
software is unpatched…
The infamous Mirai botnet of 2016 relied on unchanged default credentials (such as a login of “admin” and a password of “1234”) of about 60 specific IoT devices. When exploited, it eventually infected nearly 400,000 units of just those 60 unprotected devices.

19. A8-2017: Insecure deserialization
Serialization - transformed of an object into a binary form
often done before storying/caching/exchanging objects
Deserialization - reassembling a series of bits back into an object
The source and content of object needs to be verified before deserialization
Otherwise, attackers can modified serialized data and build illegitimate objects that execute commands within an infected application
Prevention:
integrity checks such as digital signatures on serialized objects
strict type constraints during deserialization before object creation
running code that reserializes in low privilege environments
Monitoring deserialization exceptions
Monitoring incoming and outgoing network connectivity from sources of serialized data

20. A9-2017: Components with Vulnerabilities
When vulnerabilities become known, vendors generally fix them with a patch or update
OSs, web servers, DBMSs, applications, frameworks, APIs, runtime environments, and libraries
If a vulnerability exists, assume, everyone knows about it and knows how to exploit it
Scan subscribe, update and patch
IoT is especially problematic in this regard (patching might be irregular for some devices)
The former CEO of Equifax, while testifying to Congress regarding their infamous 2017 breach, blamed it on someone in IT, stating “The human error was that the individual who’s responsible for communicating in the organization to apply the patch, did not.”

21. A10-2017: Insufficient logging and monitoring
If you’re not looking for attackers or suspicious activities, you’re not going to find them
Software and systems have monitoring abilities to analyze
(failed) logins
(peaks in) traffic
(incomplete or high-value) transactions
Attackers rely on the lack of monitoring to exploit vulnerabilities before they’re detected
Logging isn’t just important for identifying attacks in progress; it can assist with the forensic analysis after an attack has succeeded
Make sure:
Important and irregular events are logged
Logs are in an effective format and are kept long enough
High-value transactions have an audit trail with integrity controls to prevent tampering or deletion
Effective monitoring and alerting is established