module security
hutchic - December 4, 2008 - 21:39
In evaluating drupal for use at work I'm wondering what's being proactively done about module security.
From my limited reading I believe I can safely make the following assumptions but would like to be corrected:
- a module has full access to the database
- the DAL offers no form of protection by design ie $db->select('query'); gets filtered to only do a select
- a module/block/theme's output doesn't go through any form of output escaping strategy by default
- there is no review prior to a module being included in the drupal module listings
- modules are currently not required to go through any form of functional/unit testing although it looks like that is changing
- modules do not include any database table permission acl definition that are enforced by drupal ie I need to read from this table, I need to update that one etc
- does the security team implement any sort of fuzzing, owasp, phpids, sql injection detection, static code analysis et al
Overall drupal looks like a well developed platform. I understand the challenges in securing code developed by an outside party. Don't take any of the above personally just looking for some answers that I couldn't explicitly find in the documentation.
Thanks
a few answers
1) correct
2) correct, though the db_rewrite_sql does add the node access system limitations and can be used by other modules to alter things as they see fit.
3) Somewhat correct - there are tools for filtering output (input formats, filter_xss_admin, check_plain). It's basically impossible to have a default filtering mechanism because of the varied and rich nature of content in Drupal. For example, having output escaping that blocks javascript would make it hard to write a the googleanalytics module.
4) I've pinged AJK to answer.
5) Modules will likely never be required to do this. It is up to the module consumer (i.e. you) to verify that they are good. You could limit yourself to those modules which have tests, but that decision is a case-by-case issue.
6) I don't think I understand this question.
7) Some members of the team do some things like that, but it's not a standardized part of our process.
If you have an interest in this I encourage you to get more involved in the security of Drupal. There is a group at http://groups.drupal.org/security-scanner-component-and-best-practices that works on issues like automated security testing.
--
Growing Venture Solutions | Drupal Dashboard | Learn more about Drupal - buy a Drupal Book
CVS applications review
Regarding:-
It is true that current CVS account holders are free to commit and publish without review. In fact, if a review were required you would probably find less than 10% of the current stock of modules available.
However, what we do when a new person applies for a CVS account to contribute is, they are required to provide a link where their intended contribution can be downloaded and reviewed.
The CVS application review isn't harsh and steadfast. However, it's main concerns are that the applicant is "security aware" and follows Drupal best practices. Review failures at this stage result in a decline of their application and a brief note as to why.
http://drupal.org/node/59 explains more.