Executing code dynamically is security-sensitive. It has led in the past to the following vulnerabilities:
Some APIs enable the execution of dynamic code by providing it as strings at runtime. These APIs might be useful in some very specific
meta-programming use-cases. However most of the time their use is frowned upon because they also increase the risk of maliciously Injected Code. Such attacks can either run on the server or in the client (example:
XSS attack) and have a huge impact on an application’s security.
This rule marks for review each occurrence of such dynamic code execution. This rule does not detect code injections. It only highlights the use of
APIs which should be used sparingly and very carefully.
Ask Yourself Whether
- the executed code may come from an untrusted source and hasn’t been sanitized.
- you really need to run code dynamically.
There is a risk if you answered yes to any of those questions.
Recommended Secure Coding Practices
Regarding the execution of unknown code, the best solution is to not run code provided by an untrusted source. If you really need to do it, run the
code in a sandboxed environment. Use jails, firewalls and whatever means your
operating system and programming language provide (example: Security Managers in java, iframes and same-origin
Do not try to create a blacklist of dangerous code. It is impossible to cover all attacks that way.
Avoid using dynamic code APIs whenever possible. Hard-coded code is always safer.
Sensitive Code Example
value = input()
command = 'os.system("%s")' % value
def evaluate(command, file, mode):
eval(command) # Sensitive.
eval(command) # Sensitive. Dynamic code
def execute(code, file, mode):
exec(code) # Sensitive.
exec(compile(code, file, mode)) # Sensitive.
exec(command) # Sensitive.
This rule is deprecated, and will eventually be removed.