Hello, If I'm not mistaken, middlewares are not aware of decorators, mixins applied on the request handlers. Therefore, if the middleware is turned on, there wouldn't be a way to selectively not enforce it. At least not with decorators/mixins.
The rest framework uses a global setting that applies default Authentication and Permissions classes on all views. something like that could be possible in core Django. On Sat, 14 Mar, 2020, 02:18 Mehmet Ince, <meh...@mehmetince.net> wrote: > Hi everyone, > > I've been working as a security researcher for a long time. Common mistake > that I've seen is forgotten decorator and/or Mixin usage on controllers, > which leads to OWASP A5 Broken_Access_Control[1]. I believe one of the most > important, as well as most used, decorator and/or Mixing in Django world is > @login_required. > > Instead of calling that decorator on every single function-based-view is > kind a against the DRY. Also even sometimes it's possible to forgot to call > decorator, which is scary. For class-based-view it's usually requires to > define an abstract controller class, where you call login_required > decorator with method_decorator on dispatch method[2]. Of course that > approach makes sense and looks like a proper design decision but it still > leaves some open doors. For instance, what would happen if new > contributor/developer in the team inherits TemplateView directly instead of > ProtectedView class ? etc etc etc. > > Since almost %90 of the endpoint of todays web application requires an > authentication -I'm not talking about authorization-, I believe we should > be writing code in order to make endpoint accessible by unauthenticated > request. > > So my proposal is very simple: > > - We must forcefully enable session validation for every endpoint. > - Developers must do something to make the unauthenticated endpoint > instead of making it authentication protected ! > - We should do this in middlewares. Because for my opinion, such as > validation and check should be done way before execution reaches to the > views. > > Technical implementation can be as follow: > > - You can enable it by adding 'forceauth.ForceAuthenticationMiddleware' > middleware. Otherwise Django can work as it. > - If you have a FBV, and it requires to be accessible for unauthenticated > users, call *@publicly_accessible_endpoint* decorator. > - If you have CBV, and it requires to be accessible for unauthenticated > users, inherit *PubliclyAccessibleEndpointMixin* along side other classes > that you need like TemplateView,ListView etc. > - All the other endpoints will be protected by authentication validation > on middleware. > > You can see my initial implementation at > https://github.com/mmetince/django-forceauth and read my all thoughts > regarding to the approach to the session validation at blog post [3]. > > [1] > https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top_10-2017_A5-Broken_Access_Control > [2] > https://docs.djangoproject.com/en/3.0/topics/class-based-views/intro/#decorating-the-class > [3] > https://pentest.blog/why-secure-design-matters-secure-approach-to-session-validation-on-modern-frameworks-django-solution/ > > PS: This is my first mail to Django mailing list, if it’s wrong place to > discuss such a ideas please let know where to do it properly :) > > -- > 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/F6FB68F9-9287-45BD-B3AD-F59C2B4E23F0%40mehmetince.net > <https://groups.google.com/d/msgid/django-developers/F6FB68F9-9287-45BD-B3AD-F59C2B4E23F0%40mehmetince.net?utm_medium=email&utm_source=footer> > . > -- 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/CAP1-YrprcKUmLYd3CJUVWJD22jOLHWR1rO3pVZGe601Bg9%2Bd8g%40mail.gmail.com.
