Web Security: Cookies and Attacks

Cookies and Web Attacks

• Web Same Origin Policy prevents a website from accessing resources from another website.
• A DOM origin is defined by (scheme, domain, port), e.g., (http, stanford.edu, 80).
• A website can embed resources from any origin, but the requesting site cannot access the content from another origin.

DOM SOP Vulnerabilities

• Attackers can exploit DOM SOP by requesting resources without needing to see the response.
• This enables them to extract sensitive data (e.g., bank account transfer information) without directly seeing it.

Javascript Requests

• Javascript allows making requests for additional data and resources.
• Often used to fetch data from a different domain.
• An example using jQuery is shown.

Cross-Origin Resource Sharing (CORS)

• Javascript cannot read data from a different origin by default.
• Servers can add an Access-Control-Allow-Origin header to allow access from another origin.
• For example, if app.bank.com wants to access data from api.bank.com, api.bank.com needs to include the header ACAO: app.bank.com in its response.

Simple vs. Pre-Flight Requests

• CORS performs a pre-flight check when a request would be impossible without Javascript, to see if the server allows it from the specified origin.
• A pre-flight check is required when sending JSON data.
• The OPTIONS request is used as a preliminary check.

HTTP Cookies

• HTTP Cookies are used to store data on the client-side.
• A Set-Cookie header is used to set cookies in the response from the server.
• The header contains the cookie name and value.

Cookies and Same Origin

• Cookies are sent based on the origin regardless of the requester.
• Cookie's domain is the domain suffix of the URL's domain.
• Cookie's path is a prefix of the URL path.
• Cookies that belong to the domain or parent domain AND are at the same path or parent path are in scope
• In scope cookies are sent regardless of who is making the request.
• Non-in scope cookies are restricted to a specific domain and path.

Setting Cookie Scope

• Website permissions for cookie setting are based on the parent-child relationship of the domain and path
• cs155.stanford.edu can set a cookie for stanford.edu
• website.com/ can set a cookie for website.com/something
• A child domain can access/set cookies on its parent domain
• A parent domain cannot access/set cookies on child domains

No Domain Cookies

• Cookies are scoped to the host name, instead of the domain
• Cookies are not sent to subdomains if the server does not specify the domain in the set-cookie header

Cookie Scoping

• Cookies are specific to the domain and path.
• Without a domain specified, cookies are sent only to the exact matching domain.
• If no path is defined in the Set-Cookie header, the path defaults to the current path. Otherwise, all subdirectories in path will receive the cookie.

Javascript Cookie Access

• Javascript can modify in-scope cookies in the document.cookie attribute.

SOP Policy Collisions

• Cookies set by one part of site (e.g. cs.stanford.edu/dabo) are not accessible from another part (e.g., cs.stanford.edu/zakir).

Third Party Access

• Javascript running from a different domain can access the cookies of the origin that included it.

HttpOnly Cookies

• HttpOnly cookies are not accessible by Javascript on the client-side (document.cookie).

Problem with HTTP Cookies

• Attackers can trick a user into navigating to an unauthorized website using a malicious link, even if the user is accessing this website using HTTPS, this makes cookies vulnerable to theft.

Secure Cookies

• A secure cookie is only sent to the server with a HTTPS request.

Cookie Attack

• This describes how a POST request allows the client to change the cookie
• This will be followed by a Get request which will require a cookie

Session Hijacking Attacks

• Session hijacking is capturing a user's session using methods like network sniffing or malicious Javascript.

Cross-Site Request Forgery (CSRF)

• CSRF is a web exploit where a website sends unauthorized commands as a user
• A user is tricked into submitting an unintended web request to a website.

Cookie-Based Authentication

• Cookie-based authentication isn't secure for requests with side effects.

Preventing CSRF Attacks

• To prevent CSRF attacks, add mechanisms to verify that a request is authentic, as cookies on their own do not guarantee this.
• Common methods for this include referrer validation, secret validation tokens, custom HTTP headers, and same-site cookies.

Referer Validation

• This technique uses the Referer header in the request to check where the request came from.
• If the request did not come from a trusted source this will not pass validation.

Secret Token Validation

• Servers include a unique token in forms that clients need to include in form submissions to verify the authenticity of the request.

Secret Token Generation

