Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Origin should include scheme according to RFC #379

Closed
wgonczaronek opened this issue Mar 12, 2019 · 3 comments
Closed

Origin should include scheme according to RFC #379

wgonczaronek opened this issue Mar 12, 2019 · 3 comments

Comments

@wgonczaronek
Copy link
Contributor

wgonczaronek commented Mar 12, 2019

The CORS_ORIGIN_WHITELIST should include scheme according to RFC 6454:

3.2.  Origin

   In principle, user agents could treat every URI as a separate
   protection domain and require explicit consent for content retrieved
   from one URI to interact with another URI.  Unfortunately, this
   design is cumbersome for developers because web applications often
   consist of a number of resources acting in concert.

   Instead, user agents group URIs together into protection domains
   called "origins".  Roughly speaking, two URIs are part of the same
   origin (i.e., represent the same principal) if they have the same
   scheme, host, and port.  (See Section 4 for full details.)

   Q: Why not just use the host?

   A: Including the scheme in the origin tuple is essential for
   security.  If user agents did not include the scheme, there would be
   no isolation between http://example.com and https://example.com
   because the two have the same host.  However, without this isolation,
   an active network attacker could corrupt content retrieved from
   http://example.com and have that content instruct the user agent to
   compromise the confidentiality and integrity of content retrieved
   from https://example.com, bypassing the protections afforded by TLS
   [RFC5246].

Current implementation only checks netloc part, whereas it should check against scheme, host and port. This RFC is used as reference in W3 recommendations so I think it would be useful to comply to it. I would like to limit access to origins using https protocol.

EDIT I was thinking about implementing such a feature in a way that would allow user define origin with or without scheme, optionally with deprecation warning if it's defined without scheme. Tell me what you think.

@adamchainz
Copy link
Owner

Hi @wgonczaronek

Sorry for slow reply

Yes you're right, the whole origin should be checked including scheme. #259 basically reported this too, but at that time I wasn't aware it's in the spec.

We should fix this, if you have plans for a PR that sounds great. Deprecating origins without scheme or port sounds like a fine idea to me. I'd just like to do as browsers do and not need ports if they're the defaults for the scheme (e.g. https://example.com implies https://example.com:443).

If you have time for a PR please get started. Don't forget to update the documentation and HISTORY.

@wgonczaronek
Copy link
Contributor Author

I'll look into it.

adamchainz pushed a commit that referenced this issue May 10, 2019
@adamchainz
Copy link
Owner

#388 was merged and #397 improved it. Fix released in version 3.0.0: https://pypi.org/project/django-cors-headers/3.0.0/

Thanks for doing the PR @wgonczaronek !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants