I strongly disagree with this. Publishing record IDs does not imply indirect object reference vulnerability. Any application that publishes record information must have a way to reference individual records. If the individual access is not validated than the app is vulnerable to indirect object reference, whether or not the reference is done by id or not.
Who can access what is a matter of policy and policy must be implemented by the developer. Web2py provides the @auth.requires_permission and @auth.requires_membership and $auth.requires_signature. Massimo On Friday, 7 September 2012 09:22:12 UTC-5, MichaelF wrote: > > I appreciate that web2py has ways to handle this, and I also agree that > it's somewhat hackish. The problem remains, though, that we're still > exposing (publishing) internal primary keys to the browser. Isn't the main > problem the fact that we're dealing with primary key values being sent to > the browser? Look at https://www.owasp.org/index.php/Top_10_2010-A4 for > one description of the vulnerability. > > In our php application we wrote a class that hashed primary keys sent to > the browser, giving different hashes on each GET/POST so that, for example, > the hashed primary key 1 would different if the user visited the same page > two times. > > Thoughts? > > Thanks. > > On Thursday, September 6, 2012 8:18:44 AM UTC-6, Anthony wrote: >> >> How about http://web2py.com/books/default/chapter/29/06#Common-filters >> or >> http://web2py.com/books/default/chapter/29/06#Common-fields-and-multi-tenancy >> ? >> >> Anthony >> >> On Wednesday, September 5, 2012 8:48:49 PM UTC-4, Kevin C wrote: >>> >>> We did something similar but it feels very hackish, considering it has >>> to be done in every method of the admin controller. I just wanted to see >>> if there was a better way. >>> >>> Thank you. >>> >>> Kevin Cackler >>> Tech Daddies >>> 501-205-1512http://www.techdaddies.com >>> >>> On 9/5/2012 7:45 PM, Bruno Rocha wrote: >>> >>> You can do: >>> >>> if request.args(0) in ['edit', 'delete']: >>> STORE_DETAILS.id == int(request.args(2)) or >>> redirect(URL('default', 'wherever')) >>> >>> db.pages.stores_id.default = STORE_DETAILS.id >>> query = ((db.pages.stores_id == STORE_DETAILS.id)) >>> form = SQLFORM.grid(query=query) >>> >>> return dict(form=form) >>> >>> >>> >>> On Wed, Sep 5, 2012 at 9:38 PM, Kevin C <ke...@techdaddies.com> wrote: >>> >>>> Basically, we are generating a SQLFORM.grid with the following code: >>>> >>>> db.pages.stores_id.default = STORE_DETAILS.id >>>> query = ((db.pages.stores_id == STORE_DETAILS.id)) >>>> form = SQLFORM.grid(query=query) >>>> >>>> return dict(form=form) >>>> >>>> This is working perfectly fine for us. However, we have noticed that >>>> if we just change the ID in the query string for the edit page, we are >>>> allowed to edit other store's entries. >>>> >>>> IE >>>> http://test.oursite.com/test/admin/pages/edit/pages/6?_signature=f8c5560743.<http://test.shofty.com/shofty/admin/pages/edit/pages/6?_signature=f8c55607435864253b5f5b37a6b7109956e4a8fa> >>>> .. >>>> >>>> What is the proper way to do this, then? The grid itself looks >>>> great, but just by changing the page ID in the URL, we are allowed to edit >>>> pages not belonging to us. I guess I was hoping that the query >>>> conditional >>>> would be passed to each function (add, edit, delete) but that obviously is >>>> not the case. Is multi-tenancy the solution to this issue or are we >>>> overlooking something simple? >>>> -- >>>> >>>> >>>> >>>> >>> >>> >>> -- >>> >>> >>> >>> >>> >>> --
