Topic 3 - Core Defence Mechanism PDF
Document Details
Uploaded by FreedJupiter
University of Technology and Applied Sciences - Ibri
Tags
Summary
This document is a presentation on core defense mechanisms for web applications, covering topics such as handling user access, input, attacks and errors. It includes visualizations and diagrams to enhance understanding.
Full Transcript
Topic 3 Core Defence Mechanism Objectives At the end of this module, the students will be able to: Know how to handle user access. Know how to handle user input. Know how to handle attacks. 2 Current Defence Mechanisms Th...
Topic 3 Core Defence Mechanism Objectives At the end of this module, the students will be able to: Know how to handle user access. Know how to handle user input. Know how to handle attacks. 2 Current Defence Mechanisms The defence mechanisms employed by web applications comprise the following core elements: Handling user access to the application’s data and functionality to prevent users from gaining unauthorized access. Handling user input to the application’s functions to prevent malformed input from causing undesirable behaviour. Handling attackers to ensure that the application behaves appropriately when being directly targeted, taking suitable defensive and offensive measures to frustrate the attacker Managing the application itself by enabling administrators to monitor its activities and configure its functionality. 3 Authentication Handling User Session Access Management Reject known bad Access Control Accept known good Handling User Input validation Input Sanitization Handling error Core Defence Safe data Mechanisms handling Maintaining Audit Records Handling Attackers Alerting Administrators Reacting to attacks Managing the Application Vulnerability application Vulnerabilities Assessment 4 Authentication Handling User Session Access Management Reject known bad Access Control Accept known good Handling User Input validation Input Sanitization Handling error Core Defence Safe data Mechanisms handling Maintaining Audit Records Handling Attackers Alerting Administrators Reacting to attacks Managing the Application Vulnerability application Vulnerabilities Assessment 5 Handling User Access A central security requirement that any application needs to meet is controlling users’ access to its data and functionality. Types of users: Anonymous users; guests Ordinary authenticated users; and User Administrative users. Admin In many situations different users are permitted to access a different set of data. 6 Handling User Access Most web applications handle access using a trio of interrelated security mechanisms: 1. Authentication 2. Session management 3. Access control (Authorization) Each of these mechanisms represents a significant area of an application’s attack surface, and each is fundamental to an application’s overall security posture. 7 Authentication Authenticating a user involves establishing that the user is in fact who he claims to be. When should the application treats all users as anonymous — the lowest possible level of trust. Conventional authentication model where the application checks for validity (only!!). Weaknesses: guess users passwords, or bypass the login function by exploiting app vulnerability. 8 Session Management What will happen after successful logging in to the application? To enforce effective access control, the application needs a mechanism to identify and process the series of requests that originate from each user. A token identifies a session. What is the session? What is the session token? How the web app. handle the token session? 9 Session Management The session Plain definition- is a temporary and interactive info. interchange between two communicating devices*. Fancy definition- is a set of data structures held on the server that track the state of the user’s interaction with the application. The token is a unique string that the application maps to the session. Enables the application to associate the request with that user. What is the size of the string? *https://en.wikipedia.org/wiki/Session_(computer_science) 10 Session Management Login Response + Session-Token Request + Session-Token Response Request + Session-Token Response The HTTP cookies are the standard method for transmitting session tokens, although many applications use hidden form fields or the URL query string for this purpose. If a user does not make a request for a certain amount of time, the session is ideally expired. 11 Session Management The session management mechanism is highly dependent on the security of its tokens. Attackers seek to compromise the tokens issued to other users. face mask An attacker can masquerade as the victim user and use the application just as if he had actually authenticated as that user. 12 Group Discussion [10 minutes] What is the difference between a cookie and a session? References https://goo.gl/5kCDwv (PHP) https://goo.gl/PbZjR9 (Java Servlet) 13 Access Control To enforce correct decisions about whether each individual request should be permitted or denied. An application might support numerous user roles, each involving different combinations of specific privileges. it needs to decide whether that user is authorized to perform the action, or access the data, that he is requesting 14 Authentication Handling User Session Access Management Reject known bad Access Control Accept known good Handling User Input validation Input Sanitization Handling error Core Defence Safe data Mechanisms handling Maintaining Audit Records Handling Attackers Alerting Administrators Reacting to attacks Managing the Application Vulnerability application Vulnerabilities Assessment 15 Handling User Input Because the client is outside of the application’s control, users can submit arbitrary input to the server-side application. The application must assume that all input is potentially malicious. A mechanism is required to ensure that attackers cannot use crafted input to compromise the application by interfering with its logic and behaviour 16 Users’ Possible Malicious Activities Users can interfere with any piece of data transmitted between the client and the server, including request parameters, cookies, and HTTP headers. Users can send requests in any sequence and can submit parameters at a different stage than the application expects, more than once, or not at all. Users are not restricted to using only a web browser to access the application. Numerous widely available tools operate alongside, or independently of, a browser to help attack web applications. 17 Common Malicious Activities The majority of attacks against web applications involve sending crafted input to the server to cause some event that was not expected or desired by the application’s designer. (here are some examples) Changing the price of a product transmitted in a hidden HTML form field to fraudulently purchase the product for a cheaper amount. Modifying a session token transmitted in an HTTP cookie to hijack the session of another authenticated user. Removing certain parameters that normally are submitted to exploit a logic flaw in the application’s processing. Altering some input that will be processed by a back-end database to inject a malicious database query and access sensitive data. 18 Approaches to handle user’s input Some kinds of input validation may not be feasible or desirable for all these forms of input. Different/combination approaches are often preferable for different situations and different types of input. Approaches to handle user’s input Reject Known Bad Accept Known Good Sanitization Safe Data Handling 19 Approaches to handle user’s input Reject Known Bad Employs a blacklist containing a set of literal strings or patterns that are known to be used in attacks. The validation mechanism blocks any data that matches the blacklist and allows everything else. Accept Known Good Employs a whitelist containing a set of literal strings or patterns, or a set of criteria, that is known to match only benign input. The validation mechanism allows data that matches the whitelist and blocks everything else. 20 Approaches to handle user’s input Sanitization Recognizes the need to sometimes accept data that cannot be guaranteed as safe. Instead of rejecting this input, the application sanitizes it in various ways to prevent it from having any adverse effects. Safe Data Handling Ensuring that the processing that is performed on the user’s input is inherently safe. In some situations, safe programming methods are available that avoid common problems (e.g. SQL injection) 21 Authentication Handling User Session Access Management Reject known bad Access Control Accept known good Handling User Input validation Input Sanitization Handling error Core Defence Safe data Mechanisms handling Maintaining Audit Records Handling Attackers Alerting Administrators Reacting to attacks Managing the Application Vulnerability application Vulnerabilities Assessment 22 Handling Attacks A key function of the application’s security mechanisms is being able to handle and react to the attacks in a controlled way. Through mix of defensive and offensive measures. Measures implemented to handle attackers typically include the following tasks: Handling errors Maintaining audit logs Alerting administrators Reacting to attacks 23 Handling errors It is difficult to anticipate every possible way in which a malicious user may interact with the application. Some unanticipated errors will occur. 24 Handling errors A key defence mechanism is for the application to \ 1. handle unexpected errors gracefully, 2. recover from them or present a suitable error message to the user, and 3. never return any system-generated messages or other debug information in its responses. An attacker can leverage defective error handling to retrieve sensitive info. within the error messages themselves, providing a valuable channel for stealing data from the application. 25 Handling errors Most web development languages provide good error-handling support through try-catch blocks and checked exceptions. What about PHP and Java? 26 Maintaining Audit Logs Audit logs are valuable primarily when investigating intrusion attempts against an application. Following such an incident, effective audit logs should enable the application’s owners to understand exactly what has taken place, which vulnerabilities (if any) were exploited, whether the attacker gained unauthorized access to data or performed any unauthorized actions, and, provide evidence of the intruder’s identity. ﻣﮭم ﺟدا 27 Alerting Administrators In many situations it is desirable to take immediate action, in real time, in response to attempted attacks. Administrators may block the IP address or user account an attacker is using. take the application offline mitigate the defensive action. 28 Reacting to Attacks Most real-world attacks require an attacker to probe application for vulnerabilities, submitting numerous requests containing crafted input designed to indicate the presence of various common vulnerabilities. Effective input validation will identify these requests as potentially malicious and block the input from having any undesirable effect on the application. However, it is sensible to assume that some may bypasses these filters. Therefore, applications should take automatic reactive measures to frustrate the activities of an attacker. 29 Authentication Handling User Session Access Management Reject known bad Access Control Accept known good Handling User Input validation Input Sanitization Handling error Core Defence Safe data Mechanisms handling Maintaining Audit Records Handling Attackers Alerting Administrators Reacting to attacks Managing the Application Vulnerability application Vulnerabilities Assessment 30 Managing the Application In many applications, administrative functions are implemented within the application itself, accessible through the same web interface. the administrative mechanism represents a critical part of the application’s attack surface. Weaknesses in the authentication mechanism. Lack of effective access control of some of web applications administrative functions. An attacker may find a means of creating a new user account with powerful privileges. 31 Managing the Application Administrative functionality often involves displaying data that originated from ordinary users. Any cross-site scripting flaws within the administrative interface can lead to compromise of a user session that is guaranteed to have powerful privileges. Administrative functionality is often subjected to less rigorous security testing, because its users are deemed to be trusted, or because penetration testers are given access to only low- privileged accounts. 32 References Stuttard, Dafydd, and Marcus Pinto. Web Application Hacker's Handbook : Finding and Exploiting Security Flaws, Wiley, 2011. ProQuest Ebook Central, https://ebookcentral.proquest.com/lib/momp/detail.action?docID =819008. 33