Hi James, Good questions. Answers inline.
On Thu, Feb 18, 2010 at 2:08 AM, James Ashley <james.ash...@gmail.com>wrote: > 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 > <ryanb+appeng...@google.com<ryanb%2bappeng...@google.com>> > wrote: > > > > On Feb 16, 8:46 am, "Nick Johnson (Google)" <nick.john...@google.com> > > 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. > In this situation, the original query, and the one resumed from the cursor, should contain a filter on the ID of the currently logged in user. When the wife logs in, that filter is different, so the cursor won't point to a valid location in her result set - so it'll return all her own results, or none of them, but not her husband's results. > 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. > In this case, the rest of the query information (eg, the user sharing the data) needs to be included in the query string, so the app can again construct the same query before calling .with_cursor() on it. > 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. > As above, for a cursor to work, the query he takes advantage of must already be capable of selecting the records that he wants to see - otherwise either nothing or the regular results will be returned. Think of a cursor as being the key of the first result to pick up a query from - it's meaningless unless it's applied to the same query it was originally generated from. If you try and apply it to a query that it wasn't generated from, it'll either give an error outright, or affect the results in an unpredictable manner - but it'll never cause the query to return results it couldn't have on its own. -Nick Johnson > 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 google-appeng...@googlegroups.com. > To unsubscribe from this group, send email to > google-appengine+unsubscr...@googlegroups.com<google-appengine%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/google-appengine?hl=en. > > -- Nick Johnson, Developer Programs Engineer, App Engine Google Ireland Ltd. :: Registered in Dublin, Ireland, Registration Number: 368047 -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appeng...@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
