Ghost,
Though I think in many situations there's not really a way to make an
app/game 100% spoof-proof, there are some things you can do to make it
harder on the spoofer. Most of them rely on putting some extra logic on the
server-side and/or moving some client-side logic to the server, when
possible.
1) Always use server-side sessions.
That way, if I download your swf, modifiy it and try to post data, you
can detect that I don't have a valid session and not save the date I've
sent.
There are ways to circumvent server sessions, since the client is
involved in the session mechanism (the data that allows the server to
identify a client is partially held by the client), and with tabbed browsers
you can navigate to the original page to get a valid session, then open a
new tab and use any of the plugins available in Firefox, for instance, to
post data to the server with a valid session.
2) In some cases, you can move the logic that assigns points from the client
to the server. For instance, in a trivia.
Instead of loading from the server something like:
<question text="some question">
<option test="option a" correct="0" />
<option test="option b" correct="1" />
<option test="option c" correct="0" />
</question>
Use something like this:
<question id="2" text="some question">
<option test="option a" id="7" />
<option test="option b" id="8" />
<option test="option c" id="9" />
</question>
That way, you just inform the server that the user has picked the option
whose id is, say, 7, for the question 2, instead of telling it that the
user's answer was right or wrong. The server will determine whether that's
correct or not and assign points accordingly.
2) Use "unique handlers" (UH) each time you send some data to the database.
Before starting the game (or a level in the game), make a call to the
server and have it return to the swf a unique handler that will identify
that particular "transaction". A GUID (http://en.wikipedia.org/wiki/Guid)
can be a good option, since most databases implement it.
When you save data (for instance, the score), pass the unique handler
too, so the server can do some validation. That forces the spoofer to add a
new step to their "process".
3) Save the time of each "transaction"
This can be used in combination with unique handlers. You save in your
DD.BB. the time when the "unique handler" was asked by the swf and save the
time when the actual data was sent. That allows some auditing if there are
prices involved. For example, if you know it's not possible to complete the
level 1 of your game in less than 60 seconds and the time diff between the
UH request and the actual data post is, say 10 seconds, you know the data
has been spoofed (or you have a bug in your game...)
A couple of months ago, at work, we put online a trivia. There was a
total of 75 questions stored in the database, and server randomly picked 5
of them to send to the client, one at the time (each question had 5 possible
answers). Once the swf posted the option picked by the user, the server
would check if it was valid and would respond back accordingly, to inform
the user of the result. The number of correct answers was the first
criterion to determine the winner, and the total time used to complete the
trivia was used in case of a tie.
At some point we noticed that there were a couple of users that had
"too" perfect scores, so we made an "informal" audit. Googling some of the
registered names (A real name plus some real ID was required to collect the
prices). We found that one of these names appeared in a page about a robot /
automata course in an Argentinian university.
Apparently the guy built a "robot" (some automated set of scripts?) that
would "play", just for "data mining", so to speak. Our guess is that it
called the server, saved the xml with each question, and systematically
posted each answer looking for the correct one. At some point, he had
replicated the "questions" and "answers" tables from our database, so he
knew in advance all the correct answers (and you just can't lose if you know
that!). Once he got to that point, he created a legit user with his real
name, an answered the trivia without errors. The problem was the time it
took him... Comparing the time at which the xml with the questions was
returned by the server with the time the answers were posted, it was obvious
that the player was not human (There's no way anyone can read a question,
choose the correct answer and click send in 50 ms or even less...).
So, we were able to invalidate the user because we were saving a
timestamp for each request. Anyway, if he hadn't been so greedy and had put
some time delay between each answer, using timestamps wouldn't have been
enough. But the point is that by using them, you're adding an extra layer of
"protection". It's not perfect, and it's not guaranteed to prevent spoofing,
but it helps.
4) Use some form of encryption for sensitive data
Again, this only adds complexity, but it doesn't make your app
"unspoofable". The idea is avoid sending data such as scores in plain text.
Instead, encrypt or cipher it in some way.
Even a simple xor encryption can help. (
http://www.google.com/search?q=xor+encryption)
Recently, I had to adapt a couple of games developed by other agency
(minor changes really, not the core logic of the games). The games used RSA
encryption to send the scores to the server. (They used an open source AS
3.0 library: http://crypto.hurlant.com/). Of course the results are way
stronger, but in the end, it still has a week point: that code is in the
swf, which you can download and decompile at will. And to encrypt, you
either use some hardcoded key (which is visible in a decompiler) or you
retrieve it dinamically from the server (which makes it visible to any
sniffer or plugin like HttpWatch on IE or HttpFox in FF). I think the
problem is that those encryption methods are designed to avoid a third party
to intercept the data exchanged by a client and a server, but not to prevent
a client from forging that data... Anyway, it's a bit more work on your
side, quite a lot more work on the spoofer side, so even though is't not
100% spoof-proof, it helps. Of course, someone with with time and the proper
knowledge can bypass that protection, but by adding some encryption, you are
minimizing the chances of being spoofed.
Cheers
Juan Pablo Califano
2008/5/25, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
>
> Hi all.
>
> Anyone know a solution for preventing client spoofing for sending data with
> flash apps?
>
> Like say with sending high scores for a flash game?
>
> Let's say you have a flash game. Someone decompiles the SWF, (and grabs all
> the relevant SWFs in case you were using loader shell SWFs), extracts the
> url to send the scores to, then creates a flash app to mimic yours just for
> sending fake scores (now that he/she knows the proper variables & values to
> send after having decompiled your SWF and had a thorough look at your
> algorithms).
>
> How does one prevent client spoofing? (building a fake app that will
> pretend to be legit and send illegal data)
>
> Let's say a PHP or ASP file receives the scores from your flash game.
>
> Is there any way to authenticate that the scores are coming from a legit
> app?
>
> http referrer doesn't seem to be working properly with Flash.
>
> Any help is much appreciated.
>
> Regards,
>
> -Naz
> http://www.object404.com
>
> _______________________________________________
> Flashcoders mailing list
> Flashcoders@chattyfig.figleaf.com
> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
>
_______________________________________________
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
