Web Applications: Authorization and Content Delivery

Authorization

• Authorization is the process of determining if a subject has permission to perform an operation against a target resource.
• Authorization is a complex subject.
• It requires consideration of web application characteristics and resources.
• Authorization requirements may be defined by local, regional or national law (e.g., HIPAA).

Recording Lectures

• Recording lectures without permission is a violation.
• Recording and sharing recordings is considered a crime.
• The penalty can include imprisonment or fines.

Authorization (Authz) Fundamentals

• Authorization determines if a subject has enough permission.
• Authorization is a complex subject.
• Web application and resource characteristics are crucial factors.
• Authorization and authentication requirements are often specified by local, regional, or national laws (e.g. HIPAA).

Web Application Security

• Ensuring protection of external web applications from cyber threats is the goal.
• Requirements for cybersecurity must be identified, documented, and approved.
• Implement cybersecurity requirements for protection.
• Standards should cover Web Application Firewall (WAF), multi-tier architecture, secure protocols like HTTPS, and secure user policies.
• Regularly review web application security requirements.

Authorization Fundamentals

• Authenticated subject requests an operation.
• Authorization checks the permission associated with the resource using an Access Control List (ACL).
• If authorized, the operation is performed, and data is readable.
• If not authorized, the request is denied.

Authorization Goals

• Users can only perform actions within their privilege level.
• Access to protected resources is controlled based on user roles/privileges.
• Mitigate privilege escalation attacks(e.g., enabling a non-admin user to access admin functions even as an anonymous guest user).

Authorization Elements: Subjects

• Subjects are anything requesting access to protected resources.
• Examples include humans, web applications, web services, back-end databases, computer systems.

Authorization Elements: Resources

• Protected objects include data and functionality.
• Types are files, databases, and programs.
• Web applications use encoded parameters and data in the session state to identify resources.

Session State

• Most browsers limit cookie sizes to 4096 bytes.
• Session state information, including authentication, is crucial for web applications based on HTTP's stateless nature.
• Sessions are tracked between client and server.
• The state is critical to know who the user is, and what the user is allowed to do on the application.

Authorization Elements: Determining Access

• Access is determined through permissions, access controls, and policies.
• Techniques include permission-based authorization to define user permissions, and role-based authorization to assign roles and their associated permissions.
• Policies such as ACLs apply to specific resources and combine subjects, operations, and resources into discrete bundles.
• Exception handling allows new roles.

Types of Permissions

• Read access: viewing an item.
• Write access: modifying an item.
• Execute access: running a piece of code.
• There are two types of resources: data (read/write permissions), and functions (execute access).

Authorization Layers

• Authorization is not a one-time process.
• It involves multiple layers within web applications, including the web browser, web server, application server, and database server layers.

Controls by Layer (Horizontally)

• Checkpoints are in each layer for authorization.
• The web server layer uses IP addressing (blacklisting/whitelisting) and URL Authorization to control access.
• Application layer controls implement authorization logic in the application server code, using built-in frameworks (e.g., .NET and ASP.NET) or custom frameworks.
• Database layer implementation of authorization.

Where to Put Authorization Logic

• Web application is the usual place for authorization logic, although this can increase deployment complexity.
• Using stored procedures in the database layer is an option
• Security should be prioritized over convenience in choosing the method.

Custom Authorization Mechanisms

• Custom authorization mechanisms should be designed using a 3x3 matrix .
• Consider every place in the application that might need authorization.

The 3x3 Model of Authorization

• The 3x3 model defines items that participate in authorization.
• Users/subjects, operations and resources categorize interactions in the matrix.
• The model helps design an authorization framework.

The 3x3 Model of Authorization (When)

• Authorization checks can occur before the interface loads, before submitting requests, and before granting access.
• Web applications are not loaded together; instead they are distributed among a collection of HTML.

The 3x3 Model of Authorization (Client-side Attacks)

• Checks in the client side can help to keep most users honest.
• They are not substitutes for server side checks, where attackers can manipulate the client-side to behave differently to bypass authorizations.

The 3x3 Model of Authorization (Before Final Access)

• Best practice is to perform auth checks immediately before allowing access from any source including client side.
• Server-side authorization guarantees the best security outcomes.

Time of Check to Time of Use (TOCTOU)

• This occurs when there is an unnecessarily long interval between authorization checks.
• The attacker can benefit from this long interval.
• Web application servers should specify an upper limit for the TOCTOU interval preventing exploit abuses.

TOCTOU Exploits

• A scenario with a married couple needing to complete a transaction.

TOCTOU Exploits: Session Management

• Session management helps handle issues caused by the TOCTOU scenario.
• Use various criteria for automatically invalidating a session.

Web Authorization Best Practices

• Employ the principle of least privilege to limit user access and responsibilities.
• Separate duties and user/administrative functions
• Define strong policies, restricting resource sharing.
• Prevent unauthorized access through account uniqueness.

Attacks Against Authorization

• Forceful Browsing: Designers assume correct authentication.
• Cross-Site Scripting (XSS): Guessing input areas to discover hidden elements of a site's behavior or map out a site.
• Input Authorization/Parameter Tampering: Malicious alteration of parameters in requests.
• HTTP Header Manipulation: Trusting metadata.
• Cross-Site Request Forgery(CSRF): Tricks user's browser into making requests.

Attacks Against Session State

• Tampering: Changing session data to bypass checks.
• Theft: Stealing session ID to impersonate a user.
• Predictability: Session IDs should not be predictable by attackers.
• Hijacking: Stealing or taking over another user's session IDs

Attack Against Sessions: Cross-Site Request Forgery

• Exploiting relationship between application and client using session IDs.
• Attacker cannot know when the victim might take the "bait."
• Mitigation involves session expiration.

Attacks Against Session State: Tampering and Hijacking

• Tampering with or hijacking session state means changing or stealing session-critical elements (e.g., session identity).

Session Management Best Practices

• Enforce absolute session timeouts.
• Limit session concurrency to one active session per user.
• Mandate secure cookies, using methods like HTTPS.
• Use the HttpOnly flag, limiting client-side access to the cookies.
• Use cryptographically random session IDs
• Destroy invalidated session IDs and cookies
• Implement logging during sessions
• Regenerate session IDs on authentication.

Browser Development Tool

• Use browser developer tools for network debugging, checking and identifying HTTP requests.
• This helps to better understand interactions between web application and resources.

Session ID

• There is no standard name for Session ID session cookies.