How could I make my php and flash so it can only be accessed from my flash app?
So if someone loads the php on it's own it wont load.
Specific POST variables could be defined, but those could (after a bit of work) be taken from the decompiled SWF.
Can you set your own headers in actionscript GET/POSTs? You could set the agent to something along the lines of "myFlashApp" and check for that in the php code; also hackable.
if both methods are easily "hackable" why did you post them?
Because they are both viable solutions depending on how secure it needs to be.
Store a key in the Flash, have the PHP script send a salt. Generate a hash from the salt and the key in Flash and send it to the PHP script, which computes it with a matching key stored locally. Compare. Deny access if they don't match.
This is still insecure because the key must be stored in the SWF file. Even if you manage to obscure that, it must be decoded and loaded into RAM at some point. With some effort, an attacker could find the key and use it to write his own client.
There's really no way to make this totally secure.
[QUOTE=ROBO_DONUT;16772560]With some effort, an attacker could find the key and use it to write his own client..[/QUOTE]
Or the attacker could just decompile the swf and remove the part that checks the key.
I tested it myself by decompiling, finding the post variable, creating an html form and pointing it at that php, and I can immediately change my money amount on my account.
So to aid in this not happening I made it so first the user must be logged in otherwise the flash and php deny access to anything.
I also made it so that the php uses mysql to store a log of every post action, it stores username, steamid, IP, date, and amount of money given to the user, any amount of money entered that is greater then the game is capable of giving is immediately blacklisted and all admins get an email.
If it turns out to be a hack I ban.
But what I'm worried about at that point would be the prick leaking his knowledge of the exploit.
[QUOTE=Neo Kabuto;16774855]Or the attacker could just decompile the swf and remove the part that checks the key.[/QUOTE]
The check is server side. The client just computes the salted hash and sends it to the server.
Like others said, it's very very hard to make communications with something client-side unhackable.
Anyway I can make it to only accept posts from files local to the server?
That can be spoofed.
[QUOTE=nivek;16777498]I made it so first the user must be logged in otherwise the flash and php deny access to anything.[/QUOTE]
Do you mean that the PHP page checks that it knows who the user is (e.g. from a userid stored in the session, or username/password sent by the Flash applet) and refuses to send anything back to the Flash applet if not? If so, that's about the best that can be done. The PHP code running on your server has no way of knowing what software is running on the client, so you want to orient your security around what the [i]user[/i] is allowed to do, not what the [i]Flash applet[/i] is allowed to do.
[QUOTE=nivek;16777498]I also made it so that the php uses mysql to store a log of every post action, it stores username, steamid, IP, date, and amount of money given to the user, any amount of money entered that is greater then the game is capable of giving is immediately blacklisted and all admins get an email.
If it turns out to be a hack I ban.[/QUOTE]
Good move. Keeping an audit log, so that attacks can be investigated after-the-fact, is an important part of any good security system, and quick detection and response to known types of attacks is also valuable.
As an added precaution, you should make that log table insert-only -- revoke all other privileges for the database account that your PHP code connects with -- so that an attacker can't modify the records with (for example) an SQL injection attack. In addition, your application's database login should not have privileges to do any sort of DDL operations (create table, drop table, etc.) [i]at all[/i].
[QUOTE=nivek;16777498]But what I'm worried about at that point would be the prick leaking his knowledge of the exploit.[/QUOTE]
Assume that any information known by something running on the user's computer (e.g. Flash) is known to the user himself, and design your application with that assumption in mind. Treat the raw HTTP requests/responses as the application's "real" interface, and the Flash applet as just a convenient front-end that has nothing to do with the security of the system. Then it doesn't matter if all your users know how to bypass the Flash and craft their own HTTP requests, because they don't bypass any security by doing so.
Before carrying out any action requested by the user, verify that the user is allowed to do it. For example, if your application is adding money to a user's account, where is that money coming from?
[list]
[*]If they're paying with a credit card, make sure your payment-processing service has accepted the charge before updating your database.
[*]If it's a transfer from one user to another, make the "giving" user initiate the transfer, specifying the amount and the recipient, and store the pending transfer in the database with a unique ID. Make the "receiving" user specify this transfer ID, and verify that they're the intended recipient of that transfer, and that the "giving" user actually has the funds at this moment, before updating any account balances. Read up on database transaction safety or you'll be vulnerable to timing attacks.
[/list]
The user must be logged in (via session) to have access to flash app, and the money system has no relevance to real money.
You're saying the user has to be logged in to download the .swf file -- OK, probably not necessary to restrict that, but there's no harm in it.
But what about a user who uses the Flash app for a while, examines the requests it's making to the PHP page (using something like [url=http://www.wireshark.org/]Wireshark[/url]), then comes back later [i]without[/i] being logged in and starts accessing the PHP page directly? Does the PHP page itself check the user's credentials?
[QUOTE=Wyzard;16786187]You're saying the user has to be logged in to download the .swf file -- OK, probably not necessary to restrict that, but there's no harm in it.
But what about a user who uses the Flash app for a while, examines the requests it's making to the PHP page (using something like [url=http://www.wireshark.org/]Wireshark[/url]), then comes back later [i]without[/i] being logged in and starts accessing the PHP page directly? Does the PHP page itself check the user's credentials?[/QUOTE]
Yes, the page the flash is on as well as the flash itself both require that the user is logged in.
I think I may have misunderstood how your program works. Is the Flash applet a game that someone plays in their browser, and you want it to update the player's online account as the player makes progress in the game?
If so, you can't really secure that as long as the game logic runs on the player's computer, because the server has to trust that the player really earned the money that it's being asked to add to the account. It has no way to verify the player's actions because it can't see what's running on the player's computer.
To make it secure, you'd need to run the game logic on the server. The role of the Flash applet would be to simply report the player's actions to the server (e.g. the player clicked at coordinate <x,y>) and update the screen according to the server's responses (e.g. server says to draw an explosion at coordinate <x,y>). That way the server is the one that knows there's a monster at <x,y>, and that the player is wielding a rocket launcher (or whatever), so the server makes the determination that the player scored a kill, records it in the database, and tells the Flash to draw the explosion. That's how professionally-developed online games (WoW, GMod, etc.) do it.
didn't know you worked for blizzard!
[QUOTE=efeX;16804111]didn't know you worked for blizzard![/QUOTE]
It's the basics of server<->client game programming, it hardly only applies for professional games.
It's a flash slot machine.
Oh, that's easy then:
[list]
[*]Flash app tells the server that the player pulled the lever.
[*]PHP code on the server checks that the player's account has enough money to play, chooses three random symbols, updates the player's account based on the result, and sends a message back to the Flash app saying what the symbols are.
[*]Flash app draws spinning wheels for awhile, then eventually makes them stop on the symbols that the server told it to.
[/list]
Note that control over the balance in the player's account is kept entirely on the server.
Sorry, you need to Log In to post a reply to this thread.
