Comments on: Security with Zend_AMF and Flex – Part 2: Practise http://www.encapsulated.org/blog/2009/04/15/security-with-zend_amf-and-flex-part-2-practise/ An analog guy in a digital world Wed, 18 Aug 2010 19:35:56 -0700 http://wordpress.org/?v=2.9.2 hourly 1 By: Titi http://www.encapsulated.org/blog/2009/04/15/security-with-zend_amf-and-flex-part-2-practise/comment-page-1/#comment-1973 Titi Wed, 24 Feb 2010 16:19:02 +0000 http://www.encapsulated.org/blog/?p=31#comment-1973 Hi Tom I know that this blog entry is a little bit old but it's very helpful to me. Do you know if your colleague would agree to show me his flex code ? Because it's the hardest part for me in the authentication process with zend_amf... Thanks a lot Hi Tom
I know that this blog entry is a little bit old but it’s very helpful to me. Do you know if your colleague would agree to show me his flex code ? Because it’s the hardest part for me in the authentication process with zend_amf…

Thanks a lot

]]> By: Skuip http://www.encapsulated.org/blog/2009/04/15/security-with-zend_amf-and-flex-part-2-practise/comment-page-1/#comment-1491 Skuip Thu, 26 Nov 2009 16:26:00 +0000 http://www.encapsulated.org/blog/?p=31#comment-1491 That means the challenge/signature pair should be remembered forever, because at the moment you decide to delete challenge/signature pair it becomes valid again for any API call. One thing you maybe can do is to generate challenge by creating a checksum based on the user name, method name and its parameters and repeat the same on the server to check/validate the challenge. It does not prevent any replay attack, but at least he can not change the method or any its parameters. But I still think it is better to create some incrementing challenge, so you can refuse any challenge that is not bigger than the last one. Maybe use both by generating a challenge and appending it with an incrementing counter. That way you can easily determine if the challenge is new and valid. The extra challenge data may slow the brute-force attempt by the attacker. A completely different way is to go with public/private key encryption and encrypt something what the server can verify after decryption with its private key. But public key encryption can be quite expensive and I do not have any ready available solutions. And there is the fact that public/private key encryption is not a standard Flash/Flex component. There is an as3crypto library, but who knows how bug free that is. That means the challenge/signature pair should be remembered forever, because at the moment you decide to delete challenge/signature pair it becomes valid again for any API call.

One thing you maybe can do is to generate challenge by creating a checksum based on the user name, method name and its parameters and repeat the same on the server to check/validate the challenge. It does not prevent any replay attack, but at least he can not change the method or any its parameters.

But I still think it is better to create some incrementing challenge, so you can refuse any challenge that is not bigger than the last one. Maybe use both by generating a challenge and appending it with an incrementing counter. That way you can easily determine if the challenge is new and valid. The extra challenge data may slow the brute-force attempt by the attacker.

A completely different way is to go with public/private key encryption and encrypt something what the server can verify after decryption with its private key. But public key encryption can be quite expensive and I do not have any ready available solutions. And there is the fact that public/private key encryption is not a standard Flash/Flex component. There is an as3crypto library, but who knows how bug free that is.

]]> By: Tom http://www.encapsulated.org/blog/2009/04/15/security-with-zend_amf-and-flex-part-2-practise/comment-page-1/#comment-1483 Tom Mon, 23 Nov 2009 14:38:29 +0000 http://www.encapsulated.org/blog/?p=31#comment-1483 Hi Skuip, thanks for your feedback. I agree that the problem you describe is possible. The way I have used this setup, is by also implementing a transaction system: I keep track of all challenge/signature pairs. If I find a duplicate key for a pair during the session, I don't execute the call, but simply return what was returned previously. This was not really to prevent such an attack, but rather to prevent an application of submitting twice the same data (while only once was needed). Like a user who is impatient, and refreshes the page, thus submitting the data again. I haven't described the transactions in this blogpost, because I only implemented that part later on (and was too busy to blog about it). Do you think this is a viable solution to the problem you described? I'm open to input, because I would like to keep the setup as secure as possible. Hi Skuip, thanks for your feedback.
I agree that the problem you describe is possible.

The way I have used this setup, is by also implementing a transaction system: I keep track of all challenge/signature pairs. If I find a duplicate key for a pair during the session, I don’t execute the call, but simply return what was returned previously.

This was not really to prevent such an attack, but rather to prevent an application of submitting twice the same data (while only once was needed). Like a user who is impatient, and refreshes the page, thus submitting the data again.

I haven’t described the transactions in this blogpost, because I only implemented that part later on (and was too busy to blog about it).

