Add documentation to address OWASP Top 10?

[Tim Graham]

From a Trac ticket [0]: "Using incremental URLs (i.e. /comment/1 is the first comment and /comment/2 is the second comment, respectively for base 64 or other counting systems) is highly dangerous for private information. You could simply get all of the, say, private comments by accessing all comments sequentially and picking out the ones that are private. This can apply to confidential files (link sharing), personal information and more. There should be a section in the "Security in Django" about this."

Currently, the "Security in Django" document [1] says "This document is an overview of Django’s security features". I don't feel that addressing this concern, e.g. by using a randomly generated CharField or UUIDField primary key, would be considered a "security feature." Perhaps it would be worth creating a document that goes point by point through the OWASP Top 10 similar to this blog post [2] where something like this could be addressed. I know there have been some conferences talks addressing how Django address the OWASP Top 10 as well [3,4]. What do you think?

[0] https://code.djangoproject.com/ticket/26464
[1] https://docs.djangoproject.com/en/dev/topics/security/
[2] http://blog.mikeleone.com/2011/10/security-django-and-owasp-top-10.html
[3] Florian at Django Under the Hood 2015: https://opbeat.com/events/duth/
[4] Jacob at Pycon Australia 2013: https://www.youtube.com/watch?v=sra9x44lXgU

[Josh Smeaton]

I like the idea of addressing the OWASP top 10. Further, I think the advice of obscuring keys is wrong. The problem is actually addressed in the OWASP Top 10[0]

4 Insecure Direct Object References:

A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key. Without an access control check or other protection, attackers can manipulate these references to access unauthorized data.

The proper solution is *Access Controls* like the Permissions system provides. If you're going to rely on obscurity (one time file downloads for example), then you want to do so with a UUID or some kind of cryptohash (I haven't verified the particulars, don't take my this comment as security advice). That's not appropriate for something like a comments system.

[0] https://www.owasp.org/index.php/Top10#OWASP_Top_10_for_2013

[Anssi Kääriäinen]

It is notable that if the number of items is a secret (say, you don't
want to reveal how many sales items you have), just having information
about sequential numbers is bad. In that case you should use UUID,
which the documentation could point out.

> --
> 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 django-develop...@googlegroups.com.
> To post to this group, send email to django-d...@googlegroups.com.
> 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/0ca48548-6c6f-4d80-b166-ff49487ff3cb%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

[Aymeric Augustin]

That was my thinking as well.

This is a basic topic when it comes to web security. We can point to the OWASP 10 but I don’t think it’s reasonable cram a complete course about web security into Django’s documentation, let alone maintain it. Django’s docs will never contain everything one may need to know to write any project that may take advantage of Django.

-- 

Aymeric.

[Curtis Maloney]

On 06/04/16 11:35, Josh Smeaton wrote:
> I like the idea of addressing the OWASP top 10. Further, I think the
> advice of obscuring keys is wrong. The problem is actually addressed in
> the OWASP Top 10[0]
>

> *4 Insecure Direct Object References:*

> A direct object reference occurs when a developer exposes a reference to

> an internal implementation object, such as a file, directory, */or
> database key/*. Without an access control check or other protection,

> attackers can manipulate these references to access unauthorized data.
>
> The proper solution is *Access Controls* like the Permissions system
> provides.

Exactly... or just filtering the queryset according to the logged in
User, and returning a 404 otherwise -- get_object_or_404 can make this
trivial...

(yes 404, as 403 potentially admits the existence of the record in
question -- see GitHub's behavior)

--
Curtis

[Erik Cederstrand]

> Den 6. apr. 2016 kl. 07.29 skrev Anssi Kääriäinen <akaa...@gmail.com>:
>
> It is notable that if the number of items is a secret (say, you don't
> want to reveal how many sales items you have), just having information
> about sequential numbers is bad. In that case you should use UUID,
> which the documentation could point out.

If anything about your data is sensitive, then there are a pile of side channels that putting your data online could expose. URLs are just one. For an entertaining read, google "German tank problem".

Giving specific security advice in the documentation that doesn't strictly refer to Django features could IMO lead to the false expectation that you're magically secure if you follow the advice. I would prefer that the documentation simply pointed to further reading, e.g. OWASP.

Erik

[Tim Graham]

Proposed text:

Take a look at the Open Web Application Security Project (OWASP) Top 10 list which identifies some common vulnerabilities in web applications. While Django has tools to address some of the issues, other issues must be accounted for in the design of your project.

(linked to https://www.owasp.org/index.php/Top_10_2013-Top_10)

https://github.com/django/django/pull/6425