Hi again,

Have you considered having some sort of server-side permission/authentication structure based upon the method being called (and/or the user calling it)?

I know my flashPash project is quite different from your PHPObject, but perhaps you might find use for this:
http://flashpash.sshnug.com/documentation.php?menu=FlashPashServerClass#div_FlashPashServerClass_Properties_checkUser

My code is free and open source, so you're welcome to have a look...you can see the permissions in action by running demo:
http://flashpash.sshnug.com/demo.php?type=swf&name=firefly

Click on Meta-Data button, DB listing is denied, table and columns and SQL is allowed. Also similar for Generic SQL, I allow SELECT queries, but deny ALTER, CREATE, DROP queries. This is all done server-side from the XML permission file, nothing the client can do about it (unless they hack the server:)

thoughts welcome.

peace
si

Hi si, thanks for the message and the links. However, it seems you might have missed the point...

The server-side authentication you mentioned works fine for authentication of end users, because the end-user will be providing the username/password during runtime. However, we are talking about authentication between server and flash-movie (the developer), and the username/password in this case will be 'entered' during compile time (and can potentially be revealed using an actionscript viewer).

I am not concerned about authentication between server and end-users because that can be implemented easily on a project-by-project basis by the developers.

You can read about this security issue, generally present in flash remoting, also mentioned in
http://www.markme.com/mesh/archives/000377.cfm

Hope to hear more ideas, thanks.

Sorry Sunny, I didn't really understand your problem.

So if I understand correctly, you need to authenticate an application and not the user of the application?

What about this - for each request, PHP has a REQUEST_URI stored in $_SERVER. Perhaps this could this be used? eg. On the server with PHPObject, you have a list of hashes kept in a safe place, which are hashes (say MD5) of all the valid applications (shockwave files). When a request is made, PHPObject reads this URI and calculates the hash and compares against your list for validity.

This would only work if you can't easily fake REQUEST_URI...anyway, just an idea, worth what you paid for it ;-)

peace
si

Hi si, thanks. You help is appreciated :)

Unfortunately, the REQUEST_URI won't work. I have tried that before (and HTTP_REFERER). REQUEST_URI returns the path of the script (ie, Gateway.php) and HTTP_REFERER returns nothing (because the script has been requested from within Flash). I have however implemented a 'disallowStandalone' flag in v1.4 (see Journal http://ghostwire.com/archives/phpobject/000030.html ).

Anyway, pondering over this 'security issue' again, I think we may be worrying over nothing. Consider the following:

* Using in a closed environment such as an intranet - no issue

* Using in a closed environment where member authentication is required - no issue (because the key can be generated and validated during runtime)

* Using in standalone where member authentication is required - no issue, as above

* Using in standalone - no issue if it is a client project for client's own use and the gateway is hosted on client's own servers and key is maintained by client (unless the client compromises his own security circulating his key or his standalone application)

* Using in public website - don't offer web services or 'disallowStandalone' - no issue (at this time, not sure whether the 'disallowStandalone' will work as expected). Just take more care when providing services to the public under a non-authenticated environment - services that directly updates databases, such as allowing INSERT, UPDATE, DELETE etc. SQL statements to be executed from Flash is generally a no-no.

Anyway, as long as the developer writes secure PHP-side scripts, PHPObject (or flash-remoting in general) should be safe to use. You can also have more than one gateway on each server, and limiting the services (php classes) to each gateway can limit the security risk.

Hey again,

Glad your happy with the security, must test the REQUEST_URI and see what is in there...bummer if you can't get the URI of the shockwave :(

In regards to your comment:

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
[snip]

Just take more care when providing services to the public under a non-authenticated environment - services that directly updates databases, such as allowing INSERT, UPDATE, DELETE etc. SQL statements to be executed from Flash is generally a no-no.

[snip]
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

I would respectfully disagree with this, take phpmyadmin for example, this is a great tool which allows database access like SQL INSERT/UPDATE/DELETE after authentication, and it would be cool to have a nice Flash GUI which does something similar. In Flash you could make the interface more attractive and more like traditional db admin tools.

The thing you have to take care with is that SWF is open and can be easilly disassembled, so the rule should be you don't build any sensitive information into the movies, and authenticate before doing anything. If you're really paranoid, you might not store any meta-data in the movie and instead only retrieve from the server after authentication.

I guess i'm sensitive to this :) since I do allow freeform SQL in flashPash through the doSQL method, but implement a server-side permission structure to prevent malicious behaviour.

peace
si

Hi si, thanks you are right. But like I said, **under a non-authenticated environment**, such SQL operations shouldn't be allowed :)