I think the issue is that if an attacker somehow determined that a third party server was accepting signed request calls but not actually performing validation on the parameters, the attacker could just forge an unsigned request with all the appropriate oauth_* and opensocial_* data (but an invalid signature) and request arbitrary data from the third party server.
Naturally, servers should always validate all signed data, but should shindig take the precaution of clearing all user-supplied opensocial_* querystring values from unsigned requests? ~Arne On Fri, Mar 7, 2008 at 10:33 AM, John Panzer <[EMAIL PROTECTED]> wrote: > The intent is that the container only provides signatures for opensocial_* > things it can vouch for. A container can't vouch for an arbitrary > parameter > sent from gadget JS, so that sounds like a bug. > > WRT the first question, wouldn't the 3rd party site need a signature in > order to trust the owner/viewer info? > > On Fri, Mar 7, 2008 at 10:16 AM, Chak Nanga <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > Need some clarification on what opensocial_* params, if any, the > > container/proxy is supposed to append to the outgoing URL in response to > > makeRequest(UNSIGNED) calls? If it does not append the owner/viewer id > > params to the outgoing UNSIGNED request, how does the 3rd party site > know > > the owner/viewer info if it needs to fetch user specific data? > > > > It¹s fairly clear that the proxy is supposed to add > > opensocial_owner/viewer/app_id params and oauth_* params. > > > > Also, I noticed that the current proxy code does not remove opensocial_* > > and > > oauth_* if they are present in the incoming makeRequest() calls. I can > > file > > a JIRA issue, if this is indeed a bug. > > > > Thanks > > Chak > > > > >
