Python is a great development language for so many reasons. Its developers enjoy huge library support. Do you want to deploy a simple web server or implement a RESTful API? There are modules for that. Capture, analyze, and visualize network traffic flow? There are simple and free modules for all of that, too.
Developers using Python can create a prototype in minutes that may have taken days in other languages. It should come as no surprise that Python has been used to implement some of the biggest open-source projects: OpenStack, Ansible and Django, to name a few.
Unfortunately, along with ease-of-use comes ease of introducing security errors.
The vast majority of common insecure coding practices in Python are not specific to Python at all and will be familiar to anybody that has ever read the “
OWASP Top 10” or the
“SANS Top 25”: OS command injection, insecure use of temporary files, and the use of insecure libraries or cryptographic functions. Luckily, these findings and many others can be detected early using a tool called
Bandit.
Bandit parses each file into a representative Abstract Syntax Tree (AST) and looks for calls, strings and other elements usually associated with insecure code. By analyzing the AST, Bandit can reliably find calls such as the following:
subprocess.Popen(command_to_execute, shell=True)
It’s worth noting that either of these two markers by themselves are safe: the default “Popen” command requires parameterized arguments, and “shell=True” may be a perfectly safe argument to another function, but in combination, they create a command injection vulnerability. The “subprocess.Popen” documentation has a bright red warning:
But who
REALLY reads documentation anyway? Command injection is one of the most common bugs that Bandit detects in projects.
Bandit was designed with several goals in mind:
- High configurability – What’s appropriate for one project may not be for another.
- Extensibility – It should be easy for a developer to extend a Bandit plugin or even to create their own.
- Filterable – Penetration testers may tolerate a high level of noise that is not appropriate in an automated gate check.
Since Bandit is not a full “static analysis” tool, it’s very lightweight and can be run against large projects quickly without consuming extensive system resources. It’s freely available open-source software and has been used and extended by many organizations.
Example output from Bandit showing two findings and overall scan metrics
To find out more about Bandit and how to use it like a pro, please attend the
BSides SF talk: “
When Bandit(s) Strike – Defend Your Python Code” at 1:30 PM on Monday, February 13.
About the Author: Travis McPeak is a Sr. Security Architect for IBM Cloud. He is a core developer of the Bandit project and is actively involved with OpenStack, Cloud Foundry, and the Bay Area OWASP Chapter. In his spare time he loves travel, snowboarding, and quality food/beer. You can follow him on Twitter and LinkedIn.
Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.
