2014-03-18 14:02 GMT+01:00 Dario Bertini <berda...@gmail.com>: > 2014-03-18 13:39 GMT+01:00 Manlio Perillo <manlio.peri...@gmail.com>: > > eval è relativamente sicuro, dato che può eseguire solo espressioni, e > non > > statement completi come exec. > > Lo puoi rendere ancora più sicuro limitando il namespace, ad esempio: > > purtroppo, non basta: > http://nedbatchelder.com/blog/201206/eval_really_is_dangerous.html > http://nedbatchelder.com/blog/201302/finding_python_3_builtins.html
Grazie, avevo dimenticato di disabilitare i builtins, ma sembra che ancora non basti. Allora, sempre usando gli strumenti già disponibili in Python, consiglio all'OP di guardare il codice della funzione ast.literal_eval. Esegue un eval, ma restituisce l'AST del codice compilato, in modo da validare il codice da eseguire. Risparmi un bel pò di tempo rispetto a pyparsing, perchè usi la grammatica di Python. Lo svantaggio è che probabilmente devi gestire più casi. > > > > Questo però non basta, devi avere il controllo anche su value, ad esempio > > accettando solo stringhe secondo un dato protocollo, di cui farai il > parsing > > e validazione. > > Il mio protocollo preferito è "Typed NetStrings": > > "<typeid><len>:<literal> > > Ad esempio per un intero: > > "i3:777" > > > > tale protocollo è facile da leggere, parsare e validare (perchè verboso) > > > > sembra simile a un Type-Length-Value > > http://en.wikipedia.org/wiki/Type-length-value > > Direi che è quello. > se possibile, preferite linguaggi regolari ad un TLV o altro formato > context-sensitive > > http://www.youtube.com/watch?v=v8F8BqSa-XY > http://langsec.org > > TLV non mi sembra abbia i problemi riportati in quei paper, ma non ho approfondito. Ciao Manlio
_______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
