Comments on: Social Security 102: Client-Side Code http://theharmonyguy.com/2008/02/11/social-security-102-client-side-code/ Investigating privacy and security issues in online social networking Wed, 28 Jul 2010 21:02:56 +0000 hourly 1 http://wordpress.org/?v=abc By: Alex Barrera http://theharmonyguy.com/2008/02/11/social-security-102-client-side-code/comment-page-1/#comment-97 Alex Barrera Wed, 13 Feb 2008 00:19:40 +0000 http://theharmonyguy.com/2008/02/11/social-security-102-client-side-code/#comment-97 Hi, You rise a very good question. Coming from the security industry myself, I know how you feel about these issues. There is a rule of thumb, and not very hard to follow, all security checks, input validations and alike MUST be done server-side, dot. Any check you do on the client is susceptible to an attack. All inputs going to the server, even then ones generated by the client side js MUST be checked as they might be altered. And you don't have to have Opera or a FF addon, it's as simple as downloading the website, opening the js file with a text editor and resend the form/post/ajax call. Nice post! Keep the good work! Hi,
You rise a very good question. Coming from the security industry myself, I know how you feel about these issues. There is a rule of thumb, and not very hard to follow, all security checks, input validations and alike MUST be done server-side, dot. Any check you do on the client is susceptible to an attack. All inputs going to the server, even then ones generated by the client side js MUST be checked as they might be altered.

And you don’t have to have Opera or a FF addon, it’s as simple as downloading the website, opening the js file with a text editor and resend the form/post/ajax call.

Nice post! Keep the good work!

]]> By: theharmonyguy http://theharmonyguy.com/2008/02/11/social-security-102-client-side-code/comment-page-1/#comment-89 theharmonyguy Mon, 11 Feb 2008 21:39:33 +0000 http://theharmonyguy.com/2008/02/11/social-security-102-client-side-code/#comment-89 Thanks for the comment, Patrick. My main concern with OpenSocial applications is not so much the security of OS requests made to the host social network for information (I've noticed some of the improved security in 0.7), but rather pieces of code that send/retrieve data to/from third-party servers. For instance, while iLike would get user credentials from Ning or Orkut, the playlist data was stored on iLike's servers. This is precisely the nature of the Top Friends hack - I'm able to retrieve data that Slide has stored about other users, and since that data isn't coming from Facebook, I don't have to spoof Facebook user credentials. Granted, Top Friends is a Facebook application, but the point is that any JavaScript-based application is susceptible to this problem. By mentioning my particular concern over OpenSocial applications I wasn't implying that the platform is less secure than others, simply that its reliance on JavaScript may lead to more application holes than server-side solutions, such as processed FBML applications. Thanks for the comment, Patrick. My main concern with OpenSocial applications is not so much the security of OS requests made to the host social network for information (I’ve noticed some of the improved security in 0.7), but rather pieces of code that send/retrieve data to/from third-party servers.

For instance, while iLike would get user credentials from Ning or Orkut, the playlist data was stored on iLike’s servers. This is precisely the nature of the Top Friends hack – I’m able to retrieve data that Slide has stored about other users, and since that data isn’t coming from Facebook, I don’t have to spoof Facebook user credentials.

Granted, Top Friends is a Facebook application, but the point is that any JavaScript-based application is susceptible to this problem. By mentioning my particular concern over OpenSocial applications I wasn’t implying that the platform is less secure than others, simply that its reliance on JavaScript may lead to more application holes than server-side solutions, such as processed FBML applications.

]]> By: Patrick Chanezon http://theharmonyguy.com/2008/02/11/social-security-102-client-side-code/comment-page-1/#comment-88 Patrick Chanezon Mon, 11 Feb 2008 21:26:04 +0000 http://theharmonyguy.com/2008/02/11/social-security-102-client-side-code/#comment-88 Thanks for testing OpenSocial security. In OpenSocial 0.5 there was no security at all, one of the reasons why it was only a developer release. In 0.7 which is the version that will go live there is much more security baked into in the specification. The fact that makeRequest http://code.google.com/apis/gadgets/docs/reference/gadgets.io.html#makeRequest in OpenSocial 0.7 allows for signed and authentified calls makes these applications more secure. Also Caja http://opensocialapis.blogspot.com/2008/01/six-apart-hackathon-wrap-up-and-caja.html will constrain the javascript executed on the client side: it is not a mandatory aspect of OpenSocial but it is recommended for containers to use, and MySpace and Orkut will use it. Please chime in the forum if you find holes. http://groups.google.com/group/opensocial P@ OpenSocial API Evangelist Thanks for testing OpenSocial security.
In OpenSocial 0.5 there was no security at all, one of the reasons why it was only a developer release.

In 0.7 which is the version that will go live there is much more security baked into in the specification.

The fact that makeRequest http://code.google.com/apis/gadgets/docs/reference/gadgets.io.html#makeRequest in OpenSocial 0.7 allows for signed and authentified calls makes these applications more secure.
Also Caja http://opensocialapis.blogspot.com/2008/01/six-apart-hackathon-wrap-up-and-caja.html will constrain the javascript executed on the client side: it is not a mandatory aspect of OpenSocial but it is recommended for containers to use, and MySpace and Orkut will use it.

Please chime in the forum if you find holes.
http://groups.google.com/group/opensocial

P@
OpenSocial API Evangelist

]]>