defensive-coding-guide/modules/ROOT/pages/programming-languages/Python.adoc

52 lines
1.7 KiB
Text

:experimental:
:toc:
include::partial$entities.adoc[]
= The Python Programming Language
Python provides memory safety by default, so low-level security
vulnerabilities are rare and typically needs fixing the Python
interpreter or standard library itself.
Other sections with Python-specific advice include:
* xref:tasks/Tasks-Temporary_Files.adoc#chap-Defensive_Coding-Tasks-Temporary_Files[Dealing with temp files]
* xref:tasks/Tasks-Processes.adoc#sect-Defensive_Coding-Tasks-Processes-Creation[Creating Safe Processes]
* xref:tasks/Tasks-Serialization.adoc#chap-Defensive_Coding-Tasks-Serialization[Serialization and Deserialization], in
particular xref:tasks/Tasks-Serialization.adoc#sect-Defensive_Coding-Tasks-Serialization-Library[Library Support for Deserialization]
* xref:tasks/Tasks-Cryptography.adoc#sect-Defensive_Coding-Tasks-Cryptography-Randomness[Randomness]
== Dangerous Standard Library Features
Some areas of the standard library, notably the
`ctypes` module, do not provide memory safety
guarantees comparable to the rest of Python. If such
functionality is used, the advice in xref:programming-languages/C.adoc#chap-Defensive_Coding-C[Defensive Coding in C] should be followed.
== Run-time Compilation and Code Generation
The following Python functions and statements related to code
execution should be avoided:
* `compile`
* `eval`
* `exec`
* `execfile`
If you need to parse integers or floating point values, use the
`int` and `float`
functions instead of `eval`. Sandboxing
untrusted Python code does not work reliably.
== Sandboxing
The `rexec` Python module cannot safely sandbox
untrusted code and should not be used. The standard CPython
implementation is not suitable for sandboxing.