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 
<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
 
<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
 
<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/
 
<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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/F6FB68F9-9287-45BD-B3AD-F59C2B4E23F0%40mehmetince.net.

Attachment: signature.asc
Description: Message signed with OpenPGP

Reply via email to