Giters

adamchainz / django-cors-headers

Django app for handling the server headers required for Cross-Origin Resource Sharing (CORS)

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Origin should include scheme according to RFC

wgonczaronek opened this issue · comments

commented

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.

commented

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.

commented

I'll look into it.

commented

#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 !