Python - remote object protocols and security

[Dave Angel]

On 07/15/2013 06:20 AM, Jean-Michel Pichavant wrote:
> In text format... sorry for my previous html post
>
> Hello everyone,
>
> I'd like to exchange some simple python objects over the internet.
> I initially planned to use Pyro, after reading http://pythonhosted.org/Pyro4/security.html I'm still puzzled.
>
> I don't mind encrypting data, if someone wants to sniff what I'm sending, he's welcome.
>

I don't think the word you need there is "mind," but I get the idea. 
You don't care who reads the data being sent, but don't want anybody to 
be able to masquerade as somebody else, either by sending with invalid 
credentials or by intercepting and modifying legitimate traffic.

What's needed for that is public/private key encryption, where the 
legitimate user uses his own private key to encode data, and you use 
their public key to decode it.  Anybody can decode it, since the key is 
public, but anyone (especialy you) can be sure who sent it, since they 
presumably keep their private key private.


> What I think I need to care about, is malicious code injections. Because both client/server will be in python, would someone capable of executing code by changing one side python source ?
>

Even if you have a friendly user sending data, you still need to guard 
against code injection because their system may have been compromised. 
And with code injection, you risk trashing not only their own data, but 
other people's and your own as well.  In other words, encryption 
provides you no assurances.

> How do I prevent this and still provide the source to everyone ?
>

Make sure your deserializing logic (on your own machine) is entirely 
under your control, and impervious to such attacks.  In general, the 
more types that can be encoded, the more likely it's vulnerable.  So 
authors of such libraries have two conflicting goals.

I can't tell you if pyro, or any other particular one is safe.  But if 
you decide to roll your own, which is implied when you say you'll be 
publishing your source, then keep it dirt-simple.  Have a very specific 
and finite set of classes which you'll handle, and write rigorous code 
to make sure the types are limited to those.  For example, you could 
restrict yourself to lists of strings, or lists of strings and floats, 
and you have only three decoders to write.

Note that DOS attacks are possible whatever encoding scheme you have. 
Make sure that self-references within the data are well-defined (or 
impossible), and put limits on size per transaction, and transactions 
per minute per legitimate user.

-- 
DaveA