COMP9321 Web Application Engineering

COMP9321 Web Application Engineering Semester 2, 2016 Dr. Amin Beheshti Service Oriented Computing Group, CSE, UNSW Australia Week 9 http://webapps.cse.unsw.edu.au/webcms2/course/index.php?cid=2445 1

Assignment 2 The due date for this assignment 2 is (end of Mid Semester Break): Sunday, 2 October 2016, 23:59:59. Demo will be held during the lab times in week 10. UNSW, CSE, Calendar: https://student.unsw.edu.au/calendar 2

Assignment 3 Released 3

Introduction to Web Application Security Acknowledgements This presentation contains material prepared by Halvard Skogsrud, Senior Software Engineer, Thoughtworks, Inc. Sydney, Australia and from the Open Web Application Security Project (OWASP) http://www.owasp.org 4

Introduction to Web Application Security Warning The objective of this presentation is to show you common security loopholes appearing in Web applications. However, it is not meant to encourage you to attack web applications. Such actions are both a breach of the law in most countries, and of the CSE policy. Hence, by attempting any of the techniques presented in this lecture, you may be prosecuted by law enforcement and face expulsion from the university. 5

Securing your Web Application 6

Securing your Web Application: Threats! 7

Securing your Web Application: Threats! 8

Securing your Web Application: Threats! 9

Securing your Web Application: Threats! 10

Securing your Web Application: Requirements! 11

SQL Injection 12

SQL injection: SQL Injection is a code injection technique. used to attack data-driven applications How: a malicious SQL statements are inserted into an entry field for execution. 13

SQL injection: SQL Injection is a code injection technique. used to attack data-driven applications How: a malicious SQL statements are inserted into an entry field for execution. 14

SQL Injection: What is wrong? 15

SQL Injection: What is wrong? 16

SQL Injection: What is wrong? Google(comment in sql) 17

SQL Injection: What is wrong? 18

SQL Injection: Summary! 19

SQL Injection: Prevention!! To keep malicious inputs contained, any inputs written to the database need to be encoded. SQL encoding: ' OR 1=1 --' is encoded to \ \'\ OR\ 1\=1\ \-\-' https://en.wikipedia.org/wiki/secure_input_and_output_handling 20

SQL Injection: Prevention!! 21

Cross Site Scripting (XSS) 22

Cross Site Scripting (XSS) Cross-site scripting (XSS): is a type of computer security vulnerability typically found in web applications. XSS enables attackers to inject client-side script into web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same-origin policy. Same-origin policy is an important concept in the web application security model. Under the policy, a web browser permits scripts contained in a first web page to access data in a second web page, but only if both web pages have the same origin. 24

Cross Site Scripting (XSS): What is wrong? 26

Cross Site Scripting (XSS): What is wrong? Suppose the victim is given this URL by the attacker (www.badguy.com): 27

Cross Site Scripting (XSS): What is wrong? Suppose the victim is given this URL by the attacker (www.badguy.com): The web page would then be injected with the following script: 28

Cross Site Scripting (XSS): Summary! 29

Cross Site Scripting (XSS): Prevention!! 30

Cross Site Scripting (XSS): Prevention!! 31

Cross Site Request Forgery (CSRF) 32

Cross Site Request Forgery (CSRF) Cross-site request forgery also known as a one-click attack or session riding abbreviated as CSRF or XSRF is a type of malicious exploit of a website whereby unauthorized commands are transmitted from a user that the website trusts Exploit: is a piece of software, a chunk of data, or a sequence of commands that takes advantage of a bug or vulnerability in order to cause unintended or unanticipated behavior to occur on computer software 34

Cross Site Request Forgery (CSRF) 36

Cross Site Request Forgery (CSRF) 37

Cross Site Request Forgery (CSRF): Prevention!! A CAPTCHA is a type of challengeresponse test used in computing to determine whether or not the user is human. 38

Unvalidated Input 39

Unvalidated Input 40

Unvalidated Input 41

Unvalidated Input: Summary 42

Unvalidated Input: Prevention! 43

Broken Authentication 44

Broken Authentication Google(SHA-1) 45

Fixing Authentication: How To?! Google(MITM) 46

Fixing Authentication: Salting Passwords! In cryptography, a salt is a random data that is used as an additional input to a one-way function that hashes a password or passphrase. The primary function of salts is to defend against dictionary attacks versus a list of password hashes and against pre-computed rainbow table attacks. e.g. the salt and the password can be concatenated and processed with a cryptographic hash function, and the resulting output (but not the original password) can be stored with the salt in a database. 47

Fixing Authentication: Salting Passwords! Why add Salt? If each password is simply hashed, identical passwords will have the same hash: There are two drawbacks: 1. Due to the birthday paradox, the attacker can find a password very quickly especially if the number of passwords in the database is large. In probability theory, the birthday problem or birthday paradox concerns the probability that, in a set of n randomly chosen people, some pair of them will have the same birthday. See: http://en.wikipedia.org/wiki/birthday_paradox 48

Fixing Authentication: Salting Passwords! Why add Salt? If each password is simply hashed, identical passwords will have the same hash. There are two drawbacks: 1. Due to the birthday paradox, the attacker can find a password very quickly especially if the number of passwords in the database is large. 2. An attacker can use a list of precomputed hashes to break passwords in seconds. A rainbow table is a precomputed table for reversing cryptographic hash functions, usually for cracking password hashes. See: http://en.wikipedia.org/wiki/rainbow_table 49

Fixing Authentication: Salting Passwords! In order to solve these problems, a salt can be concatenated to the password before the digest operation. A salt is a random number of a fixed length. This salt must be different for each stored entry. It must be stored as clear text next to the hashed password. In this configuration, an attacker must handle a brute force attack on each individual password. The database is now birthday attack/rainbow crack resistant. consists of systematically checking all possible keys or passwords until the correct one is found. In the worst case, this would involve traversing the entire search space. 50

Fixing Authentication: Salting Passwords! 51

Fixing Authentication: Salting Passwords! 52

Fixing Authentication: Salting Passwords! 53

Session Management 54

Session Management: Problem or Solution?! 55

Session Management: Problem or Solution?! 56

Session Management: Problem or Solution?! Set-Cookie: <name>=<value>[; <Max-Age>=<age>] [; expires=<date>][; domain=<domain_name>] [; path=<some_path>][; secure][; HttpOnly] 57

Transport Layer Security 58

Transport Layer Security (e.g. HTTPS) 59

Transport Layer Security (e.g. HTTPS) Google(Secure Sockets Layer, SSL) Google(Certification Authority, CA) 60

HTTPS: Basics 61

HTTPS: Public-Key Cryptography 62

HTTPS: Shared-Key Cryptography 63

HTTPS: Hashing 64

HTTPS: Certificates 65

HTTPS: Signatures 66

HTTPS: How to? Limitations?! How to? Follow the steps at: https://tomcat.apache.org/tomcat-6.0-doc/ssl-howto.html 67

Application Layer Security 68

References http://www.owasp.org https://tomcat.apache.org/tomcat-6.0-doc/ssl-howto.html 69