[development] Think there's a security problem in your module? Here's what to do.

[Ivan Sergio Borgonovo]

On Wed, 23 Jan 2008 21:56:07 -0500
"Khalid Baheyeldin" <kb at 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?

> http://drupal.org/writing-secure-code

> 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 at 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