On Wed, 23 Jan 2008 21:56:07 -0500 "Khalid Baheyeldin" <kb@2bits.com> wrote:
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?
If they need improvement, please chip in.
Pointing out that API should be used in the "proper way" was inspirational for me too. They look mostly a general guide. What I can read in the documents sounds like "you've to be careful and the places where you *may* have to be careful are a, b and c". People don't read docs, if you're lucky enough they read docs they want things that are easy to understand and remember. They read docs just when they strictly need them and there are more chances they will consult the api reference rather than a general guide about making code secure. Lacking a clear boundary between safe and unsafe functions people have to think. The few people that really enjoy to think, prefer to think tackling the problem they chose, not the "marginal stuff". Now make it more clear that if in the docs of the function you wrote array of int *it is up to the module writer* to pass an array of int. duck typing doesn't make it easy to make things explode in errors ASAP before it is too late without putting extra code down the path. Once you've to put extra code down the path to "explode in errors", just put extra code that filter at the cost of duplication. But still if there is a chance in API to write stuff that will explode in errors if input is not in the right format in spite of passing it down, it would be better. If a function filter input by its own make it clear, if some parameter disable filtering in a way it could be dangerous for security, make it clear. http://api.drupal.org/api/function/l/5 The risk is you're offering a map of functions that don't offer filtering, people will just download contrib and grep through it looking for the functions marked "not safe". I do not have any stats on this. Similar thread about disclosure just passed. If this is not acceptable write in the front page of the api that developers should look twice at the input parameters of functions. That's for simple types and SQL injection. For XSS I'd make more explicit that some functions filter some do not.
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.
A form can offer advantages a mailing list does not. Including a way to filter spam and all requests for assistance in security issues that don't pertain to the sec team. Add some drop down, put a text around it saying it is not the right place etc... You can turn it into a private issue queue/ticketing system easier and no private email and such... the reply will be the one of the sec team, no matter who is in charge. A form can offer immediate feedback if everything went OK. Email can get lost, even your autoreply. Still send the autoreply, people prefer to read emails and they can keep a copy of the instructions.
- 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.
Not only an autoreply... but some forms to be filled by sec team to keep the poster informed. eg. - someone did really read what you wrote - we couldn't replicate the problem - we confirm the problem - please, send a POC - we are going to address the problem: fixing the module, fixing core,... - we expect a fix to get in, be published in.... This will have a lot of good side effects including:
- 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.
You can build up 4 or 5 prepared forms for replying... I think you'd have more experience in what people are asking to get a list of prepared forms. I think one of the FAQ is when are you going to release a SA, the other 2 more frequent should be: did you get my message?, do you confirm there is a sec problem? Just speculating... and these things could have prepackaged answers. Plus you're halfway to have a workflow.
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.
Unless there are things that are strictly related about how drupal is done I'd point to all the good material out there about general security. You'd generally point to better material than what you could generally write by yourself and you save the time to write it and keep it updated. Other than stuff related to coding for dev and how to set writing permissions on /files and settings.php and some advice if you've to deal with web designer accessing templates I can't think of anything that is suited to administrators and it is peculiar to drupal. The first good advice that doesn't require too much culture to be managed and decide upon is put down the site if you can, change the passwords (even if this is not going to save your ass for long), backup, watch the logs. Everything else is going to take too deep understanding, it offers too many options etc... People that have a clue will go further without any extra help. People that don't have a clue can't build up a culture on forensic, incident management... when it is too late and anyway it is stuff that goes beyond drupal. There is a lot of docs that somehow hides what's peculiar to drupal even eg. for cvs stuff and patch. -- Ivan Sergio Borgonovo http://www.webthatworks.it