[thelist] Link security and performance

[Lee Kowalkowski]

On 4 February 2010 15:17, Bill Moseley <moseley at hank.org> wrote:
> I have not had much time (or luck) reverse-engineering Gmail,

Reverse engineer the basic HTML view if you want to make it easier for yourself!

> but I have
> often wondered about their links.  Selecting a message and deleting it seems
> to send somewhat abstract IDs back in the AJAX post.

Yeah, I thought this was deliberate to make is harder to script their
interface.  To reduce spam?  Just guessing... I noticed the field
names on the forms are dynamic, I cannot fathom another reason for
doing this.

> So, I was wondering if
> those links contain just the message ID or if they also include access and
> ownership.  How does Gmail prevent me from modifying that request and
> deleting another message I don't own, for example?

Authentication & validation I presume, this is done using cookies as
far as I can tell.

> I'm not so interested in Gmail details, but of building links with security
> built-in.

Session cookie based authentication is the traditional way of doing this.

> I often have the situation where I send a list of objects the user owns or
> has control over back to the client.  Then in another request the user may
> ask to delete one of those things.  In some applications it may be very
> expensive (slow) to check all the permissions and ownership on the object
> that is requested to be deleted.  Plus, when that object was provided to the
> user in the first place all those checks were already done.

It might be more expensive and slower, but it's necessary isn't it?
If the expense or speed is a problem, that's just something you'll
need to work at.  Perhaps a little restructuring or something.

> I've done something similar in the past.  For example, I have a page that is
> very expensive to generate but has lots of links to do small actions.  When
> the request come in for those small actions I need to make sure that it's a
> valid action for that specific page w/o having to do the expensive part of
> basically rebuilding the page to know what links are available.

It shouldn't really matter what links were available to the user.
It's the actions that need protecting.

> In that case I built normal links (with query parameters) but also included
> a hash of the parameters along with their session ID and a secret.  That way
> when I receive the request I can validate that it's not been tampered with
> and it is a valid link created for the specific page.

That does sound like it might work, but doesn't sound necessary.  REST
APIs don't do this when authentication or authorisation is involved.

> I'm now building out a much more complex application that's all about
> managing "objects" -- where each object has ownership and permissions.  It's
> mostly CRUD so what I'm thinking is a system where I don't pass object IDs
> between the client and server but a more complex "ID" that when I get a
> request to delete the object I know right away that the user can do that
> action just by looking at this "ID" in the passed-in request.  The hope is
> that I can simplify my model code (specifically the complex database read
> and joins) and make the AJAX updates much simpler.
>
> Anyone done something like this?  I guess what it boils down to is a system
> to convert my primary keys into a tamper-proof ID that carries permissions
> and ownership -- or maybe carries the key, the sesssion, and permissions.

I don't see the problem with just having an authentication token
(usually in a session cookie) and doing the rest of the processing on
the server.  You can derive the user's primary key without ever
requiring the client to provide it (if User ID and user's primary key
are separated).  Then the rest is all down to granularity (e.g.
whether you're putting users into groups, and whether you assign roles
to users or groups).

> Yes, there's some problems with this -- e.g. if permissions change on an
> object and the user tries to use an old link.

Yes, depends on the likelihood of bookmarking or browser-back usage if
within the same session.

-- 
Lee
www.webdeavour.co.uk