At 8/21/12 02:48 AM, kaiser-d wrote:
1) php extracts data from mysql, converts to json
3) ??? flash needs to accept json and initialize things based on what is handed to it from php
4) flash handles graphic intensive processes, sends variables via json to update other page elements
5) ??? upon completion of task, data is posted from flash, handled again by php, and updated to database
6) new instance is called after updating and process repeats
ahh, it seems you don't quite understand how all of that works. It's fine, not a whole lot of flash programmers do (it's not like it's actually useful to flash 99% of the time)
The difference is that GET variables are visible (and taken from) the URL directly, while POST is more hidden.
This is the fun part.
Say you have a "vote" button that takes a user's username and hashed password as variables. You could use a POST request and GET request interchangeably.
Now say that you wanted the user to be able to bookmark the "vote" page directly so all they have to do is visit the page to vote. With POST they would have to click the button every time, whereas with GET all they would have to do was bookmark the page and visit it to vote. Why does that work? Because POST is hidden and GET is not.
If you didn't want them to be able to bookmark the page, then use POST.
"hidden" does not mean "secure" by any stretch of the imagination. GET and POST requests are both equally user-writeable.
When coding, assume that every single user who uses your script is a malicious hacker with lots of time, energy, and focus to spend on your script. You need to be even more diligent to keep them out. After the script is written and security is in place, then you can go back to your happy land where there is no evil.
The point is that when scripting and including security, assume that everything's out to get you. Yes, it makes you paranoid. Yes, being paranoid is a good thing. After all, the paranoid programmer will have fewer vulnerabilities and thus fewer successful attacks on the script.
Nothing is 100% secure. There is not a single program ever written in the history of the world, and never will be, that is 100% secure. Same thing with locks and any other types of security.
Do not "play" with hackers or think that you can outwit them. Do not think for a second that your script can't be hacked. Do not allow a hacker into your system farther than what you have caught them at if you catch them. You squash anything and everything that tries to get in immediately.
Security is dark and somewhat depressing. You have to let go of all faith in humanity and assume that everyone is this malicious, evil being spawned from Satan. I put a lot of emphasis on this because it needs it. When you're dealing with security, you do NOT play around.
On to the brighter side of things.
This is the easy part. All you have to do is make sure of two things:
1. Everything going into the database is sanitized to avoid SQL injection.
2. Passwords and private things are encrypted and not in plain text.
Please don't use MD5 and expect that to work. MD5 is great, but can be cracked - use something like an AES-standard Rijndael encryption with a double-hashed 100-character key and a CFB cipher mode on top of your MD5.
This is the hard part. This is where I start getting into public keys and private keys (or at least something similar)
Data sent through HTTP requests are plaintext and can be picked up anywhere along the way by something like wireshark or ettercap. HTTPS is more secure, and those programs will just get a load of garbage coming in. Flash's URLLoader supports HTTPS.
If, however, you don't have access to 20 frieking bucks a month for HTTPS support, you devise your own little "load of garbage" like I did. I haven't yet figured out a "garbage collection" system for the public keys, but I think I have an idea on it.
It's actually quite simple once you get the basic concept down. The major thing to keep in mind is that you don't want people seeing what's being passed through. How do you do that? Via encryption!
I added a table to the database that stored public keys attached to an ID (encrypted by the private database key. Yeah. I don't play around.)
When someone connects to the DB for the first time, it will generate a new 10-to-15 character key. The key is just a random string of letters and numbers. After the key is in the database and the ID is pulled from it and any other stuff I want to run is done, I send the unencrypted key and ID to flash. This is the only dangerous part.
After that's done, all I have to to is encrypt all the variables I want to send in the client, send them along with the ID, and decrypt the variables server-side.
As for garbage collection, I think adding a "date and time last used" to each key would be a good idea. You could just tell the server to clear out anything older than x minutes (or x seconds, depending on the program and server load)
The tricky part with this is that the encryption used for the client -> server has to match EXACTLY, or else you'll just get a bunch of garbage.