The system should not use dynamic code execution features such as eval().
Dynamic code execution features, despite the flexibility they provide, should be used carefully and generally avoided. These features often open the door for remote code execution (RCE) and cross-site scripting (XSS) attacks. Therefore, if it is not possible to avoid dynamic code execution, any untrusted input being included (e.g., the one provided by the users) should be properly sanitized.
This requirement is verified in following services:
- CAPEC™-19. Embedding scripts within scripts
- CAPEC™-242. Code injection
- CAPEC™-248. Command injection
- CWE-95. Improper neutralization of directives in dynamically evaluated code ("eval injection")
- CWE-915. Improperly controlled modification of dynamically-determined object attributes
- OWASP TOP 10-A3. Injection
- Agile Alliance-9. Continuous attention to technical excellence and good design
- MITRE ATT&CK®-M1013. Application developer guidance
- MITRE ATT&CK®-M1038. Execution prevention
- PA-DSS-5_2_7. Cross-site scripting (XSS)
- FedRAMP-CM-7_5. Least functionality - Authorized software, whitelisting
- ISO/IEC 27002-8_28. Secure coding
- NIST SSDF-PW_6_1. Configure the compilation, interpreter, and build processes to improve executable security
- OWASP SCP-7. Error handling and logging
- OWASP SCP-14. General coding practices
- CWE TOP 25-77. Improper neutralization of special elements used in a command (command injection)
- OWASP SAMM-IR_3. Code review process to discover language-level and application-specific risks
- OWASP ASVS-5_2_4. Sanitization and sandboxing
- C2M2-9_3_m. Implement IT and OT asset security for cybersecurity architecture
- SIG Lite-SL_89. Is there a formal Software Development Life Cycle (SDLC) process?
- SIG Core-I_2_1. Application security