Re: Technical Board Decision Needed: Admin append_slash behaviour.
On Thursday, January 7, 2021 at 2:16:57 PM UTC+1 carlton...@gmail.com wrote: > 1. Add the catch-all view to admin to stop the unauthenticated probing, as > per the Security Teams initial idea, but not the AdminSite.append_slash > option. > 2. Don't even add the catch-all, and close the ticket as wontfix. > I think the catch-all view is certainly a worthwhile addition, it is a low hanging fruit that makes fast probing if auth.user is installed impossible. * It SEEMS to me that the catch-all view does serve it's purpose as as the > AdminSite.admin_view decorator redirects all non-staff requests equally to > login (whether they exist or not, because the catch-all view exists.) This > is prior to any per-view timing variation. (I think 🙂) Technically you could already mount a timing attack because url resolving is not constant time, the first matching view wins :þ Cheers, Florian -- 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/03910826-32d4-44c9-a3d5-a35f984c05e7n%40googlegroups.com.
Re: Technical Board Decision Needed: Admin append_slash behaviour.
I wouldn't object to a wontfix. It seems like we've already spent a lot of effort here for little benefit, if any. On Thursday, January 7, 2021 at 8:16:57 AM UTC-5 carlton...@gmail.com wrote: > OK, thanks all. So... > > Two new options then: > > 1. Add the catch-all view to admin to stop the unauthenticated probing, as > per the Security Teams initial idea, but not the AdminSite.append_slash > option. > 2. Don't even add the catch-all, and close the ticket as wontfix. > > A site concerned here still has the middleware option with 2, but I > imagine Jon arguing whether this is sufficiently secure by default. > > Additional points: > > * Middleware option did come up in the original discussion and on the PR. > * It SEEMS to me that the catch-all view does serve it's purpose as as the > AdminSite.admin_view decorator redirects all non-staff requests equally to > login (whether they exist or not, because the catch-all view exists.) This > is prior to any per-view timing variation. (I think 🙂) > * So I'd say Option 1 here — I'll adjust the PR on that basis, but if you > conclude that actually Option 2, do say. > > Thanks again. This has been a difficult issue to think about and deal > with, and I do appreciate the input and guidance. > > Kind Regards, > > Carlton > > -- 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/836bbb46-0009-4e03-9a02-b9263800eafan%40googlegroups.com.
Re: Technical Board Decision Needed: Admin append_slash behaviour.
OK, thanks all. So... Two new options then: 1. Add the catch-all view to admin to stop the unauthenticated probing, as per the Security Teams initial idea, but not the AdminSite.append_slash option. 2. Don't even add the catch-all, and close the ticket as wontfix. A site concerned here still has the middleware option with 2, but I imagine Jon arguing whether this is sufficiently secure by default. Additional points: * Middleware option did come up in the original discussion and on the PR. * It SEEMS to me that the catch-all view does serve it's purpose as as the AdminSite.admin_view decorator redirects all non-staff requests equally to login (whether they exist or not, because the catch-all view exists.) This is prior to any per-view timing variation. (I think 🙂) * So I'd say Option 1 here — I'll adjust the PR on that basis, but if you conclude that actually Option 2, do say. Thanks again. This has been a difficult issue to think about and deal with, and I do appreciate the input and guidance. Kind Regards, Carlton -- 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/92e544bc-3406-41da-b694-9f16b0db6b40n%40googlegroups.com.
