Is it secure to have IDs show up in URLs?
Bastien
Is it a good idea to try to change this behavior? Maybe with some sort of middleware? Is there any project doing it already? For instance the urls in Instagram seem to be encoded at least.
Vovk Donets
I am concerned about seeing the IDs of objects appearing in the URL and in a totally predictable manner. It is very convenient and clean to do all sorts of things but can be abused very easily to retrieve all the content of the site, ie: photos...
Is it a good idea to try to change this behavior? Maybe with some sort of middleware? Is there any project doing it already? For instance the urls in Instagram seem to be encoded at least.
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/UBBLhaPnHf4J.
To post to this group, send email to django...@googlegroups.com.
To unsubscribe from this group, send email to django-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
--
Vovk Donets
python developer
Bastian Ballmann
it's the task of the backend to manage the authorization including
users and permissions.
If the view and permission system allows all users to see everything
and you dont want it that way than you have to check permission in your
views.
See https://docs.djangoproject.com/en/1.3/topics/auth/
This has nothing to do with having the id in the url or not cause
hiding the id wont help you get a more secure system if your auth
backend is crappy. Security by obscurity doesnt work.
HTH && Greets
Basti
Am Fri, 23 Mar 2012 04:06:45 -0700 (PDT)
schrieb Bastien <bastien....@gmail.com>:
--
Bastian Ballmann / Web Developer
Notch Interactive GmbH / Badenerstrasse 571 / 8048 Zürich
Phone +41 43 818 20 91 / www.notch-interactive.com
Bastien
For instance if we talk about photos, publicly available, the url would look something like /photos/1, /photos/2 .... 1 and 2 being the pk of the object in the db. If someone wants to download or link to these photos in a totally uncontrollable way (without using an API), with that system we are making it very easy to do mass content leakage. I don't want to promote security by obscurity here, just want to know what people in the group think about it and what solutions can be implemented, or if it is relevant at all.
The idea of slug could do the trick, but wouldn't it require some sort of date or title or a combination of both in the url? Not the most convenient in this case.
On Friday, March 23, 2012 12:17:02 PM UTC+1, Bastian Ballmann wrote:
Hi Bastien,it's the task of the backend to manage the authorization including
users and permissions.If the view and permission system allows all users to see everything
and you dont want it that way than you have to check permission in your
views.
See https://docs.djangoproject.com/en/1.3/topics/auth/This has nothing to do with having the id in the url or not cause
hiding the id wont help you get a more secure system if your auth
backend is crappy. Security by obscurity doesnt work.HTH && Greets
Basti
Am Fri, 23 Mar 2012 04:06:45 -0700 (PDT)
schrieb Bastien <>:
Brett Parker
> Sorry maybe my post was not very clear, I am talking about public content
> here, that should be accessed by anyone, even anonymous users not logged in.
> For instance if we talk about photos, publicly available, the url would
> look something like /photos/1, /photos/2 .... 1 and 2 being the pk of the
> object in the db. If someone wants to download or link to these photos in a
> totally uncontrollable way (without using an API), with that system we are
> making it very easy to do mass content leakage. I don't want to promote
> security by obscurity here, just want to know what people in the group
> think about it and what solutions can be implemented, or if it is relevant
> at all.
Are there links on the site to those bits of content, anyways? If so,
then this is entirely irrelevant, as they're already entirely
spidarable, and there's plenty of software out there that will parse web
pages and download all content, and follow links, etc.
Cheers,
--
Brett Parker
Tom Evans
> Sorry maybe my post was not very clear, I am talking about public content
> here, that should be accessed by anyone, even anonymous users not logged in.
> For instance if we talk about photos, publicly available, the url would look
> something like /photos/1, /photos/2 .... 1 and 2 being the pk of the object
> in the db. If someone wants to download or link to these photos in a totally
> uncontrollable way (without using an API), with that system we are making it
> very easy to do mass content leakage. I don't want to promote security by
> obscurity here, just want to know what people in the group think about it
> and what solutions can be implemented, or if it is relevant at all.
>
> The idea of slug could do the trick, but wouldn't it require some sort of
> date or title or a combination of both in the url? Not the most convenient
> in this case.
>
If you are concerned about predictable URLs, then you could instead
add a random uuid for each object, use that as an db index and index
your URLs with the uuid.
Your uuid field could simply be a char field, or there are several
UUIDField implementations out there in the internet - ideally, you'd
be using postgres (which has a uuid field type), and it would get
stored as a 128 bit integer rather than a 36 character string.
Cheers
Tom
PS: This is the uuid field I use: https://github.com/dcramer/django-uuidfield
Tom Evans
You might have a page with links to '/photos/1' and '/photos/2'. You
don't want someone to try to download all the photos by guessing that
there may be content at '/photos/3' as well. Using non-predictable
URIs for resources allows you to control how and when a user is linked
to a resource.
Cheers
Tom
Brett Parker
*if* they wanted all the photos, then spidering the site isn't exactly
difficult, see wget -m. They'll end up with more than they need, but
it'll all be local, and it'd take them minutes to then just weed out the
photos - obscuring urls and using random ids just appears to be a waste
of time for public content.
--
Brett Parker
Tom Evans
<iDu...@sommitrealweird.co.uk> wrote:
> *if* they wanted all the photos, then spidering the site isn't exactly
> difficult, see wget -m.
You assume that all the content is indexed on the website. Consider a
press release model; you may have a 'published' flag on the
PressRelease model, so that a press release being prepared does not
appear in the list of press releases on the site.
The user uploads several images to include in the press release, the
images have commercially sensitive information in them that you can
only show after the release is published.
Should someone be able to get lucky and guess the ids of photos that
have not been included in a published release?
> They'll end up with more than they need, but
> it'll all be local, and it'd take them minutes to then just weed out the
> photos - obscuring urls and using random ids just appears to be a waste
> of time for public content.
>
It isn't obscuring the URI; it is making it non-predictable. There are
many occasions where generating non-predictable URIs is essential, and
assigning objects a UUID (also called a GUID) is extremely common, as
it gives a way of uniquely identifying arbitrary items.
Stuff like this seems pointless and arbitrary until it's not. Only the
OP knows his needs; if he needs non-predictable URIs, he needs
non-predictable URIs.
Cheers
Tom
Bastian Ballmann
complain about the matter that everyone can access everything?
Anyway for on any reason you want not so easy guessable links why not
use md5 or sha1 checksum in hex of the photo as link?
Greets
Basti
Am Fri, 23 Mar 2012 04:38:43 -0700 (PDT)
schrieb Bastien <bastien....@gmail.com>:
> Sorry maybe my post was not very clear, I am talking about public
> content here, that should be accessed by anyone, even anonymous users
> not logged in. For instance if we talk about photos, publicly
> available, the url would look something
> like /photos/1, /photos/2 .... 1 and 2 being the pk of the object in
> the db. If someone wants to download or link to these photos in a
> totally uncontrollable way (without using an API), with that system
> we are making it very easy to do mass content leakage. I don't want
> to promote security by obscurity here, just want to know what people
> in the group think about it and what solutions can be implemented, or
> if it is relevant at all.
>
> The idea of slug could do the trick, but wouldn't it require some
> sort of date or title or a combination of both in the url? Not the
> most convenient in this case.
>
> On Friday, March 23, 2012 12:17:02 PM UTC+1, Bastian Ballmann wrote:
> >
> > Hi Bastien,
> >
> > it's the task of the backend to manage the authorization including
> > users and permissions.
> >
> > If the view and permission system allows all users to see everything
> > and you dont want it that way than you have to check permission in
> > your views.
> > See
> > https://docs.djangoproject.com/en/1.3/topics/auth/<https://docs.djangoproject.com/en/1.3/topics/auth/>
Daniel Sokolowski
even a simple status fields with a live(...) objects manager would do the
trick better.
One can attempt guess and access the next sequence but it won't show. I
personally use status field on almost all my models and per object level on
sites with users. See https://github.com/lukaszb/django-guardian.
Sample model managers:
class ProductCategoryManager(models.Manager):
"""
Additional methods / constants to ProductCategory's objects manager:
``ProductCategoryManager.objects.active()`` - all active instances
"""
### Model (db table) wide constants - we put these and not in model
definition to avoid circular imports.
### One can access these constants through <foo>.objects.STATUS_DISABLED
or ImageManager.STATUS_DISABLED
STATUS_DISABLED = 0
STATUS_ENABLED = 100
STATUS_ARCHIVED = 500
STATUS_CHOICES = (
(STATUS_DISABLED, "Disabled"),
(STATUS_ENABLED, "Enabled"),
(STATUS_ARCHIVED, "Archived"),
)
# we keep status and filters naming a little different as
# it is not one-to-one mapping in all situations
def live(self):
""" Returns all entries accessible through front end site"""
return self.all().filter(status=self.STATUS_ENABLED)
def current(self):
""" Returns entries that are live and considered 'fresh' """
return self.all().filter(status=self.STATUS_ENABLED, ... date range,
other condition, etc)
def retired(self):
""" Returns entries that are live and considered 'old' """
return self.all().filter(status=self.STATUS_ARCHIVED)
Then you do ProdcutCategory.objects.live() , etc.
Cheers
Tom
--
You received this message because you are subscribed to the Google Groups
"Django users" group.