Нормально ли устанавливать значение rejectUnauthorized равным false в производственных соединениях PostgreSQL?

#node.js #postgresql #ssl #heroku-postgres #pg-promise

#node.js #postgresql #ssl #heroku-postgres #pg-обещание

Вопрос:

Недавно мы перешли на Heroku, и при попытке подключить наши приложения к БД он продолжал отклонять наши запросы с сообщением «Самоподписанный сертификат». Передача rejectUnauthorized решена для этого, но теперь мне интересно, должны ли мы делать это в производстве? Если нет, то каков подходящий для нас способ подключения к нашим базам данных Heroku PG?

 const pgp = require('pg-promise')(/*initOptions*/);
const {ConnectionString} = require('connection-string');

const cnObj = new ConnectionString(process.env.DATABASE_URL);

const cn = {
  host: cnObj.hostname,
  port: cnObj.port,
  database: cnObj.path?.[0],
  user: cnObj.user,
  password: cnObj.password,
  ssl: {
    rejectUnauthorized: false,
  },
};

const db = pgp(cn);

1. Исправлен код для лучшего ConnectionString использования. Кроме этого, это не проблема с pg-promise , это строго конфигурация аутентификации, которая рассматривалась много раз ранее — ищите связанные проблемы .

2. Вы докопаетесь до истины, если просто будете следовать этой теме .

3. Спасибо @vitaly-t. Как всегда, спасает

Ответ №1:

Риск, которому вы подвергаетесь, заключается в том, что кто-то становится между вами и сервером Heroku и выдает себя за последнего. Затем они могут предоставить вам свой собственный сертификат и согласовать с вами соединение. Человек в середине также может передать вам вызов с сервера и использовать ваш ответ для входа на сервер базы данных вместо вас.

Все это предполагает, что злоумышленник контролирует один из сетевых узлов между вами и сервером Heroku.

Итак, я бы сказал, что, хотя существует остаточный риск, я бы не стал терять слишком много сна из-за этого, если только вы не работаете с действительно конфиденциальными данными, и в этом случае паранойя является достоинством.

1. Отклонено. Если они могут выдавать себя за сервер, а сервер Postgres использует метод аутентификации на основе пароля (который, я думаю, использует Postgres на Heroku), злоумышленник также может перехватить пароль. IMO это неприемлемо.

2. Пароль никогда не отправляется во время аутентификации по паролю. Но вы правы, злоумышленник все еще может войти в систему. Я исправлю ответ.

3. Спасибо, снова проголосовал. для информации, похоже, Heroku использует метод аутентификации MD5 по умолчанию ( postgresql.org/docs/current/auth-password.html ). Это действительно не отправляет пароль через туннель, вместо этого отправляется представление имени пользователя / пароля / соли в формате MD5 ( pgcon.org/2014/schedule/attachments / … ) — смотрите этот ответ, чтобы узнать мнения по этому поводу: security.stackexchange.com/questions/41064 /…

4. @Michael Принятый ответ на вопрос, на который вы ссылаетесь, совершенно неверен для многих учетных записей. На самом деле, способ, которым PostgreSQL использует MD5, безопасен, за исключением того, что хэш дешев для вычисления, что упрощает атаку методом перебора.

5. Не уверен, что это «совершенно неправильно». Возможно, это недостаточно подчеркивает использование случайной соли. Размышляя об этом дальше, злоумышленник MITM может просто запросить у клиента аутентификацию по паролю открытым текстом. Клиент npm, используемый в вопросе, основан на github.com/brianc/node-postgres который поддерживает аутентификацию открытым текстом, и это решает сервер. Итак, неприемлемо.