You could do a referrer check in the gadget rendering servlet and only accept requests from your domain ... but thats still not secure.
Another possibility would be to force the gadget developers to use a javascript function to redirect users to other domains via an iframe with a secure url 2009/5/13 Paul Lindner <[email protected]> > Moving the security token to the hash does not fix this problem. You will > still leak that information. > > There are other ways to fix/minimize this risk. HTML content rewriting can > force requests through a proxy. There is an auth-refresh feature that can > reset secure tokens. > > I don't think the problem is the application developer here -- they can get > anything on the iframe src param using plain javascript. Instead the risk > is that you have an application that allows an attacker to add arbitrary > content such as images that are then displayed on another user's > profile/canvas. > > An application would want to use the caja html sanitizer with a url policy > function. The policy could use a redirector or proxy to serve up content. > > I'd be interested in hearing what others think about this. > > > > On May 13, 2009, at 4:27 AM, Yoichiro Tanaka wrote: > > Hi folks, >> >> I'm Yoichiro Tanaka as an architect of mixi Platform in Japan. >> I report on a problem and a solution about a spoofing by Referer here: >> >> Phenomenon: >> >> If an user obtains a referer URL of an OpenSocial application, >> the user can use the application as other's account >> (= an application spoofing). >> >> Replicate: >> >> (1) An application developer writes a code for accessing to >> an external web server by using <img> or <a> tag in an content >> of an OpenSocial application. >> >> (2) The application is used by users on SNS. >> >> (3) The external web server is accessed from the application >> of the user on user's browser by pressing the link or >> displaying the image. >> >> (4) As a result of accessing to the external server, an iframe's >> src URL for the application is written in an access log of the >> external web server as Referer. >> >> (5) The external web server's owner or any users who can >> know the URL can use the application by using the Referer >> URL as the user specified by a security token included >> in the URL. >> >> Cause: >> >> It is a cause that the st parameter is included in the src >> attribute value of iframe. >> >> Risks: >> >> The user's individual information can be acquired by spoofing >> as other users and using the application with the referer URL. >> >> React: >> >> It is a problem that the st parameter with the authentication >> information is included in Referer. If the st parameter is >> excluded from URL recorded as Referer, the spoofing can >> be prevented. >> >> Therefore, it is better that the Security Token value is passed >> as URL Fragment. >> >> NG: http://.../...?st=abcdefg&;... >> OK: http://.../...?...#st=abcdefg >> >> When main browsers transmits URL to the request header >> as Referer, URL Fragment is not sent. Because the st >> parameter comes to never include Referer that remains >> in the access log of external Web server, the spoofing can >> be prevented. >> >> Can anyone mention or advice about this? >> >> Thanks, >> -Yoichiro >> >> -- >> Yoichiro Tanaka >> Email: [email protected] >> Blog: http://www.eisbahn.jp/yoichiro >> > >
