Lecture 7 Authorization PDF

AUTHORIZATION Prepared by: Dr. Alia Alabdulkarim ‫‪Recording Lectures‬‬ ‫ﻧﻈًﺮا ﻟﻤﺎ ﺗﻢ ﻣﻼﺣﻈﺘﻪ ﻣﻦ ﺗﻜﺮار ﻣﺨﺎﻟﻔﺔ اﻟﺘﺴﺠﯿﻞ اﻟﺼﻮﺗﻲ‪/‬اﻟﻤﺮﺋﻲ ﻣﻦ دون اذن اﻟﺸﺨﺺ‬ ‫اﻟﻤﺴﺠﻞ وﺟﮫﻞ اﻟﻄﺎﻟﺒﺎت ﺑﺄن ھﺬا اﻟﻌﻤﻞ ﻳﻌﺘﺒﺮ ﻣﺨﺎﻟﻔﺔ وﺗﺪاوﻟﻪ ﻳﻨﺪرج ﺗﺤﺖ اﻟﺠﺮاﺋﻢ اﻟﻤﻌﻠﻮﻣﺎﺗﯿﺔ‬ ‫)اﻟﻔﻘﺮة اﻟﺜﺎﻟﺜﺔ ﻣﻦ اﻟﻤﺎدة اﻟﺨﺎﻣﺴﺔ( واﻟﺬي ﻳﻌﻨﻰ ﺑﺎﺳﺘﺨﺪام وﺳﺎﺋ...

AUTHORIZATION Prepared by: Dr. Alia Alabdulkarim ‫‪Recording Lectures‬‬ ‫ﻧﻈًﺮا ﻟﻤﺎ ﺗﻢ ﻣﻼﺣﻈﺘﻪ ﻣﻦ ﺗﻜﺮار ﻣﺨﺎﻟﻔﺔ اﻟﺘﺴﺠﯿﻞ اﻟﺼﻮﺗﻲ‪/‬اﻟﻤﺮﺋﻲ ﻣﻦ دون اذن اﻟﺸﺨﺺ‬ ‫اﻟﻤﺴﺠﻞ وﺟﮫﻞ اﻟﻄﺎﻟﺒﺎت ﺑﺄن ھﺬا اﻟﻌﻤﻞ ﻳﻌﺘﺒﺮ ﻣﺨﺎﻟﻔﺔ وﺗﺪاوﻟﻪ ﻳﻨﺪرج ﺗﺤﺖ اﻟﺠﺮاﺋﻢ اﻟﻤﻌﻠﻮﻣﺎﺗﯿﺔ‬ ‫)اﻟﻔﻘﺮة اﻟﺜﺎﻟﺜﺔ ﻣﻦ اﻟﻤﺎدة اﻟﺨﺎﻣﺴﺔ( واﻟﺬي ﻳﻌﻨﻰ ﺑﺎﺳﺘﺨﺪام وﺳﺎﺋﻞ ﺗﻘﻨﯿﺎت اﻟﻤﻌﻠﻮﻣﺎت ﻟﻠﺘﺸﮫﯿﺮ‬ ‫ﺑﺎﻵﺧﺮﻳﻦ وإﻟﺤﺎق اﻟﻀﺮر ﺑﮫﻢ‪.‬وﻳﻌﺎﻗﺐ ﻋﻠﯿﮫﺎ ﺑﺎﻟﺴﺠﻦ ﻣﺪة ﻻ ﺗﺰﻳﺪ ﻋﻦ ﺳﻨﺔ وﺑﻐﺮاﻣﺔ ﻻ ﺗﺰﻳﺪ ﻋﻦ‬ ‫ﺧﻤﺴﻤﺎﺋﺔ أﻟﻒ ﷼ أو ﺑﺈﺣﺪى ھﺎﺗﯿﻦ اﻟﻌﻘﻮﺑﺘﯿﻦ‪.‬‬ Authorization (AuthZ) Fundamentals Authorization: is the process of determining whether a subject has sufficient permission to perform a given operation against a target resource. Authorization is a complex subject. Must take into consideration the characteristics of a web application and their resources The requirements for authentication and authorization may well have been determined in conjunction with local, regional, or national law. Example: HIPAA. You need to spend some time during early phases to gather info about Determining Resource laws that can govern Subject Access (Object) your web app. 3 Web Application Security 4  Authorization Fundamentals ACL : Access Control List Read Write Authenticated means Who writes readable User has session ID data (blood examination)? AuthZ 5 elements 1-Subject 2- Determining Access 3-Object (resources) Authorization goals There are three specific goals associated with it: To ensure that users can only perform actions within their privilege level. To control access to protected resources using criteria based on a user’s role or privilege level. To mitigate privilege escalation attacks, such as might enable a user to access administrative functions while logged on as a non-administrative user or potentially even an anonymous guest user. 6 Authorization Elements 1.Subjects The thing requesting access to protected resources KSU Student LMS DB 7  Authorization Elements 2.Resources (Objects) The protected objects: data or functionality File Database Programs How a web application knows what the resource in question is for any given access request? 1. Encoded in URL parameters: http://www.MyHometownNewspaper.com/archives?article=0029385923 Difference between 1 2. Encoded as path components within the URL: http://www.amazon.com/Animal-Farm-Anniversary- and 2 George-Orwell/dp/B000KWSLAO 3. Encoded or identified by data stored within the session state à adds little security 8 Session State Most browsers restrict cookie size to 4096 bytes 9 Authorization Elements 3. Determining Access Session ID Once the web application has determined the subject and what the subject wants to do, it can determine whether the action is permitted Through rules: many names permissions, access control, policies.. Session State – URL parameter – URL Path We have heterogeneous techniques to define and enforce these rules. Among these techniques, we can highlight two: Permission-based authorization defines permissions to each system’s user Role-based authorization specifies permissions to a set of roles of a system, roles assigned to each user. 10 Authorization Elements 3.Determining Access 1. Policies: ACL are permissions that are applied to a specific resource ACL combines particular subjects, operations, and target resources into discrete bundles They can be fine-grained and flexible è More active administration Can we make exceptions? What we need to get full access to resources? 11 Authorization Elements 3.Determining Access 2. Role-based authorization labels resources with groups of subjects (roles) Requires two-stage decision: Assessing what roles can perform the requested action Determining whether the subject is a member of any of these roles Less flexible èeasier to administer Can we make exceptions? We need to create a new special role to hold subject(s) who need to have that exception. Which style to choose is one of the key decisions 12 Types of permissions Read access: ability to see what something is Write access: ability to change something Execute access: ability to run a piece of code in order to do something There are two kinds of resources that users attempt to access Read & Write permission Execute permission 13 Authorization Layers (Reading assignment) Authorization is NOT a one-time thing. We have four layers in web applications: Web browser layer Web server layer (static content) Application server layer (dynamic content) Database server layer AuthZ should happen at many points and many times within a web app. 14 When and How to Authorized 15  Authorization Layers (Reading assignment) Traditional computer security concerns with vertical interaction User to application (horizontally) Horizontally: it takes place between systems on the path from user to app. Interacting components Vertically: it takes (vertically) place between interacting components within an individual system. 16 Web browser layer Web server layer Application server layer Database server layer Controls by layer (Horizontally) Talk about potential authorization checkpoints in each layer. Web server layer IP Addressing Blacklisting Ø Block IP who performs DoS. How? IP Addressing whitelisting Ø internal private network (intranets) URL Authorization (most java web server allows limit access to URL through setting or configuration files) Ø specify which users and groups can access what URLs. OS Authorization (web application| server must run in some context within the OS) Ø Use OS native security framework of file and directory permissions, security group, ACL, …. 17 Ø Reduce damages when web applications are compromised Controls by layer (Horizontally) Application server layer Can use the same basic techniques as the previous ones (IP black or white listing…). In addition to: Application Compartmentalization Servlet and App Server Restrictions Ø Java implemented applications Ø Use resource management configuration features Ø Complex Application Server Code Ø Using the business logic within the web application to implement authorization Ø Three ways to do it: § Use a built-in framework: Mircosoft’s.NET and ASP.NET platform § Use an existing, open plug-in authorization module: add features not present in frameworks § Develop a custom framework: significant responsibility 18 Code Access Security: performing authorization on pieces of code to determine whether the code is allowed to run with the capabilities it wishes to use. Controls by layer (Horizontally) Database Server Layer Databases have their own implementations of concepts like users, roles, permissions, and so forth Take advantage of these features to implement part of the application’s authorization scheme Ø Stored procedures à revoke direct access permissions from all the tables in the DB Ø User accounts: and reduce their permissions to the bare minimum Procedures ___________ ___________ Web ___________ Application Database ___________ ___________ 19 Where should you put authorization logic AuthZ logic: the code that enforces those permission policy decisions 1. Web application (Most popular) + Simplifies the design and development process - Complicates deployment and maintenance: web admin and DB admin are different people 2. Database layer Stored procedures can contain authorization logic Before running that query, the stored procedure can first figure out whether the user making the request is allowed to do so or both Which one is better? There is no right or wrong here. Just make sure you make the decision for security reasons rather than convenience. 20 Custom authorization mechanisms Not recommended (security code can be hard and tricky to get right) You can’t receive any help and support However, if you need to use your own custom authorization mechanism: Any authorization framework should be designed around a 3-by-3 matrix of factors (also referred to as a lattice). It ensures you will consider all the critical authorization points in your application Why is it necessary? (the 3-by-3 matrix) Alternative: designers brainstorm a list of every place in the application that needs to consider 21 authorization. They can forget an important area that leaves your application open to attack. The 3X3 model of authorization 2 axis: 1- What (3 categories of item of participant) 2- When (3 places) The pairings between the items on each axis of the matrix gives you a systematic basis for designing your authZ framework. 22 The 3X3 model of authorization What: considers the categories of items that participate in authorization 23 The 3X3 model of authorization When: it considers the times when permission checks need to happen and approvals granted or denied To a degree, it also captures where these checks need to take place Before loading the interface Before requests are submitted Before granting final access 24 The 3X3 model of authorization Before loading the interface Web applications are not loaded at onceè distributed among a collection of HTML pages. It does not need to make a one-time all-or-nothing decision. They will perform authorization checks before ever sending that part of the interface to the user’s web browser There are two main ways to do it. It’s better to do both Link filtering: web application omit the link for unauthorized user Ø Hidden sensitive functionality from users who not authorized. Ø Vulnerable to forceful browsing Ø It should be done with each URL request Redirect upon direct URL access Ø Root URL, terminating session ,.. Other secure failure action… 25 Forceful Browsing 26 The 3X3 model of authorization Before (HTTP|HTTPS) requests are submitted Interactive web pages creates the possibility of using client-side code to implement additional authorization checking Warning: it is only for performance, it offers zero protection against determined attackers Ø Save server time from dealing with request that will only be denied Client-side code can deter casual attackers driven by curiosity more than actual malice. They are trivial to bypass It can also filter the links. Its there but you can’t see it you can’t click it (using CSS or DOM). Attackers can use reverse engineering to extract hidden links It can also defend against a user interacting with UI elements at the wrong time. Disable submit button when field has improper value 27 The 3X3 model of authorization Client-side attacks Client-side checks are helpful for keeping most users honest and for improving overall CSS and JavaScript can be used to display the places color code that show which is available system performance by keeping most bad and which is reserved. requests from reaching the server side But they are not a substitute for actual authorization checks elsewhere If the checks are only in the client side, attackers can do tricks using browsers extensions or intercept HTTP request and change the seat number to pick whatever https://www.smartertravel.com/ seat they want even it it’s shown to be not 28 available. The 3X3 model of authorization Before granting final access The most important time to perform authorization checks, and the most important place to perform them, is on the server immediately before granting final access to anything The server can be the web application server, the database server or both. The strongest guarantees of security come from server-side authorization The server is the last line of defense for those resources The best time to make server-side authorization checks is as close as possible to the time when an action is to be taken, to avoid the “time of check to time of use (TOCTOU)” problem. 29 Ø Race condition vulnerability  The 3X3 model of authorization Time of check to time of use (TOCTOU) The idea is to minimize the interval between these two times, because an overly lengthy interval can create the potential for abuse It can show up in two different forms: Different person using an authenticated and authorized user’s account without permission Ø Do an action on behalf of you. Subject’s permissions may change Web application servers should specify upper limit on the TOCTOU interval. This limit represents a time beyond which the server isn’t even willing to trust its own prior authorization checks 30  TOCTOU exploits Married couple example Go to the Sign-in to bank and bank Go to take a website meeting check Open the Offer to Go home fund give half and transfer complete form fund transfer 31 Based on your experience with web apps, how can we avoid this problem? form TOCTOU exploits Automatically invalidating the session Solution to deal with TOCTOU problem: session management Automatically invalidate sessions based on various criteria: A session that has been idle for too long can be expired A session that has simply been in existence for too long can be expired A session can be forcibly expired if the timestamp on the permission records for the user is newer than the creation timestamp of the session ID, thus indicating permission changes. 32 Web authorization best practices (Reading assignment) Failing closed Minimizing custom authorization Fails securely code Operating with least privilege Protecting static resources Separating duties Avoiding insecure client-side users and admin authorization tokens Defining strong policies Keeping accounts unique Using server-side authorization Don’t allow users to share accounts Mistrusting everybody Authorizing on every request Centralizing the authorization mechanism 33 Attacks against authorization Forceful browsing Designers assume that users couldn’t have reached the URL unless they had permission to use the functions exposed by this URL. XSS maybe used in a completely unrelated website to obtain user’s browsing history à make a site map Or by guessing: admin.php or main.html That’s why we need to authorize on every request Input authorization/parameter tampering Occurs when an attacker or malicious user alters the parameters of a request before the request reaches the web application Any data stores in URL parameters, cookies, or form fields is subject to tampering. Dan’s example 34 Attacks against authorization HTTP header manipulation Contains metadata about the request Should never be trusted for authorization, except for the cookie holding the session ID Attacker have control over it à CSRF, SQL injection…. 35 Attacks against authorization Cross-site request forgery (CSRF) ‫ﺗزوﯾر‬ Occurs when an attacker tricks a victim’s browser into making an HTTP request against a target web application The victim is already authenticated à has SessionID Example: attacker stole Joe’s web browsing history through XSS à online banking history (purchases) Ø à chat forum for vintage cars à crafts a post Sensitive operations should be properly authorized, or require additional authorization 36 beyond a valid session ID Session Management 37 Session Management The key challenge is that HTTP is stateless Example: two students logged on edugate Sessions represent a user’s authentication and authorization for the duration of a user’s interaction with your web application Session management is the means by a client and server keep track of who a user is It is also related to what that user is allowed to do, and what the user is actually doing Is how the web server knows you are you, after you have been authenticated Allow\deny access Web application security is impossible without sessions What’s a session? Tracking a single user’s interactions with the web application 38 Session management fundamentals A secure (encrypted) session ID will therefore look like random data The harder you make it for an attacker to guess the value, the harder it is for them to impersonate an active session with the web application 39 Session management fundamentals When to issue sessions IDs? Many web applications issue a session ID at the time an unknown user performs the application’s authentication procedure, but some do so before authentication Example: filling the shopping cart before signing-in Before completing the purchase, the user must sign-in à issue new session ID Never reuse a session ID à let the web client dictate to you the session ID value open you up to session fixation attack If the applications doesn’t need to track user behavior prior to authentication à it’s safer not to do it 40 What is session state Session IDs help enormously by at least allowing a web application to tell different users apart But they don’t track user’s information across a session Shopping cart, your previous actions or previous requests Common strategies to track user’s information across a session: Cookie: content held in one or more client-side cookies Ø Pros: easy to implement Ø Cons: insecure, unless encrypted; and limited to 4KB of data, performance issue Form fields and URL query parameters: Ø Not secure Ø URL parameters è length challenge Web storage: introduced by HTML5 è client side Ø Improves cookie storage issue, but we still can’t trust the client unless encrypted, not send with each request 41 What is session state Common strategies (cont.): Flash Local Shared Objects (LSOs): web applications using Adobe Flash Player Ø Called also Flash cookie Ø Same security issues as cookies Silverlight isolated storage: Microsoft’s platform Ø Client-side and server-side storage Ø Client-side storage not considered secure unless encrypted Server-side storage: Ø Modern web application server implementations provide facilities for session state management Ø Name/value pair associated with a user’s session ID 42 How to manage session state? 43 Attacks against sessions Tampering Also referred to as: cookie poisoning Modifying the client-side session ID or other data to bypass authorization checks Relies on session state being stored in any client-side data storage such as cookies or form fields. Example: storing permission level in cookies Theft Stealing the session ID value to impersonate the victim Mitigations are generic (see Session Management Best Practices ) Ø XSS: trick the victim in running a script to transmit the cookies on their browser Ø Intercept by using packet sniffer who has access to the network § SSL and HTTPS (reading assignment) 44 Attacks against sessions Predictability Session IDs should not be predictable Attacker can then generate the next 100 or 1000 session IDs and wait for a user to be assigned one of them Session fixation When an attacker is able to prepopulate a victim’s web browser with session ID value Mitigation: Ø Not issue before authentication Ø Or issue a new one (not to reuse session IDs) Session hijacking Use a stolen or fixated session ID to impersonate a legitimate user è prevent the user from using it 45 Attacks against sessions Cross-site request forgery Cause the victim’s browser to take a single desired action within the application It exploits the trust between the application and the client based on the session ID Works by tricking the web browser into making a request for a URL à hidden elements Attacker cannot predict when the victim might take the bait (if ever) Ø Succeed attack: hijacking a still used session, or been idle for a long period of time Mitigation: session expiration 46 Attacks against session state Sessions and session state go hand in hand Two principal concerns: data tampering and data hijacking Tampering: when an attacker is able to alter elements within a session state Ø Dan’s example Hijacking: when an attacker is able to steal the contents of the session state Ø E-commerce web site à identity theft Mitigation: client-side à encryption. Or just store everything at server-side 47 Session Management Best Practices (Reading Assignment-P 141) Enforcing absolute session timeouts Enforcing idle session timeouts Limiting session concurrency (active session single user can have - sessions per user) Mandating secure cookies (secure tag – uses ssl and https) Using the HttpOnly flag Using cryptographically random session IDs Destroying invalidated session IDs Using encrypted cookies Logging out 48 Regenerating session IDs on Authentication Browser Development Tool (Reading Assignment) 49 Browser Developer Tool Google Chrome 1 Select the top right icon in your browser 2 Select More tools then choose developer tools 3 50 Browser Developer Tool Cookies Files log in to your KSU email account go to application tab and click cookies check what have been stored into your browser cookies Select a file added by KSU Delete the selected files by clicking Refresh browser What happens? 51 Browser Developer Tool Network Request After making some sort of activity in your browser. Select network tap and check randomly the HTTP request send by your browser 52 Session ID There is no standard name for Session ID any cookie can hold the session ID 53 References Web Application Security: A Beginner’s Guide Chapter 4 54