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?
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.
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.