Web Frameworks ¶
Evaluating The Security Of Frameworks¶
To evaluate the security of Python web frameworks, we're going to take a look at each item in the list of topics.
Access Control/Authorization¶
See access control.
What mechanisms are there to restrict URL access?
What permissions model is available?
How hard is it to define who should be able to access what?
Authentication¶
See authentication.
What authentication methods are available?
What hash method is used on user credentials? Is it salted?
Could account creation overwrite an existing account?
Could the change password or recover password functions be used maliciously?
Configuration¶
See configuration.
Are the framework dependencies up to date? Are there security vulnerabilities in the versions used by the framework?
Are there default account passwords?
If there an exception handler, will it run in production? Are there notes and reminders to turn it off in configuration?
Cross-Site Request Forgery (CSRF)¶
See cross-site request forgery.
Are there GET requests that change state? This helps enable CSRF.
What mechanisms are there to add CSRF tokens to forms? How easy is it to use?
Cross-Site Scripting (XSS)¶
See cross-site scripting.
What specific escaping does the template engine do to prevent XSS? What does the developer need to do to use it? What is automatic and what is manual?
Are there vulnerabilities in the template engine?
Cryptography¶
See cryptography.
We'd like to see frameworks provide the structure to do solid encryption in applications even if the framework itself doesn't need it. A configuration toggle to encrypt stored user data (if such a thing is handled by the framework) would be wonderful as well.
Does the framework provide a system for applications to encrypt data?
What algorithm is it using?
Where is the key stored?
Who can access the encrypted data?
Can developers easily encrypt user data?
Injection¶
See injection.
What interpreters is the framework capable of using?
How does it access a database? What about LDAP queries or OS commands?
What escaping is done on data headed to an interpreter?
Can a developer write raw SQL? If so, proper escaping is almost certainly not done. Documentation should have a large warning indicating they may be vulnerable to SQL injection.
Object Reference¶
See object reference.
Is there a mechanism to proxy direct object references through an indirect reference?
Redirects and Forwards¶
If there is skeleton code in the framework, can a URL be crafted to redirect to an arbitrary site?
In the framework documentation for doing redirects and forwards, is there a warning about using user-supplied data in the redirect location?
Session Management¶
See session management.
How are session IDs generated?
Are session IDs ever exposed in the URL? Leaking session IDs through logs, referrer headers, etc can lead to compromised accounts.
Are session IDs accepted through GET or POST data? This would aid in session fixation attacks.
Do session IDs timeout?
Can users log out?
When a user logs out, is the session invalidated?
Are session IDs changed after login?
Transport Layer Security¶
Can the framework be used with SSL? What is required and how difficult is it to set up?
When used in SSL mode, do session cookies have the 'secure' flag set?
Validation¶
See validation.
Is there a mechanism available that allows developers validate input data against a schema? Regex validation as well as custom attributes like numeric comparison. Having developers directly use the re module does not count.
-
Wiki content is available under a Creative Commons 3.0 License.
