pyscg-0021: Exclude Developer Tools From the Final Product
Keep design tooling in separate packages from the actual product and supply useful logging.
Design tooling for functional tests, performance tests, or troubleshooting increases the attackable surface making a product more vulnerable [MITRE 2023]. A need to include them in a final product typically originates from missing the concept of staged testing with separate packaging of the product and required design tooling. Designers only using high privileged users for troubleshooting is often the root cause for badly designed logging that forces the operator to also use highly privileged or shared accounts in production.
Anti-patterns:
- Printing debug information directly to stdout or to the web-interface
- Ports left open such as 22 for ssh or 5678 for debugpy
- Verbose logging enabled in production sites.
- Monkey patching [Biswal 2012].
- Hidden functions enabling/disabling verbose logging via external interfaces.
- Hidden functions providing a shell for troubleshooting.
- Operators need of root or superuser access for troubleshooting
- Test tools and results available in the product
- Designing directly on a live instance.
Not knowing that a product must be deployed differently in production than in staging can leave well known entry points wide open. [Hammond 2022]. Well written test-driven design can avoid the need to have such excessive troubleshooting design tooling as seen in Flask.
Non-Compliant Code Example (Monkey Patching)
In noncompliant01.py, a monkey patch replaces the process_payment method at module level with a debug version that prints sensitive internal state to stdout and logs verbose object details. This type of patch is often introduced during development for troubleshooting and should not be left in the production deployment. This exposes internal data and increasing the attack surface.
""" Non-compliant Code Example """
import logging
class PaymentProcessor:
"""Class to process payments"""
def process_payment(self, amount):
"""Process a payment transaction"""
logging.info("Processing payment of %s", amount)
# Payment processing logic
return True
def patched_process_payment(self, amount):
"""Monkey-patched method that logs sensitive details for debugging"""
print(f"DEBUG: Payment amount: {amount}, processor state: {self.__dict__}")
logging.debug("Full payment details: %s", self.__dict__)
return True
# Monkey patching left in production code
PaymentProcessor.process_payment = patched_process_payment
#####################
# exploiting above code example
#####################
processor = PaymentProcessor()
processor.process_payment(99.99)
Compliant Solution (Monkey Patching)
The compliant01.py solution keeps the class method intact and uses Python’s logging module, and never “print”, with an appropriate log level to control verbosity.
""" Compliant Code Example """
import logging
logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(__name__)
class PaymentProcessor:
"""Class to process payments"""
def process_payment(self, amount):
"""Process a payment transaction"""
logger.info("Processing payment of %s", amount)
# Payment processing logic
return True
#####################
# exploiting above code example
#####################
processor = PaymentProcessor()
processor.process_payment(99.99)
In compliant01.py, the code behaviour matches the source, logging is controlled through configuration rather than code modification, and no sensitive internal state is exposed.
Automated Detection
| Tool | Version | Checker | Description |
|---|---|---|---|
| Bandit | 1.7.4 on Python 3.10.4 | Not Available | |
| Flake8 | 8-4.0.1 on Python 3.10.4 | Not Available |
Related Vulnerabilities
| Component | CVE | Description | CVSS Rating | Comment |
|---|---|---|---|---|
| ceph-isci-cli Red Hat Ceph Storage 2,3 | CVE-2018-14649 | ceph-isci-cli package as shipped by Red Hat Ceph Storage 2 and 3 is using python-werkzeug in debug shell mode. This is done by setting debug=True in file /usr/bin/rbd-target-api provided by ceph-isci-cli package. This allows unauthenticated attackers to access this debug shell and escalate privileges. | CVSS 3.xx: 9.8 | |
| OpenStack ironic-inspector, ironic-discovered | CVE-2015-5306 | When debug mode is enabled, might allow remote attackers to access the Flask console and execute arbitrary Python code by triggering an error. | CVSS 2.x: 6.8 |
Related Guidelines
Bibliography
| [Biswal 2012] | Biswal, B. (2012). Monkey Patching in Python [archived]. Internet Archive Wayback Machine. Available from: https://web.archive.org/web/20120822051047/http://www.mindfiresolutions.com/Monkey-Patching-in-Python-1238.php [accessed 3 January 2025] |
| [Hammond 2022] | DANGEROUS Python Flask Debug Mode Vulnerabilities [online]. Available from: https://www.youtube.com/watch?v=jwBRgaIRdgs [accessed 3 January 2025] |