I agree with this especially around the point about timing attacks. I don’t believe potentially being able to infer the names of models in a very, very noisy way (thousands of requests) gives anyone leverage in a system or even any particularly sensitive information at all. Maybe in a really extreme scenario involving other issues within an app like some form of blind class-based direct object access vulnerability, but that’s really stretching the imagination.
If I had to pick I would say 1, but it still leaves open timing attacks as I’d expect the permission check path would take an order of magnitude longer than the fast “404 but not really” path. So it begs the question “do we really want to?” Tom > On 6 Jan 2021, at 13:20, James Bennett <ubernost...@gmail.com> wrote: > > I'm going to be the contrarian here and at least ask whether the right answer > is "don't do any of these options". > > To see why, consider a hypothetical world where we do one of the above > options, and a site sets whatever config is necessary to disable APPEND_SLASH > behavior in the admin. > > The very next thing we're going to get is a report to the security address > saying there's a detectable timing difference between what we do to hide a > real app/model from a user with admin-access-but-not-to-that-model/app, and > what we do when that app/model genuinely doesn't exist, and in order to > properly hide apps/models could we please address that? > > (and if we do end up taking one of the above options, please consider this my > report of this vulnerability, as I can pretty much guarantee that 404'ing a > nonexistent app/model will be faster than finding it, resolving a URL into > it, and doing the associated permission check) > > And this will never end. For a user who already has been granted admin > access, there likely *always* will be some detectable difference between the > admin's behavior with respect to a model/app that isn't present versus one > that is present but for which the user is not authorized. In an app with the > complexity of the admin, there are just too many possible > behavioral-difference vectors that people will be able to come up with, and > we'll never be able to close them all reliably. > > So what I'd really like us to do here is pause and consider what kinds of > guarantees we can really commit to. Some are obvious and good and we already > do or try to do them -- you shouldn't be able to access/modify/delete things > you haven't been granted access to, you shouldn't be able to escalate your > own privileges, you shouldn't be able to XSS the admin, etc. > > But it's not at all clear to me that "the existence or nonexistence of > apps/models to which they don't have access is undetectable to an admin user" > is one of the guarantees the admin should make. I understand the rationale, > but I'm not sure the threat it wants to be securing against is one we > reasonably *can* secure against. > -- > 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-developers+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/CAL13Cg_1QRhht3eSD29AJ25Cbkp%2BfbCxyOi7GdhYpfzcEkmDbQ%40mail.gmail.com. -- 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-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/827E088B-21AE-4B02-8BB7-6A6065414045%40tomforb.es.
