Common Security Model / API

Common Security Model / API as a core module!

Defending against the unknown.

(I do not claim to be a software / Internet / development expert, and what I recommend here may very well exist, unbeknown to me.)

Summary:

My observation is that a variety of Drupal modules concerning email, each conducts it's own, individualised and different checks, specifically against email injection attacks. The code differs, methods vary and some implementations are more comprehensive than others. Undoubtedly the effective levels of defense will vary widely from module to module. Furthermore, there is no guarantee (or even an indication) that a particular module is secure or has any security features implemented at all. When scrutinising the code of modules it is often difficult to identify any security measures at all! This represents a worst-case scenario where many varied parts of the whole attempt to conduct their own defense in a multitude of different ways! I would suggest the development of a common Drupal security model as a project for the Google Summer of code.

Motivation:

It is a matter of time. Only a matter of time before the next big security exploit will take place. In Drupal, in PHP, in MySQL. Undoubtedly the holes are there, they just have not been identified yet.

My casual observation is that there are many different areas, modules and hacks within the Drupal Code-base where security is implemented. For example the bad-behaviour module attempts to analyse the behaviour of spam-bots while the feedback module implements a form of checking for injection exploits. Comparing the code in the Feedback module against PHP code posted on the Internet to counter email injection exploits would appear (to me at least) that the code in the feedback module does not look as complete. This is not saying that the code in the feedback module is ineffective. Simply, as a non-technical implementer of Drupal sites I just don't know.

While I am investigating other mailto/'mail this link' modules to be placed on Drupal sites, as an example, I don't have the time or indeed the expertise to check them all for the level of security against exploits. On the other hand, I am very aware of the risk that my IP address, which hosts dozens of websites, might become blacklisted as an originator of spam due to security exploits.

I can only presume a couple of things concerning Drupal and I admit that I may be entirely wrong:

This leads me to the observation that possibly there should be a common security model in Drupal. This should be a core module that can be updated rapidly in the event of a new security exploit. Through the Drupal API, calls can be made to the security module to vet objects such as strings to be emailed as an example. Thus all code in Drupal that deals with email can use this common security check.

Undoubtedly there are future security exploits that will occur. Conceptionally this security model cannot counter the unknown. But, should a future security exploit occur, the framework would exist where optimised code can be introduced into Drupal at short notice and all modules and other code sources can utilise that unified API to counter the attack. That would assure the person that implements a Drupal site that module XYZ is indeed able to counter the latest threat since it utilises the Drupal security API.

At present, if a number of modules have to implement counter measures individually and each in a different way with varied levels of security, it represents something close to a worst-case scenario. That is, if all modules implement the necessary security, something I just dont know at present.

Ideally there should also be code resident (or by means of an optional attached code base) where automated tests against security exploits can be conducted. At a minimum, the tests should verify things such as that all fields of a certain type are being checked/processed by the security API.

Conclusion

As stated, this functionality might exist already. From what I have seen from my limited viewpoint it does not and it is something that will most probably become necessary. Drupal is increasing exponentially in popularity and will most certainly become a prime target for security exploits, thus a security framework/model may become very relevant. The idea is to have code offering the best level of security available to developers through the Drupal API. Thus individual developers can concentrate on the module they are developing while persons specialising in countering security exploits can concentrate on security-related code. The current Drupal developers are very busy on individual projects and this is a system-wide project that should be undertaken by someone not already bogged in current development. Thus the 'Summer of Code' project might be ideal for this, especialy if someone with an extensive background in security can become involved. The scope of security issues may be far wider than just injcetion attempts on fields or emails. It might require a wide-ranging overview of Drupal.

I can olnly hope this will be valuable to the Drupal community.