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