>
> I agree; note however, that nonces are part of CSP Level 2, which is in
> "W3C Recommendation" status
Ah, I am not familiar with all these standards, thanks for clarifying.
The first part I think Django should be involved in in generating the nonce
> (a simple base64(os.random(16)) and making it available from the request
> object. Doing this in SecurityMiddleware sounds natural.
Makes sense, also the middleware should be the thing adding the header.
The explicit way would be to add a `{% csp_nonce %}` template tag, which
> expands to `nonce=NONCE` if SecurityMiddleware if a nonce is available
> (SecurityMiddleware is enabled), and to nothing otherwise. Apps will need
> to annotate their tags with it, similarly to how `{% csrf_token %}` is used.
>
Agree with the logic around making it a conscious choice, auto-adding it
after the rendering is just leaving the security hole wide open as it's
impossible to tell what was part of the template and what is data that
potentially injected a <script>.
django-csp-nonce generates two different nonces, one for <script>s and one
for <style>s. I can't tell if this is really more secure... 🤔 Thoughts?
On 16 May 2017 at 20:08, Ran Benita <[email protected]> wrote:
> OK, so to refocus the issue:
>
> Using CSP nonces requires the following: any <script> tag (and optionally
> <style> tags, as well) must be annotated with a `nonce="NONCE"` attribute,
> where NONCE is a sever-generated random string, unique per request.
>
> The problem you run into in Django is that you do not control all the
> places that add <script> and <style> tags, 3rd party apps add those
> regularly, and it is not reasonable to ask all of them to depend and
> standardize on some common "csp tokens" package.
>
> The first part I think Django should be involved in in generating the
> nonce (a simple base64(os.random(16)) and making it available from the
> request object. Doing this in SecurityMiddleware sounds natural. This way,
> 3rd-party middleware can construct the CSP header using it, and templates
> can annotate the tags with it.
>
> The second part is annotating the tag:
>
> One way you might think to solve this is to somehow auto-annotate any
> <script> and <style> tag. This is not the approach I would take, because:
>
> 1. I'm not sure if it's technically possible in Django's template system.
> 2. Definitely implicit "magic" which is better avoided.
> 3. Not sure that it's desirable from a security viewpoint; adding csp
> tokens should maybe be a conscious choice.
>
> I should not though, that this is the approach taken by Google in their
> template system: https://developers.google.com/closure/templates/docs/
> security#content_security_policy
>
> The explicit way would be to add a `{% csp_nonce %}` template tag, which
> expands to `nonce=NONCE` if SecurityMiddleware if a nonce is available
> (SecurityMiddleware is enabled), and to nothing otherwise. Apps will need
> to annotate their tags with it, similarly to how `{% csrf_token %}` is used.
>
> Does this sound acceptable? If we can decide on an approach I will be
> happy to try and implement it. I'm sure projects like django-csp and
> https://github.com/Bennyoak/django-csp-nonce will be happy to have it as
> well.
>
> Ran
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/0c5df40b-f325-4327-9fa5-
> 616d71dfd499%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/0c5df40b-f325-4327-9fa5-616d71dfd499%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
--
Adam
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAMyDDM2LtRx%3DxEmbxxcVGThTOmc8-84eDk-ogfup-RfdGx0s7A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
