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 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?
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?
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?
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
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
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
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
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
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
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 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
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 > >