Browsers implement CORS to protect users, not servers

CORS is designed to protect users from cross site attacks where one site has the browser execute code to connect to another site without the user recognizing that it happened. CORS relies on the Web Browser to recognize and block disallowed cross site requests.  Server side CORS does not block service requests or protect a web site from direct interrogation and or programmatic attack.

Applications and Internet facing services cannot rely on CORS for general site protection. They can rely on CORS to protect the site when the site is connected to by a web browser.    Companies should not consider CORS any type of secure Authorization model. They should implement CORS policies that provide least privilege where possible.

Specified by Server, Implemented by Browser

Application servers can say that they allow connections from any browser no matter where that original browser session / page originally resided. This makes it simple for any page to aggregate information from multiple back-end services on multiple sites.

Application servers can say that they allow connections from a browser only when an original browser session / page were started on an approved web site. The basic flow looks like

  1. A user connects to a web site.
  2. The browser downloads HTML and Javascript.
  3. The browser makes a call for data from the original domain. The request is allowed because the page and data are from the same origin. 
  1. The browser requests data from a 2nd site.
  2. The browser sends a CORS request to the second site asking for a list of domains that are allowed to call the services on that site.
  3. The 2nd site CORS response describes which domains are allowed to connect for this cross-origin scenario.
  4. If not allowed, the browser aborts the call to services outside the page's origin domain with a return code of "Not Authorized"


NOTE: The browser implements cross-site authorization protection. The server specifies the desired protection level and the browser tries to implement it.

Specified by Server, Ignored by Appplications

Remember that CORS is implemented in the Browser to protect the User. CORS restrictions are not honored by web client libraries or the applications that sit on them.

CORS Specification: Allowing Cross Origin Requests

There really only three levels of cross origin that are allowed. They are specific and different: 

  • All : A server can say that it allows requests from pages and applications that originate in all other domains.  Examples uses include: Shared services, advertising services and other public endpoints.
  • None: A server can say that "no cross origin requests are allowed". This tells the browser that the service is only available to content/pages that originate on the same web server (FPDN).
  • Specified Exactly: A server can enable cross-site requests from specific hosts. Companies may use this setting to white-list their own cooperative applications while disabling request from outside organizations. Note that each host has to be listed here.
Wild cards are not supported.  This means that "*.domain.com" does not work.

Scenario: Multiple Enterprise Applications

A company could have a set of applications that exist as static content on web servers. The same company could put out a set of services to be shared across the organization.

Every web service host would list all internal Static Content host names in their CORS definitions.

This would let all applications share services while blocking consumption by non-firm web applications.










Working around CORS

CORS protection is all about "Cross Origin". It has no impact if everything looks like it comes from the same origin.  An alternative of building cooperative applications without explicitly listing hosts is to proxy all static content and and  HTTP/HTTPS web services through a single proxy. This would make all requests look like they came from the same domain.







    This post on YouTube



    References

    • https://en.wikipedia.org/wiki/Cross-origin_resource_sharing
    • https://www.owasp.org/index.php/CORS_OriginHeaderScrutiny
    Created 2017/11

    Comments

    Post a Comment

    Popular posts from this blog

    Installing the RNDIS driver on Windows 11 to use USB Raspberry Pi as network attached

    Image
    I do a lot of my development and configuration via ssh into my Raspberry Pi Zero over the RNDIS connection. Some models of the Raspberry PIs can be configured with  gadget drivers  that let the Raspberry pi emulate different devices when plugged into computers via USB. My favorite gadget  is the network profile that makes a Raspberry Pi look like an RNDIS-attached network device.  All types of network services travel over an RNDIS device without knowing it is a USB hardware connection. A Raspberry Pi shows up as a Remote NDIS (RNDIS) device when you plug the Pi into a PC or Mac via a USB cable. The gadget  in the Windows Device Manager picture shows this RNDIS Gadget connectivity between a Windows machine and a Raspberry Pi. The Problem Windows 11 and Windows 10 no longer auto-installs the RNDIS driver that makes magic happen. Windows recognizes that the Raspberry Pi is some type of generic USB COM device. Manually running W indows Update  or  Upd...
    Read more

    Understanding your WSL2 RAM and swap - Changing the default 50%-25%

    Image
    The Windows Subsystem for Linux operates as a virtual machine that can dynamically grow the amount of RAM to a maximum set at startup time.  Microsoft sets a default maximum RAM available to 50% of the physical memory and a swap-space that is 1/4 of the maximum WSL RAM.  You can scale those numbers up or down to allocate more or less RAM to the Linux instance. The first drawing shows the default WSL memory and swap space sizing. The images below show a developer machine that is running a dev environment in WSL2 and Docker Desktop.  Docker Desktop has two of its own WSL modules that need to be accounted for.  You can see that the memory would actually be oversubscribed, 3 x 50% if every VM used its maximum memory.  The actual amount of memory used is significantly smaller allowing every piece to fit. Click to Enlarge The second drawing shows the memory allocation on my 64GB laptop. WSL Linux defaul...
    Read more

    Almost PaaS Document Parsing with Tika and AWS Elastic Beanstalk

    Image
    The Apache Tika project provides a  library capable of parsing and extracting data and meta data from over 1000 file types.  Tika is available as a single jar file that can be included inside applications or as a deployable jar file that runs Tika as a standalone service. This blog describes deploying the Tika jar as an auto-scale service in Amazon AWS Elastic Beanstalk.  I selected Elastic Beanstalk because it supports jar based deployments without any real Infrastructure configuration. Elastic Beanstalk auto-scale should take care of scaling up and down for for the number of requests you get. Tika parses documents and extracts their text completely in memory. Tika was deployed for this blog using EC2 t2.micro instances available in the AWS free tier. t2.micro VMs are 1GB which means that you are restricted in document complexity and size. You would size your instances appropriately for your largest documents.   Preconditions An AWS account. AWS ac...
    Read more