I don't think we should mark the ticket as closed since we want to merge
part of the open PR, the catch-all view.
On Fri, 8 Jan 2021 at 17:24, Markus Holtermann
wrote:
> Thanks you for bringing this up, Carlton. And thanks Jon for tackling the
> issues.
>
> I concur with what has been said so
Thanks you for bringing this up, Carlton. And thanks Jon for tackling the
issues.
I concur with what has been said so far. Especially what James said, that there
are so many places where one possibly/maybe/theoretically could come up with
timing attacks. Mitigating the difference in response
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
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
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
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
I agree with James, this is going down something of a rabbit hole of micro
security holes within the trusted area of the admin.
There is also lower hanging fruit in the realm of admin security. For
instance geodjango's admin extensions rely on external scripts and are not
compatible with a strict
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
As a non-technical board member, I'd prefer option 1. I also think that for
most use cases, staff users are at least somewhat trusted and even if they
are not, model enumeration isn't likely to be a security problem.
On Wednesday, January 6, 2021 at 5:07:44 AM UTC-5 carlton...@gmail.com
wrote:
Hi Uri.
Can I please ask that this discussion not get side-tracked.
I'm asking for a Technical Board decision on the specific question, under
the rules of DEP 10.
The PR in question has been in progress for six months, and we want to
resolve it in time for the Django 3.2 feature freeze
Hi,
For security reasons, I would recommend protecting any url which starts
with /admin/ (or the website's admin url prefix) with an HTTPS password
from the web server directly (such as Nginx or Apache), so that even the
login to the admin will be protected. You may consider adding this
11 matches
Mail list logo
