Web-Technology Lecture 11
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 E-mail to me Assignment 3 Deadline has been slightly extended Last time Course evaluation on Caracal https://caracal.uu.nl Between 3-4-2018 and 29-4-2018
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
More deadlines 15/04/2017: Assignment 3 submission 23/04/2017: Assignment 3 grades are posted 23/04/2017: Final Exam grades are e-mailed to you 25/04/2017: Deadline for grades to be disputed 27/04/2017: Course grades are entered into Osiris
Materials for exam preparation Lecture Slides Reading page
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
WebApp Security
OWASP Top Ten 2017 1: Injection 2004 2007 2013 2017 OWASP Top Ten 2017 https://www.owasp.org/index.php/Top_10-2017_Top_10 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
A3-2017: Sensitive Data Exposure
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
A3-2017: Examples of attack Initial target - user Initial target - app
A3-2017: Protection
A4-2017: XML External Entities (XXE)
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”
A4-2017: Classic XXE Other flavors: Port scanning Directory listing …
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:
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
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.
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
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.”
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