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
--
http://mail.python.org/mailman/listinfo/python-list
