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.
As much as possible the Drupal project has used so far is to have security as a side effect of proper use of the API: i.e. if you use
[snip]
holes. The second major area of weakness, is in education about the existence of the APIs and the _proper_ way to use them.
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. If it is clearer what they can rely on it makes stuff easier and simpler, if the things they can rely on are more than the one with a red button with "self destruction" written on it would be even better. function A accept int may mean: a) function a will work just with int, explode in errors otherwise b) function a will break silently with anything but int c) if you let rubbish get in you may be exposed to a SQL injection I think a) is better than b) and may be a way to avoid c) earlier; at least things will reach the log and you've a chance to fix stuff. Or maybe it is just a matter of making the input type parameters in the docs <blink>. 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) - 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. - just offer *official* reply through official channels, so that personality don't kick in. - 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. Thanks to Derek who gave me just one more kick in my ass and woke me up from my dream, giving me one more opportunity to test if finding the positive side of all negative experiences is a rewarding hobby and unconsciously reminding me that computers are used by people and taking care of the human factor in security is a big slice of the equation and it is worth to insist on it. [1] this should address also the problems related to how to manage disclosures and how to fix the issues in a more elastic way even if you still may have a "preferred" or "suggested" way to deal with security -- Ivan Sergio Borgonovo http://www.webthatworks.it