• The method used to create a unique token on the server-side.
  • A static token can be used within forms, but if the user accesses the server using any means outside the form, the token is potentially exposed.
  • The token can be session-specific and sent as part of the page to protect from theft due to separation of permissions

Force CORS Pre-Flight

• This forces the browser to use a pre-flight check when a request is made, alerting the server that this request needs this type of check.
• Typically, developers use headers like X-Requested-By.

SameSite Cookies

• This prevents the browser from sending the cookie along with cross-site requests.
• Strict mode disables sending cookies in any cross-site context, even when following a regular link.
• Lax mode allows cookies only in cases where a regular link is used to navigate to the requested site. However the mode blocks the same-site cookie during CSRF-prone requests

Beyond Authenticated Sessions

• CSRF attacks can be used even when the user is logged into the service.
• There are other attacks unrelated to authentication. For example, scripts that access the users router and modify sensitive settings.

SQL Injection

• SQL injection attacks occur when unsafe user data is used in SQL queries.
• Attackers can gain access and modify sensitive data, run arbitrary commands.

SQL Injection Example

• An example of how SQL injection lets attackers add unexpected commands

Non-Malicious Input

• An example of an expected query

Bad Input

• An example of an attempt to exploit the query

Malicious Input

• An example of a successful attack

No Username Needed!

• An example of an attack that does not require a username

Causing Damage

• An example of a successful attack that causes SQL server damage

MSSQL xp_cmdshell

• A Microsoft SQL server feature that allows running arbitrary system commands

Escaping Database Server

• An example of exploiting the MSSQL xp_cmdshell feature to run arbitrary commands, possibly gaining access to the system

Preventing SQL Injection

• Don't trust user input when constructing commands.
• Use parameterized SQL or ORMs.

Parameterized SQL

• Parameterized SQL separates commands from arguments, preventing attackers from injecting malicious code

Object Relational Mappers

• ORMs offer a way to interact with the database, which do not require manual SQL command construction.

Cross Site Scripting (XSS)

• An attack where malicious code is injected into a legitimate webpage
• Attacker's code is executed on user's browser, not the server.

Search Example

• An example of a search page vulnerable to XSS

Normal Request

• A demonstration of a normal search request to a webpage, without any embedded malicious content

Embedded Script

• Examples of how malicious scripts can be injected to a webpage, or a different origin.

Cookie Theft!

• An example that demonstrates how malicious content can be used to steal cookies from the user
• This may not be an XSS attack. but a malicious injection.

Types of XSS

• Reflected XSS, where the code is reflected back to the user.
• Stored XSS, where the code is stored on a server.

Reflected Example

• An example of how reflected XSS could be used.
• Attackers can trick users into websites that run malicious scripts which could run arbitrary commands

Stored XSS

• Attackers can store malicious code in a server resource that would be run by any user who accesses it

Samy Worm

• A malicious exploit that spread quickly using XSS vulnerabilities

MySpace Bug

• A vulnerability in MySpace that allowed users to run malicious scripts

Filtering Malicious Tags

• Techniques used to prevent XSS attacks

Filtering is Really Hard

• There are multiple ways of making malicious code that could be run if users do not use secure techniques
• Many XSS attacks involve escaping/encoding to circumvent filters.

Filters that Change Content

• The types of filters and escapes that could be used to prevent XSS attacks

Content Security Policies (CSP)

• Defines a whitelist of allowed resources, preventing the execution of untrusted scripts.
• Content-Security-Policy

Other Directives

• CSP provides other rules for various resources such as images, fonts, or JavaScript

Mozilla Recommended Default

• A sample CSP policy that whitelists resources from the same origin, preventing various types of attacks.

Report Mode Only

• CSP report-only mode reports violations without blocking resources.

Real-World Breaks CSP

• An example of how real world scripts could violate CSP

Similar Protection for iFrames

• HTML5 sandboxes provide enhanced protection for iframes, preventing attacks despite being on the same domain
• IFrame protections can be violated with vulnerabilities, e.g. iframes can still use various attack methods to abuse features without any further security restrictions that are not present on the main page

Explore the complexities of web security with a focus on cookies and various web attacks. This quiz covers concepts like the Same Origin Policy, cross-origin resource sharing, and vulnerabilities related to DOM SOP. Test your understanding of how these elements interact to protect sensitive data on the web.