On Jan 23, 2008 9:27 PM, Ivan Sergio Borgonovo <mail@webthatworks.it> wrote:
On Wed, 23 Jan 2008 15:04:56 -0200 "Greg Knaddison - GVS" <Greg@GrowingVentureSolutions.com> wrote:
call to fix this inside the API so that it was liberal in accepting any data and would do the filtering to prevent the holes as much as possible. That sounds like it does what you want.
Can you state in a positive manner what change you would like to see? Do you feel that prepared statements will be the solution to this problem?
It is just a db_query on steroids. If you still compose the prepared statement dynamically... you still get the chance to inject code but you don't cast in php, you should be able to use NULL (great once you start to use pk/fk) and you make the code of db_query much simpler making it easier to make it smarter.
Improving the abstraction of the DB layer should avoid most chances to get into trouble since queries will be built with prepackaged static parts and parameters, not anymore assembling strings in the modules.
This will not happen until the DB layer is abstracted via PDO or some other means. Talk to Crell (Larry Garfield) about his efforts in that direction (not before Drupal 7).
People make errors and if they have to take care about what is the proper way to use the API they will make more errors.
Have you checked this page and the child pages under it? http://drupal.org/writing-secure-code If they need improvement, please chip in.
As for a positive contribution to the sec process and for the people asking if anything was really screwed I'd suggest:
- kill the security@drupal.org email if you can't guarantee it is a reliable channel (spam/whatever)
It is reliable, but moderated. The team does not get anything from it unless someone check the queue and moderate it. Again, we are short of hands. - open a web form (I know there is one) and make it send an autoreply
with instructions and greetings immediately. The point is: offer just things you know will work. Reply promptly with no effort. Lower the chances people don't know what to do next.
Good suggestion. Copying the security list.
- just offer *official* reply through official channels, so that personality don't kick in.
At present all replies are written by humans. But an auto-reply is an idea worth considering. - be aware that once you decide to do voluntary job and be part of
a community you take the responsibilities that come with *your choice*. Being part of the sec team of a successful project as Drupal is like volunteering as a paramedic. Projects do get judged by their security response too, it is also a matter of image. Image is important for getting more dev involved. - keep the reporter informed [1] - Establish a code of conduit for sec team communications: You're dealing with someone you don't know that is aware of a security problem. You don't know his personality, you don't know his skills, you want information and hopefully collaboration: guide and pamper the reporter. The consequences of an unexpected behaviour may have a high cost in terms of sec and image. A code of conduit may make dealing politely with the issue nearly automatic, reducing the chances of frictions and the time required to formulate answers and make easier to delegate responsibility to reply if the one in charge is busy and the one left don't have the gift of diplomacy.
One more thing, for you and everyone else out there: Many of the queries we get are "my site was hacked into, please help". In 90% of the cases, it is not a Drupal problem at all, but many other attack vectors (writable directories to the web server, an intrusion via FTP or ssh, other applications installed, other accounts on the server, ...etc.) We are drafting a FAQ page for this, so as to decrease the load, and point the people to it via a URL. If you can help with this, email me off list. -- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting.