COMP9321 Web Application Engineering

Size: px

Start display at page:

Download "COMP9321 Web Application Engineering"

Sibyl Lyons
5 years ago
Views:

1 COMP9321 Web Application Engineering Web Application Security Dr. Basem Suleiman Service Oriented Computing Group, CSE, UNSW Australia Semester 1, 2016, Week 8 1

2 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) 2

3 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. 3

4 Securing your Web Application 4

5 Securing your Web Application: Threats! 5

6 Securing your Web Application: Threats! 6

7 Securing your Web Application: Threats! 7

8 Securing your Web Application: Threats! 8

9 Securing your Web Application: Requirements! 9

10 SQL Injection 10

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

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

13 SQL Injection: What is wrong? 13

14 SQL Injection: What is wrong? 14

15 SQL Injection: What is wrong? 15

16 SQL Injection: What is wrong? 16

17 SQL Injection: What is wrong? userid = request.getparameter( id ); Statement stmt = cpn.createstatement ( select * from TBL_USERS + where id = +userid + ); User input the following User Id 105; DROP TABLE Staff Select * from TBL_USERS where id = 105; DROP TABLE Staff Is the resulted SQL statement valid? Will it execute? 17

18 SQL Injection: Batched SQL Statement userid = request.getparameter( id ); Statement stmt = cpn.createstatement ( select * from TBL_USERS + where id = +userid + ); User input the following: User Id 105; DROP TABLE Staff Select * from TBL_USERS where id = 105; DROP TABLE Staff SQL Injection - Batched SQL Statement Most databases support batched SQL statement, separated by semicolon. 18

19 SQL Injection: Summary! 19

20 SQL Injection: Prevention!! Check and try code examples: 20

21 SQL Injection: Prevention!! Prepared Statement String custname = request.getparameter("customername"); // should be validated // code to perform input validation to detect attacks String query = "SELECT account_balance FROM user_data WHERE user_name =? "; PreparedStatement pstmt = connection.preparestatement( query ); pstmt.setstring( 1, custname); ResultSet results = pstmt.executequery( ); Prepared statements ensure that an attacker is not able to change the intent of a query, even if SQL commands are inserted by an attacker In the safe example above, if an attacker were to enter the userid of tom' or '1'='1, the parameterized query would not be vulnerable and would instead look for a username which literally matched the entire string tom' or '1'='1 21

22 Cross Site Scripting (XSS) 22

23 Cross Site Scripting (XSS) Cross-site scripting (XSS): 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 23

24 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

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

