In the previous post, XSS using Facebook, Twitter open API, I mentioned that open API could be used to XSS on consumer’s web page. But, some people misunderstood it and they asked about it, It is not working on Facebook page, it is working on consumer’s page developed by open API. I posted it to show the bad case of open API and to demonstrate that it can be a threat of service providers and users.
And API were not completely opened to XSS, Service provider’s have adopted the permission model, that separate out each feature based on each permission. A user need to confirm the permission permit at the first access via each feature like login, feed, like and others. (http://developers.facebook.com/docs/reference/login/#permissions)
But, if a user already permitted the permission of features that the attacker want to use, there is no permission message. So, these status and other information are need to make a payload. It is similar with the development app using API.
I give an example Facebook APIs, but other service providers adopted similar API structures and features. And the effect of XSS is depend on the consumer’s circumstance, but it can be a threat on some environments. The key factor is that many consumer’s pages are not secure to protect from XSS. They should audit their pages and hide the app secret and only grant the minimum permissions.