Do you think this is a viable solution to the problem you described? I’m open to input, because I would like to keep the setup as secure as possible.

]]> By: Skuip http://www.encapsulated.org/blog/2009/04/15/security-with-zend_amf-and-flex-part-2-practise/comment-page-1/#comment-1481 Skuip Mon, 23 Nov 2009 13:59:12 +0000 http://www.encapsulated.org/blog/?p=31#comment-1481 I think you got a problem with verifySignature($challenge,$signature). What is preventing a hacker from using the same challenge and signature hashed for an other API call (replay attack)? Probably can solve it by using a challenge that's incrementing and enforcing that every received challenge is bigger than the last received challenge. That way an attacker can't reuse a challenge and signature pair. I think you got a problem with verifySignature($challenge,$signature). What is preventing a hacker from using the same challenge and signature hashed for an other API call (replay attack)? Probably can solve it by using a challenge that’s incrementing and enforcing that every received challenge is bigger than the last received challenge. That way an attacker can’t reuse a challenge and signature pair.

]]> By: Rich http://www.encapsulated.org/blog/2009/04/15/security-with-zend_amf-and-flex-part-2-practise/comment-page-1/#comment-766 Rich Fri, 04 Sep 2009 00:03:51 +0000 http://www.encapsulated.org/blog/?p=31#comment-766 I would not recommend storing the password in session. It's just not secure. Nice try to replace SSL.:) I would not recommend storing the password in session. It’s just not secure. Nice try to replace SSL.:)

]]> By: seb http://www.encapsulated.org/blog/2009/04/15/security-with-zend_amf-and-flex-part-2-practise/comment-page-1/#comment-124 seb Fri, 03 Jul 2009 14:35:10 +0000 http://www.encapsulated.org/blog/?p=31#comment-124 I mean, since i have an error when the signature isnt good, i can bruteforce the user:pass and then all this is useless. But, this technique will indeed generally work. I mean, since i have an error when the signature isnt good, i can bruteforce the user:pass and then all this is useless. But, this
technique will indeed generally work.

]]> By: Tom http://www.encapsulated.org/blog/2009/04/15/security-with-zend_amf-and-flex-part-2-practise/comment-page-1/#comment-120 Tom Thu, 02 Jul 2009 20:51:19 +0000 http://www.encapsulated.org/blog/?p=31#comment-120 Hi Seb, i don't believe that with decompiling the flash, that you can do a lot of mischief. It would be possible for you to find out how all the hashing is done, and what the order of the parameters is. But then you would still need the user & password of someone who is known on the server side. If you brute force a user & pass that is not known on the server, then the server won't be able to verify the validity of the signature. And then a call won't be allowed. If you know a user & password, then there's no need for you to decompile the flash, since you will just be able to log in, and do everything there. As I said before, as soon as the password is discovered, no security will matter. Hi Seb,

i don’t believe that with decompiling the flash, that you can do a lot of mischief. It would be possible for you to find out how all the hashing is done, and what the order of the parameters is. But then you would still need the user & password of someone who is known on the server side. If you brute force a user & pass that is not known on the server, then the server won’t be able to verify the validity of the signature. And then a call won’t be allowed.

If you know a user & password, then there’s no need for you to decompile the flash, since you will just be able to log in, and do everything there. As I said before, as soon as the password is discovered, no security will matter.

]]> By: seb http://www.encapsulated.org/blog/2009/04/15/security-with-zend_amf-and-flex-part-2-practise/comment-page-1/#comment-119 seb Thu, 02 Jul 2009 20:42:02 +0000 http://www.encapsulated.org/blog/?p=31#comment-119 What about the flash client side, wich we can decompile and get the signature. Then, we brute force for a user:pass and boom... What about the flash client side, wich we can decompile and get the signature. Then, we brute force for a user:pass and boom…

]]> By: Tom http://www.encapsulated.org/blog/2009/04/15/security-with-zend_amf-and-flex-part-2-practise/comment-page-1/#comment-90 Tom Fri, 05 Jun 2009 09:17:21 +0000 http://www.encapsulated.org/blog/?p=31#comment-90 Hey Lasse, You have probably found a vulnerability in my system yes :) Perhaps Zend_Session::regenerateId() is a possible solution. Another solution would be that the challenge is in fact a checksum of the data you want to submit. This way, a hijacker could intercept the call, but he wouldn't be able to tamper with the data, or the checksum & signature won't be valid. Then it doesn't matter if the attacker can manipulate the data and checksum (challenge). The signature won't be valid, so the call won't succeed. How does that sound? Perhaps this in combination with regenerateId(). Thanks for pointing out the hole. It's actually quite obvious, but I hadn't looked at it this way :) Hey Lasse,

You have probably found a vulnerability in my system yes :)
Perhaps Zend_Session::regenerateId() is a possible solution.
Another solution would be that the challenge is in fact a checksum of the data you want to submit. This way, a hijacker could intercept the call, but he wouldn’t be able to tamper with the data, or the checksum & signature won’t be valid.

Then it doesn’t matter if the attacker can manipulate the data and checksum (challenge). The signature won’t be valid, so the call won’t succeed.

How does that sound? Perhaps this in combination with regenerateId().

Thanks for pointing out the hole. It’s actually quite obvious, but I hadn’t looked at it this way :)

]]> By: Lasse http://www.encapsulated.org/blog/2009/04/15/security-with-zend_amf-and-flex-part-2-practise/comment-page-1/#comment-88 Lasse Thu, 04 Jun 2009 20:31:38 +0000 http://www.encapsulated.org/blog/?p=31#comment-88 Hello Tom, the specific situation I'm thinking of is: The session has been hijacked and the hijacker has also intercepted the client generated signature and challenge, which he is now able to use, without ever having known the password? Am I mistaken or would that not enable him to make api calls as an authenticated user? Also wouldn't it be a good idea to do Zend_Session::regenerateId(); on each request, in order to make the chance of session hijacking as low as possible? Hello Tom, the specific situation I’m thinking of is: The session has been hijacked and the hijacker has also intercepted the client generated signature and challenge, which he is now able to use, without ever having known the password? Am I mistaken or would that not enable him to make api calls as an authenticated user? Also wouldn’t it be a good idea to do Zend_Session::regenerateId(); on each request, in order to make the chance of session hijacking as low as possible?

]]>