Path's and security

Using Django Forms & APIs
1

I am getting familiar with the path system of Django. I was wondering is there no risk for security issues showing the ID in the path? EG ‘http://127.0.0.1:8000/shift_info/5/’
It is easy to manipulate the path and see an other shift by changing the ID in the browser.

2

I’m not expert on this topic, just my basic understanding:
security is not build on top of URL path. If a user has permission on both shift 5 and 7, definitly he/she can view the other by just changing the path. But you can set user permission only has 5, but not 7. In that case, even if he/she change the path to 7, he still doesn’t have the permission, and the access will fail.

3

@perry7t - zejiang is correct.

If you need to secure access to shift information, then that is something you do in the view by verifying that the user has access to the shift being requested.

You must always validate data coming from the browser, and that includes URL parameters. You must never trust what you get from the browser - all data is subject to being altered at the far end, and that even includes things like selections in drop-down lists. (Fortunately, Django does what it can to help.)

4

Yes. You always need to think about checking for permission.

Here’s an example of adding a simple permission check to a Django class view (from my product Amazing.photos). See the LoginRequiredMixin:

class Home(LoginRequiredMixin, TemplateView):
    login_url = '/'
    redirect_field_name = ''
    template_name = 'home.html'

    def get_context_data(self, **kwargs):
        context = super().get_context_data(**kwargs)
        context["products"] = self.get_offered_products_data()
        return context

And here’s a more explicit permissions check in a function view:

from django.contrib.auth.decorators import login_required
from django.shortcuts import render
from django.http import HttpResponseForbidden

def home(request):
    if not request.user.is_authenticated:
        return HttpResponseForbidden("You do not have permission to view this page.")
    
    context = {
        "products": get_offered_products_data(),
    }
    
    return render(request, 'home.html', context)

Hope that’s helpful @perry7t !

5

There’s an OWASP guide that references this:

The potential issue is that sequential IDs allow you to guess URLs, and so attempt an enumeration attack.

Note though:

IDOR does not create a direct security issue itself … To be exploited, an IDOR issue must be combined with an Access Control issue, because it’s the Access Control issue that “allows” the attacker to access the object for which they have guessed the identifier through the enumeration attack.

This is what @KenWhitesell said: apply access controls to your endpoints.

Depends on your threat model… — for many apps it probably doesn’t matter if IDs are guessable (because, e.g. you need to be auth’d to see any URL, so only already trusted users could enumerate them…)

If you are concerned, you can use a non-sequential identifier in the URL. (There are many options here. I quite like Hash IDs — which map from sequential IDs to short non-enumerable strings.) Even with such URLs you still need access controls, since URLs are shared in too many places to be considered secure just via obscurity.

HTH.