Real-World Python Application Security Scanning With ThunderScan SAST
1. How popular Python really is?
Python programming language is becoming increasingly popular in application development and it is easy to see why. Python is simple, clean, and very powerful, therefore no surprise it is used in variety of use cases – ranging from simple and handy Python scripts, but also used effectively in very complex AI/ML implementations and Web Application development with powerful Web Development frameworks. Extensively adopted and used by large enterprises business like Google, Facebook, Spotify, Netflix, Dropbox and many more, we can be sure that Python will stay here for some time to come.
With wide ranging purposes and adoption Python as a programming language naturally draws security implications and raise questions – How secure is Python? Well, that depends… Even though Python is well designed, and with use of popular Python frameworks, some security features are included by design, however code that is produced in Python can still be insecure. Robust and secure code essentially depends on secure coding practices that are being used during the application development.
Even with Python’s strong security foundations, there are some well known security issues with vulnerabilities such as SQL Injections, Cross-Site Scripting, Code Injections, Path Traversal, to name a few, that exist in Python applications. This is why it is so critical to conduct regular security scans and audits of source code written in Python.
2. Real-world Python application source code scanning
DefenseCode provides SAST (Static Application Security Testing) and DAST (Dynamic Application Security Testing) tools for security scanning of Python applications, both security scanning of the applications source code and security scanning of live (web/internet facing) applications.
We will show some common Python security issues in a real-world Python based application source code that has already been scanned by another security vendor and focus on high risk security vulnerabilities that were previously missed by the other SAST tools.
Latent issues in code continue to be a major challenge to business regardless of size, these are issues that have gone undetected despite peer reviews or use of tools.
Real-world Python application that will be scanned for the purpose of this blog post is Earthgecko Skyline application (source code available on GitHub – https://github.com/earthgecko/skyline/).
“Skyline is a near real time anomaly detection system, built to enable passive monitoring of hundreds of thousands of metrics, without the need to configure a model/thresholds for each one, as you might do with Nagios. It is designed to be used wherever there are a large quantity of high-resolution time series which need constant monitoring.”
First, initiate new DefenseCode ThunderScan SAST scan of Skyline application source code.
As it can be seen from a previous ThunderScan screenshot, to scan the source code of the Skyline application, ThunderScan SAST needs to be provided with a ZIP archive of the application code (or a repository such as from Github), choose a scan name and select a target language (in this case Python), or select “Auto-language Recognition”, and click on the START button.
3. See how DefenseCode ThunderScan really makes a difference
In a matter of minutes, we are presented with a deep source code security scanning results of the Skyline application.
As we can see from the previous screenshot, 18 SQL Injection vulnerabilities were detected by DefenseCode ThunderScan SAST that went undetected during the security scan from another SAST vendor. Now we can examine and triage each reported security issue and prioritize vulnerability risks.
Looking more closely at one specific SQL Injection vulnerability data/code flow. With DefenseCode ThunderScan SAST it is straightforward and easy to examine vulnerabilities and their progress through the source code.
As we can see from a previous screenshot, user input is received from an HTTP request with request.args on line 168 of /skyline/webapp/backend.py and copied into the metric variable. Further on line 172 in the same file, SQL query is constructed in variable query using string concatenation by copying metric variable into the SQL query string. SQL query string with user input is further passed as an argument to the function mysql_select() in file /skyline/skyline_functions.py on line 1228 as a select variable argument. Further in the same file on line 1330, select variable is copied into the query variable and in the end passed unsanitized into a sensitive sink function execute() on line 1334, thus resulting in a high risk SQL Injection vulnerability.
ThunderScan SAST also keeps detailed track of identified vulnerabilities in the source code, so it is easy to navigate and track down previously identified vulnerabilities in the source code, as show on the screenshot below.
More details about SQL Injection vulnerabilities can be found on OWASP:
“A SQL injection attack consists of insertion or “injection” of a SQL query via the input data from the client to the application. A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file present on the DBMS file system and in some cases issue commands to the operating system. SQL injection attacks are a type of injection attack, in which SQL commands are injected into data-plane input in order to affect the execution of predefined SQL commands.”
Interestingly, with a closer investigation of the source code, associated with the Skyline application, we can see attempts to prevent SQL Injections but those measures were not actually enforced nor fully implemented. As it can be seen on the code snippet below, there is Python code which would try to escape the whole SQL query, which of course would not prevent the SQL Injection vulnerabilities, since it is done on the whole SQL query. Moreover, this part of code is never actually executed since this is an ‘else’ clause which is never true.
4. Conclusion – Risk of not checking applications for security vulnerabilities
Not performing source code security audits can result in situations where high risk vulnerabilities escape into production-level code, potentially resulting in a hazardous security breach. Implementing high-quality SAST products early in the software development process and CI/CD pipeline is an imperative. Delaying security audits and being reactive rather than proactive in identifying security vulnerabilities has been proven consistently to be much more expensive and not nearly effective as an early stage SDLC (Software Development Life Cycle) static application security testing. Our recommendation would be to use automated code inspection early and often in the development process. Of course, worst thing is not checking security of deployed applications at all. Find out more about DefenseCode ThunderScan SAST and DefenseCode WebStrike DAST for static and dynamic application security testing.
