Driving continuous improvement for Python security
Not long ago I said our goal for Python analysis this year was to Kick Asp & Take Names. Today I'm proud to report that we're making good on that promise, with regular deposits of new functionality.
Through the end of April, we delivered Python 3.8 support, additional taint analysis rules, and support in such rules for dictionaries and keyword arguments in both SonarQube and SonarCloud. Since then, we've focused on making Django and Flask development more secure.
The most important part of that is the detection of Cross-Site Scripting (XSS) vulnerabilities in DTL and Jinja2 templates. While not strictly Python, these HTML files are used by Django and Flask to generate output to the user. These templates contain symbols that are interpolated at runtime, which makes them part of the attack surface of a Django or Jinja2 project and a prime target for XSS attacks. Fortunately, rule S5131 "Endpoints should not be vulnerable to reflected cross-site scripting (XSS) attacks" can now detect such vulnerabilities. This is a big deal because XSS is the most common vulnerability type fixed by open-source Python developers.
We've also added an XSS-related Security Hotspot for template engines: S5247 "Disabling auto-escaping in template engines is security-sensitive". As a reminder, Security Hotspots are uses of security-sensitive code. Depending on the context, they may or may not be problems; human review is required. (For a full explanation of Security Hotspots, check out this recent post on the topic.) So this new rule will find all the places where auto-escaping has been turned off, and the Security Hotspot workflow will help you review them efficiently. That's in addition to the pre-existing Security Hotspot S5247, which checks auto-escaping in code.
Cross-Site Scripting is number "A7" in the OWASP Top 10, which is a list of the most significant risk categories in web development today as determined by a broad community of security experts. We're making OWASP Top 10 coverage a priority for Python (and across languages), so we're proud to have added coverage in three other categories as well:
A2 Broken Authentication
- S4433: LDAP connections should be authenticated
A3 Sensitive Data Exposure
- S5547: Cipher algorithms should be robust
- S4830: Server certificates should be verified during SSL/TLS connections
A6 Security Misconfiguration
- S5542: Encryption algorithms should be used with secure mode and padding scheme
- S4502: Disabling CSRF protection is security-sensitive
In addition to all these new rules, we've also beefed up the existing taint analysis rules to properly recognize Flask endpoints (Django was already covered) as sources of user-provided data. That means for instance that the rule to detect SQL-injection vulnerabilities now recognizes uses (and mis-uses) of `Flask.Request`, and can raise issues on missing or unsafe converters for captured values.