26 Cross Site Scripting (XSS): What is wrong? Suppose the victim is given this URL by the attacker ( 26

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

28 Cross Site Scripting (XSS): Summary! 28

29 Cross Site Scripting (XSS): Prevention!! 29

30 Cross Site Scripting (XSS): Prevention!! More on XSS prevention rules and examples 30

31 Cross Site Request Forgery (CSRF) 31

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 32

33 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 behaviour to occur on computer software 33

34 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 Such behavior frequently includes things like gaining control of a computer system, allowing privilege escalation, or a denial-of-service attack. 34

35 Cross Site Request Forgery (CSRF) 35

36 Cross Site Request Forgery (CSRF) 36

37 CSRF Attacks Mechanisms GET scenario Using GET method, the money transfer operation might be reduced to a request like GET HTTP/1.1 Maria decides to exploit this web application vulnerability using Alice as her victim. Maria first constructs the following exploit URL which will transfer $100,000 from Alice's account to her account. She takes the original command URL and replaces the beneficiary name with herself, raising the transfer amount significantly at the same time GET The attack that tricks Alice into loading this URL when she's logged into the bank application Sending an unsolicited with HTML content Planting an exploit URL or script on pages that are likely to be visited by the victim while they are also doing online banking The exploit URL can be disguised as an ordinary link, encouraging the victim to click it <a href=" my Pictures!</a> More CSRF Attacks Examples: 37

38 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

39 CSRF: Prevention!! Synchronizer Token Any state changing operation requires a secure random token (e.g CSRF token) to prevent against CSRF attacks. A CSRF Token Unique per user & per user session Tied to a single user session Large random value Generated by a cryptographically secure random number generator The CSRF token is added as a hidden field for forms or within the URL if the state changing operation occurs via a GET The server rejects the requested action if the CSRF token fails validation More CSRF prevention techniques 39

40 Unvalidated Input 40

41 Unvalidated Input 41

42 Unvalidated Input 42

43 Unvalidated Input: Summary 43

44 Unvalidated Input: Prevention! 44

45 Broken Authentication 45

46 Broken Authentication 46

47 Fixing Authentication: How To?! 47

48 Authentication: Hashing Passwords with Salt! To Store a Password Generate a long random salt using a CSPRNG (Cryptographically Secure Pseudo-Random Number Generator) (java.security.securerandom) Prepend the salt to the password and hash it with a standard cryptographic hash function (e.g., SHA256 ) Save both the salt and the hash in the user's database record In Web applications, only hash on the server To Validate a Password Retrieve the user's salt and hash from the database Prepend the salt to the given password and hash it using the same hash function Compare the hash of the given password with the hash from the database. If they match, the password is correct. Otherwise, the password is incorrect. 48

49 Fixing Authentication: Salting Passwords! In cryptography, a salt is 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. 49

quickly especially if the number of passwords in the database is large.

50 Fixing Authentication: Salting Passwords! Why add Salt? If each password is simply hashed, identical passwords will have the same hash. There are two drawbacks to choosing to only storing the password s hash: 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: 50

51 Fixing Authentication: Salting Passwords! Why add Salt? If each password is simply hashed, identical passwords will have the same hash. There are two drawbacks to choosing to only storing the password s hash: Due to the birthday paradox, the attacker can find a password very quickly especially if the number of passwords in the database is large. 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: 51

52 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. 52

53 Fixing Authentication: Salting Passwords! 53

54 Fixing Authentication: Salting Passwords! 54

55 Fixing Authentication: Salting Passwords! 55

56 Session Management 56

57 Session Management: Problem or Solution?! 57

58 Session Management: Problem or Solution?! 58

59 Session Management: Prevention 59

60 Session Management: Prevention Secure Attribute: the Secure cookie attribute instructs web browsers to only send the cookie through an encrypted HTTPS (SSL/TLS) connection. This session protection mechanism is mandatory to prevent the disclosure of the session ID through MitM (Man-in-the-Middle) attacks. HttpOnly Attribute: the HttpOnly cookie attribute instructs web browsers not to allow scripts (e.g. JavaScript) an ability to access the cookies via the DOM document.cookie object. It is mandatory to prevent session ID stealing through Domain and Path Attributes: The Domain cookie attribute instructs web browsers to only send the cookie to the specified domain and all subdomains The Path cookie attribute instructs web browsers to only send the cookie to the specified directory/subdirectories (or paths or resources) within the web application 60

61 Session Management: Prevention Content-Security-Policy (CSP) W3C spec. standard header aimed to prevent a broad range of content injection attacks such as XSS Supported by many browsers including Firefox 23+, Chrome 25+ and Opera 19+ It only allows resources from the originating domain for all the default level directives, and will not allow inline scripts/styles to execute. If your application and function with these restrictions, it drastically reduces your attack surface having this policy in place, and will work with most modern browsers 61

62 Transport Layer Security 62

63 Transport Layer Security (e.g. HTTPS) 63

64 Transport Layer Security (e.g. HTTPS) 64

65 HTTPS: Basics 65

66 HTTPS: Public-Key Cryptography 66

67 HTTPS: Shared-Key Cryptography 67

68 HTTPS: Hashing 68

69 HTTPS: Certificates 69

70 HTTPS: Signatures 70

71 HTTPS: How to? Limitations?! How to? Follow the steps at: 71

72 Application Layer Security 72

73 References

74 74

COMP9321 Web Application Engineering

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