how to restrict outside access to php files needed by a swf

[mammy]

hello all,
i have php files that my swf needs for database access that i'd like to restrict access to so no one other than the swf can gain access to for security reasons. seeking best practice for this.

can't simply do an .htaccess redirect away from the directory w/ the php in it since the swf client will also get redirected.

one way is to embed a key into the swf which gets POSTed to the php file. if this key doesn't exist then the php file sends an error message rather than executing. but then someone could crack the swf and get the key. and if the swf retrieves the the key from the server then there still must be an unprotected file for the swf to get the key from.

another way is to .htaccess protect the folder with the php files and allow the swf to authenticate. is this best? if so, how to do this?

what's your thinking?

tia,
michael

[CyanBlue]

I'd go with the key idea plus checking the referrer so that you are only accepting the connection from the mydomain.com... That's my 2 cents... ;)

[mammy]

thx cyanblue,
don't think i can restrict connection domain/ip since the swf will need access to the php files, too, and it'll be executing client-side.

[Cota]

Will this be on a webserver, or local?

[mammy]

server

[Cota]

This is what I would do in this situation.
1 - Have Flash send the domain name to a PHP script.
2 - This PHP would check the domain to validate it. Then I would have it send back a hash value to Flash. It will also store this has value in the database. Think of a session variable. This hash should only have a limited life span.
3 - Use the hash to verify all the other calls from Flash.

[CyanBlue]

Hm... Why wouldn't my referrer idea work??? What/when would be the case where that won't work, Cota???

[mammy]

Cota,
interesting idea but when flash sends the domain name to the php file to make that domain valid for php access during that session, then a hacker's domain would temporarily validate so he could gain direct access to the php files during that session. so all a hacker would have to do is go to the site first, then get access to the php files. true?

[Cota]

I cant answer that with 100% certainty, but we use a similar hashing system for our CMS security and, well, it hasnt been compromised yet. Granted, we have a complicated hashing system, however, if you're checking the domain, and a time sesative hash for all calls, you're in really good shape.

@CyanBlue - the http referrer is what can be compromised. The domain name is send via Flash. This way, if someome tried to take your SWF to another domain, it should fail.

[CyanBlue]

Hm... You can modify the referrer data??? I did not know that... Interesting...

[Cota]

Here's one way,
http://www.mustap.com/phpzone_post_62_how-to-bypass-the-referer-se

[CyanBlue]

Ah, I see... Thanks... ;)

[mammy]

Cota, sounds good but one question. my universe of uses is a combination of members with known IP address but also new users with an unknown IP who, when they go to the site and download the swf, their swf would need access to the php files, too. so there isn't a finite domain or IP address list to validate from. it has to be open to all domains/all users (but only the swf should have access to the php file rather than a hacker going directly to a php file from his browser). not sure if the system you built only grants access to a finite list of users.

let me see if i can translate your methodology to my open user-base:

flow:
- use's browser downloads the .swf and the swf reports back to a php file the IP address of the user ISP.

- the php file creates a hash value for this IP/session ID/time stamp combination and stores in a database and sends back to the swf.

- the php file will auto kill the hash value in the database after a predetermined timeout.

- with every php call the swf makes it sends this hash value for validation.

- all php files must receive a hash value to grant access to them and all php files validate before executing.

do i have it right?

[Cota]

correct, except for one part. I'm a little unclear, I thought the swf was running in a site, not being downloaded to individual machines?

[mammy]

yes, it's running from a site but the downloading i'm referring to is the user's browser downloading the swf when the user goes the site and running the swf locally, as swfs do.

[Cota]

Is the user looking at it in a browser or as a stand alone app? If its in a browser, the domain sent from Flash will be the sites domain name.

[mammy]

looking at it in a browser. hmmm. so i guess flash, after the user's browser runs it locally, can't report the user's IP address after it downloads. this makes sense.

> 1 - Have Flash send the domain name to a PHP script.

i thought the domain you were referring to was the user's IP. what good would it do to send the site's domain since the hacker knows it and can send just as easily as the swf??

[Cota]

Thats where you add a little extra, know what I mean?

[mammy]

i hear ya. but still, all a hacker has to do is go to the site and use that browser session to get direct access to all of the php files since the system is only using session id, the known domain name and time as validation criteria. the hacker would go to the site and have x number of minutes to get access to the php files. even with the user's IP address thrown in as part of the hash it doesn't help much.

but i can't think of anything more secure. i suppose you can thrown in an internal key that's inside the swf for some added security.

[Cota]

And the varaible name that the php is looking for is another layer of security.

[mammy]

true. so you think that this is a better method than having the swf perform authentication on an .htaccess protected folder?

[jsebrech]

There are hacker tools that make it quite easy to intercept the calls from the swf and turn them into whatever you want (http stream editors). Even https does not save you in this case, because there are ways to get around that as well. So, I would say, use a simple mechanism (like referrer checks) to prevent casual snooping and cross-site scripting, and combine this with a thorough server-side rights and security mechanism. Don't rely on any sort of client-side protection, because that just does not exist, at all.

[mammy]

thx joeri, i agree. but the main problem is how to execute any form of server-side rights/security with flash with an open user-base since ultimately the swf needs access to the files and its coming from the client side. at some point, client-side swf needs to provide some sort of permission to gain access.

[jsebrech]

By server-side security I mean you must have server-side accounts with some form of rights management. A user should never be allowed access to stuff their account doesn't cover. The swf is merely the intermediary, and almost inconsequential to the security model (aside from XSS or CSRF security exploits).

[mammy]

i agree that security should be server-side only but this is a flash-specific dilemma since a swf a) executes client-side and, b) needs access to php files for database access that human users shouldn't get access to. that's the problem. and it's an open user-bases. no accounts.

[jsebrech]

Even so, if the flash file accesses the PHP page, a human is accessing it, but through an intermediary. So, you have to think about what it is that users are legitimately allowed to do, and block any non-legitimate actions from the server. This may mean keeping a "workflow" server-side, where you hand out sessions to each user and verify that the user is in the correct workflow step in the session to take the action they are requesting.

[mammy]

i think i understand what you're getting at. the tricky thing is that i don't want a human to do even the legitimate actions that the swf is able to do. the swf can, say, delete an image at the appropriate time after user interaction with the swf interface. i don't want a human to be able to replicate that same legitimate action or a hacker will be able to delete image files.

i think what you're saying is to setup a step-wise process that php must receive/validate in order for php to delete an image file rather than the php file simply deleting a file on command. the php file must be aware of a flow of actions before deleting a file. since only the server-side php workflow manager file will know what these steps are (not a human) only the swf will ultimately be able to delete an image file. do i have it right?