Re: [flexcoders] AMFPHP Security?
Thanks everyone for your help on this. I was hoping for some ideas but now i have loads of them! We will look into these replies in more detail in the coming days. Its interesting to know the different approaches available. Im starring this! Clark. On 11 August 2010 14:57, Imap.gmail.com jmitchell@gmail.com wrote: Use a token system. Accessing the entry page, preferably by the submission and validation of a username and password, have the server randomly generate a token and store it in php (or whatever your server side language is written in) session variables. For any other data request of any kind, query the session token and validate it prior to accepting any data or executing any other code. This, of course, should be in addition to any sql injection correction you do on data received (side note). Happy coding! Jm Sent from my iPad
Re: [flexcoders] AMFPHP Security?
You shouldn't send sensitive data to begin with, you need to calculate it on server and call saveHighScore() without parameters, so only server will know what the score was. No matter what your client technology is, the client cannot be trusted.
Re: [flexcoders] AMFPHP Security?
Clark Stevenson wrote: Hi all. I am new to AMFPHP. Lets say you have a class and a function: SomeClass.saveHighScore(304958); For me, the way i see it, is that anyone using Charles can call this method? Whats to stop anyone from calling it directly? SomeClass.saveHighScore(20394948548438484). Can any one advise me on ways i could secure this method? Hi Clark, first of all, there is no secure method; you can just make it harder. Consider this scenario: the website uses a server session. When the game starts, or just prior to sending highscore, the movie asks the server for some token (which will be stored in the serverside session data) Now the movie performs some calculations with the token and the value, and sends result of calculation. Server can verify that the client was indeed using the token matching its session ID. The calculation is sort of a crypt thing, obviously Wolfgang
Re: [flexcoders] AMFPHP Security?
Use a token system. Accessing the entry page, preferably by the submission and validation of a username and password, have the server randomly generate a token and store it in php (or whatever your server side language is written in) session variables. For any other data request of any kind, query the session token and validate it prior to accepting any data or executing any other code. This, of course, should be in addition to any sql injection correction you do on data received (side note). Happy coding! Jm Sent from my iPad
RE: [flexcoders] AMFPHP Security
Hi,
I would like to underline that somebody with good AMF knowledge can craft
strongly typed objects and send them to the server-side. If the deleteUser
doesn't require authentication and authorization it can be hacked in any
language.
function deleteUser($userVO)
{
$userVO-delete();
}
Well, you might expect that $userVO is a com.myPackage.UserVO, but it
could also be a com.myPackage.PhotoVO, or a com.myPackage.AdminVO,
or whatever. So you either have to make sure you do receive the VO type
you expect, using instanceof or is_a, or you should only use dumb VOs
which don't have any methods
Mit freundlichem Gruß,
Zoli
Re: [flexcoders] AMFPHP Security
Wouldn't Fluorine and OpenAMF throw a type-coercion error, given that
the first argument is typed? Of course, the code in the constructor
would be called anyways.
Patrick
Zoltan Csibi a écrit :
Hi,
I would like to underline that somebody with good AMF knowledge can
craft strongly typed objects and send them to the server-side. If the
deleteUser doesn't require authentication and authorization it can
be hacked in any language.
function deleteUser($ userVO)
{
$userVO-delete( );
}
Well, you might expect that $userVO is a com.myPackage. UserVO, but it
could also be a com.myPackage. PhotoVO, or a com.myPackage. AdminVO,
or whatever. So you either have to make sure you do receive the VO type
you expect, using instanceof or is_a, or you should only use dumb VOs
which don't have any methods
Mit freundlichem Gruß ,
Zoli
RE: [flexcoders] AMFPHP Security
What I mean is: if I can sniff what typed VO an application is receiving, I can craft an AMF packet with: - call to deleteUser - the same VO type (simplified: as we know that this is just a string of the class name followed by other strings describing property names and other binary data with property values etc etc etc) The gateway (fluorine, openamf, fds ... anything) will see a valid object/type. There is no type-coercion error here. This is an easy task to do with AMF knowledge. Bottom line: I don't think that passing simple types, untyped VOs or typed VOs makes any difference from security point of view. Mit freundlichem Gruß, Zoli From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Patrick Mineault Sent: Thursday, January 18, 2007 6:29 PM To: flexcoders@yahoogroups.com Subject: Re: [flexcoders] AMFPHP Security Wouldn't Fluorine and OpenAMF throw a type-coercion error, given that the first argument is typed? Of course, the code in the constructor would be called anyways. Patrick
Re: [flexcoders] AMFPHP Security
Amfphp is not inherently less secure than FDS. Anybody who wants to can
spoof requests to FDS or amfphp, just like they can for HTTP POST. As a
side-note, users don't have to bother to decompile your SWF; they can
just sniff packets coming in or out of your movie using ServiceCapture
or Charles.
The rules for securing Remoting apps aren't any different than the rules
for HTTP POST: don't trust data, secure sensitive methods
(deleteEntireDatabase(), for example), use sessions to identify users,
be wary of SQL injection, don't send SQL over the wire, use SSL when
sending credit card/banking info, etc. Just common sense really. The
only thing that you should be worried about that doesn't have an
equivalent in HTTP POST is sending VOs. Since they are mapped
automatically and VO types are uneforced, someone can spoof VOs and make
them any type they want. For example, consider the service function:
function deleteUser($userVO)
{
$userVO-delete();
}
Well, you might expect that $userVO is a com.myPackage.UserVO, but it
could also be a com.myPackage.PhotoVO, or a com.myPackage.AdminVO,
or whatever. So you either have to make sure you do receive the VO type
you expect, using instanceof or is_a, or you should only use dumb VOs
which don't have any methods. This and the fact that assignments on a
class for variables that not defined won't cause a warning unless using
E_STRICT, which amfphp won't run in (as it's impossible to work in
E_STRICT while supporting PHP4), means that using VOs in amfphp (and in
PHP in general) is IMHO bad practice. VOs make a lot more sense in fully
(runtime, not just compile-time) typed languages.
Patrick
Kevin a écrit :
Is there any good information available on how to properly secure
AMFPHP/Flex. It seems like a simple decompile of the swf file can
expose a wealth of information which could allow a hacker to easily
connect to the gateway and call any number of methods. Is there any
information on available on how to lock down an AMFPHP/flex app
properly? I have seen some discussions on the boad regarding FDS
security, but not AMFPHP. Is AMFPHP inherently less secure OR more
secure than any other data service technology. The app I am building
requires as high a level of security as I can reasonably enable.
Thanks,
Kevin
RE: [flexcoders] AMFPHP Security
I was also researching AMFPHP and I found in AMFPHP's authentication documentation that they recommend having the user authenticate themselves via textfields from Flex and pass these credentials on to PHP service. Also, sending the information encrypted via the use of SSL/TLS should also help lock down security. Those were my thoughts anyway... :) -Original Message- From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Kevin Sent: Tuesday, January 16, 2007 11:09 PM To: flexcoders@yahoogroups.com Subject: [flexcoders] AMFPHP Security Is there any good information available on how to properly secure AMFPHP/Flex. It seems like a simple decompile of the swf file can expose a wealth of information which could allow a hacker to easily connect to the gateway and call any number of methods. Is there any information on available on how to lock down an AMFPHP/flex app properly? I have seen some discussions on the boad regarding FDS security, but not AMFPHP. Is AMFPHP inherently less secure OR more secure than any other data service technology. The app I am building requires as high a level of security as I can reasonably enable. Thanks, Kevin
Re: [flexcoders] AMFPHP Security
On Jan 17, 2007, at 10:27 AM, Patrick Mineault wrote: So you either have to make sure you do receive the VO type you expect, using instanceof or is_a, or you should only use dumb VOs which don't have any methods. I think that this is an important point, so I want to make sure I understand what you are saying since I have been debating whether to use VO's in my PHP. I can create dummy VO's as you suggested (which is essentially what my Flex VO's are), but I have been wondering what advantage I get from using VO's at all in PHP unless I attempt to implement an ORM approach and actually map the PHP VO directly to the MYSQL tables and abstract my SQL into these objects. I have been a little wary of this approach (for reasons other than security) since I need a more flexibility in my inserts, AND it sounds like you would not recommend this either due to the security holes it could reveal. However, the other advantage of VO's on the PHP side is to allow them to manage the deserialization of my MySQL results, and thus fully organize them into objects that can be easily mapped back to Flex. So... a) Does this present as big a security issue? b) Is a good way to approach the mapping of PHP to Flex? How are others solving this problem. c) If one could spoof a VO, wouldn't it be just as easy to spoof a method call (assuming I take a more procedural approach). I guess I don't fully understand why the procedural approach is more secure than the VO approach. I am new to understanding web security, so forgive me if I am being naive... thanks, Kevin
Re: [flexcoders] AMFPHP Security
I think you are being very reasonable here when considering VOs, as a
lot of people tend to use them blindly, esp. people coming from Java
backgrounds. A thing I hear very often is with VOs you can be sure what
data you receive, which is true in a typed language, but in a dynamic
language, that's just not right.
Consider for example:
void addComments(CommentVO[] commentVOs) (Java)
Versus:
function addComments($commentVOs) (PHP)
Of course in Java, if a user tried to send an array of UserVO to
addComments in the first parameter, it would throw an error. In PHP
however, because it is untyped, no error is thrown, so you have to
manually check if you get the right type. Now if UserVO and CommentVO
both define an add() method, you can see that your addComments methods
could also be used to add users. Of course if users have administrative
rights, someone might use this to inject a new user with admin rights in
the db, and could wreck havoc on your system. The difference between
this and spoofing a call is that this is a really subtle security hole,
so you might not think about it. Honestly, it's not a huge hole, you
could definitely do a lot worse (I've seen people send SQL over the
wire, unencrypted, and unsecured), but I don't think trying to make PHP
into Java is a great idea (if so, why not use Java in the first place?)
I really see no issue in sending VOs back to Flash, because Flash runs
in a sandbox, so the worst that can happen is that the hacker's app
stops functioning. But sending them to the server... not the greatest idea.
Now I've seen a lot of code that looks like this:
$rs = mysql_query(SELECT * FROM the_table);
while($row = mysql_fetch_assoc($rs))
{
$vo = new UserVO();
$vo-id = $row['id'];
$vo-name = $row['name'];
$results[] = $vo;
}
return $results;
How is this any better than:
return mysql_query(SELECT * FROM the_table);
...I'm not sure... seems like it's quite a bit more code to add that
doesn't really serve that much of a purpose. Sure, you'll get VOs on the
Flash side, but if they are dumb VOs... what's the point?
Now if you actually want to send more complex data to Flash, for
example, if you wanted to send back a PostVO that includes an array of
CategoryVO, then since you're going to have to traverse the MySQL data
set anyway, you'd be justified in adding typing in as well. So basically
I'd say if you need simple data, stick with plain arrays and objects, if
you need more complex things, then VOs are cool. Right tool for the
right job, basically.
About ORM, the next version of amfphp will support Zend DB, so I'd
recommend trying out Zend_Db_Table, I looked at the docs yesterday and
it's pretty sweet. Doesn't handle associations or anything but it's
still cool. There's also Propel/Creole.
Kevin a écrit :
On Jan 17, 2007, at 10:27 AM, Patrick Mineault wrote:
So you either have to make sure you do receive the VO type
you expect, using instanceof or is_a, or you should only use dumb VOs
which don't have any methods.
I think that this is an important point, so I want to make sure
I understand what you are saying since I have been debating whether to
use VO's in my PHP.
I can create dummy VO's as you suggested (which is essentially what my
Flex VO's are), but I have been wondering what advantage I get from
using VO's at all in PHP unless I attempt to implement an ORM approach
and actually map the PHP VO directly to the MYSQL tables and abstract
my SQL into these objects. I have been a little wary of this approach
(for reasons other than security) since I need a more flexibility in
my inserts, AND it sounds like you would not recommend this either due
to the security holes it could reveal.
However, the other advantage of VO's on the PHP side is to allow them
to manage the deserialization of my MySQL results, and thus fully
organize them into objects that can be easily mapped back to Flex. So...
a) Does this present as big a security issue?
b) Is a good way to approach the mapping of PHP to Flex? How are
others solving this problem.
c) If one could spoof a VO, wouldn't it be just as easy to spoof a
method call (assuming I take a more procedural approach).
I guess I don't fully understand why the procedural approach is more
secure than the VO approach.
I am new to understanding web security, so forgive me if I am being
naive...
thanks, Kevin
Re: [flexcoders] AMFPHP Security
Thanks for the detailed reply. You might think about posting that to your blog since I have seen very little discussion about VO's in PHP and whether to use them or not. i think you have valuable insight.. (I've seen people send SQL over the wire, unencrypted, and unsecured) Sadly, in my first remoting app, I did this!! About ORM, the next version of amfphp will support Zend DB, so I'd recommend trying out Zend_Db_Table, I looked at the docs yesterday and it's pretty sweet. Doesn't handle associations or anything but it's still cool. There's also Propel/Creole. i like the simplcity of Zend_Db_Table. thanks for suggesting that. I like how easy it is to access to database. However, my only worry about using classes like this are that sometimes make it too easy to modify the data. I sometimes like to use separate mysql users ( php clases) for my delete, insert, select queries. i am not sure that this is possible in something like this. (And I don't really know if it makes anything more secure.) Propel/Creole seems good, but after looking at it closely for our uses a while back, we decided that it involved too many abstraction layers to deal with. Ultimately (for our project) we could probably do the whole thing much simpler coding the classes ourselves and writing our own SQL... Thanks again, - Kevin
