Sadly, you've discovered one of the major limitations of a client side
application - code that runs on a client can be modified by the client
to do anything and therefore cannot be trusted to always feed valid
information back to a third party server. Note that this is a
weakness of all client-side apps, even compiled executables are
vulnerable (people with reasonable debugging experience can modify
compiled programs). The normal advice given for this kind of thing is
for a server to validate all input, as even input from a client
program could be malicious (if you ever played Diablo 2 online, the
servers didn't validate the client input, so people had a fun time
hacking the program to give superpowers to their characters).
In the case of App Data, the server that the client sends input to is
the social network and therefore not under your control (you can't
upload validation code to the social network). All the social network
does is validate that the user is writing to their own data
(everything else is forbidden for this reason) but can't verify that
the high score that the user just stored in App Data is valid.
So the best advice I can give you is that for storing data that a user
may want to manipulate, you shouldn't use App Data. Instead, run your
own server (I like app engine, but any web server will do) and use
request validation code to obtain the ID of the user sending the
request. That way, you can perform validation on all input that is
sensitive to being manipulated.
For example, if a user is playing a flash space shooter game and the
enemy spaceships are worth 100 points each and the game renders one
spaceship a second, the highest score possible will be 100 times the
number of seconds the game has run. If a user plays for ten seconds
and reports a score of 1,000,000, you can reasonably throw that score
away because the user is obviously cheating. The user could figure
out your algorithm for reporting scores, but at least that's much less
likely than just writing an arbitrarily large number to your server.
If you're writing an app where you can validate each state of the app,
this approach is even better. Think about a chess app where the user
writes their move back to the server upon each turn- chess has very
well-defined rules, so you can verify whether the move is valid and
update the state on your server if it is. If you were using App Data,
you would have to store the state of the board in App Data, which
means that the user could rewrite the entire board whenever they felt
like it.
You may be asking, "what use is App Data then?", which is a valid
question. I like to treat it like a user preference store- if a
person uses my app to say that their favorite movie is "Casablanca"
but then decides to rewrite their App Data to say that their favorite
movie is "The Matrix", then I don't really mind very much. There's
also a use case where an app uses App Data to cache data that is
rendered by their server in order to speed up performance. When your
app gets used by a lot of people, this extra caching becomes extremely
useful in speeding up your app and reducing server load.
I hope this helps a bit,
~Arne
On Mar 12, 5:40 am, RoelandP <dnal...@gmail.com> wrote:
> Imagine these functions (a call and a callback):
>
> function updateAppData(myData) {
>
> var req = opensocial.newDataRequest();
> req.add(req.newUpdatePersonAppDataRequest
> ("VIEWER","appDataKey",myData),"appDataHook");
> req.send(updateAppData_callback);
>
> };
>
> function updateAppData_callback(response) {
>
> if (response.get("appDataHook").hadError()) {
> trace("updateFAIL");} else {
>
> trace("update APP was great Succes! Party On!");
>
> }
> };
>
> Yes it is a basic application data updater, which stores some data
> under the "appDataKey" for my application (e.g. Highscore, last time
> used, favourite dish, etc.)
>
> According to my opinion it is possible to script in Firebug a call to
> this function (e.g. inject <a href="javascript:updateAppData('this is
> malicious data');">inject it</a> in the current html of the app. In
> this case only the Viewers AppData though (storing the string 'this is
> malicious data'). But it is still possible I think... (6)
>
> Is this indeed possible and are there possible solutions for securing
> these calls?
>
> looking forward to your reactions/opinions!
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"OpenSocial Application Development" group.
To post to this group, send email to opensocial-api@googlegroups.com
To unsubscribe from this group, send email to
opensocial-api+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/opensocial-api?hl=en
-~----------~----~----~----~------~----~------~--~---
