I don't have time to test this just now, and I hate to waste bandwidth on what (so far) is just idle speculation, but I did spot what looks like a potential security. I figured it'd be better to share it with the group than sit on it until I actually *do* have time to confirm/ deny.
On Feb 16, 11:30 pm, ryan <[email protected]> wrote: > > On Feb 16, 8:46 am, "Nick Johnson (Google)" <[email protected]> > wrote: > > > As you point out, in order to use a cursor, you still have to > > reconstruct the original query, so a user could not modify a cursor to cause > > you to display records they should not have access to. > > +1. this is important. Very much agreed. This seems almost like it might be a reason to not pass cursors around "in the clear." > > It contains the complete key of the next record to be returned, along with > > some extra information about the query. Feel free to experiment and see for > > yourself, of course. :) > > specifically, the "extra information" is your app id and the kinds and > some property values, and possibly also property names, of one or more > entities that were query results. the specific properties involved are > the properties in the query. This is where I had my "Wait, that sounds wrong" moment. You didn't mention anything about the currently logged in user. Off the top of my head, I can think of 2 mutually exclusive scenarios. They both assume a page requires the user to be logged in, the original query used the login ID as part of the WHERE clause, and there's a cursor to page through results. 1) The user has a bunch of personal...whatever. Bookmarks that he doesn't want to share with his wife. The original query is tied to his google account. He stashes a browser bookmark halfway through the list and logs out of the site. Later, his wife uses the same computer and logs in and checks out the new bookmarks. This one requires her to log into her google account. From what I'm reading, it sounds like she'll see his data. 2) The user has a query that she wants to share. So sends some sort of private site-specific message to one of her friends. In this case, we want the cursor to maintain its original set of results, ignoring the currently logged in user. And we want the friend to be able to access that query from a completely different part of the site. I'm guessing it doesn't check to see if the current user "owns" that query. In many cases, it would be a waste of time to check. And, if we're using something besides the google user API, it would be a meaningless check. Another possibility that springs to mind: Mr. Cracker With Too Much Time On His Hands has a cursor with data he shouldn't see that belongs to, say, admin portions of the site. He browses the rest of your site, looking for anything else that uses cursors. He replaces those with this one. This one's probably just paranoia on my part. You did mention that cursors store Kind information. So (depending on how the API is implemented), if he happened to plug it into a page with models that had the same properties, it seems like a risk that duck-typing could work in his favor. I know I've written a few testing pages that are designed to dump the details of whichever models I happen to give them query descriptions for. They were always admin-only, and I haven't had one make it into production yet, but... I guess how dangerous this is depends totally on undocumented implementation details, and the individual app. But maybe the (hypothetical) user login issues are worth keeping in mind, I suppose they might suggest other gotchas to list members. Regards, James -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
