скрытие конфигурации на веб-сайте [дубликат]

Сколько запросов мое приложение сможет обрабатывать одновременно с этим утверждением?

Это сильно зависит от вашего приложения. Каждый новый запрос будет иметь поток запущен - он зависит от того, сколько потоков ваша машина может обрабатывать. Я не вижу возможности ограничить количество потоков (например, uwsgi-предложения в производственном развертывании).

Каковы недостатки этого использования? Если я не ожидаю более нескольких запросов одновременно, могу ли я продолжать использовать это?

Переход от одного потока к многопоточному может привести к ошибкам параллелизма ... if вы используете это, будьте осторожны с тем, как вы обрабатываете глобальные объекты (см. объект g в документации!) и состояние.

353
задан AviD 13 January 2011 в 08:53
поделиться

17 ответов

Несколько человек неправильно понимают это как вопрос о том, как хранить пароли в базе данных. Это не правильно. Речь идет о том, как сохранить пароль, который позволяет получить доступ к базе данных.

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

207
ответ дан Farray 21 August 2018 в 11:26
поделиться
  • 1
    Благодарю. Если я это правильно пойму, тогда в файле php будет добавлен файл конфигурации, позволяющий ему использовать пароль. например Я создаю файл с именем «app1_db_cfg.php», в котором хранятся логин, pword и amp; имя db. Тогда моя страница application.php включает «app1_db_cfg.php», и я в бизнесе! – user18359 19 September 2008 в 01:40
  • 2
    Я согласен с тем, что конфигурация должна быть надлежащим образом защищена. Однако знание того, как это сделать, - это дело системных администраторов, а не разработчиков. В этом случае я не согласен с ценностью сильного шифрования. Если вы не можете защитить свой файл конфигурации, что заставляет вас думать, что вы можете защитить свои ключи? – user11318 21 September 2008 в 21:04
  • 3
    Я предпочитаю использовать учетную запись базы данных, которая разрешена только для доступа к базе данных с веб-сервера. И тогда я не буду зашифровывать конфигурацию, я просто храню ее за пределами веб-корня. – gnud 25 April 2009 в 09:01
  • 4
    Я использую переменную окружения apache для установки пути, так что даже путь к файлу неизвестен в исходном коде. Это также прекрасно позволяет иметь другой пароль для разработки и производства, основанный на настройках Apache на сервере – geedew 12 March 2014 в 15:07
  • 5
    Имейте в виду, что даже файлы, хранящиеся за пределами доступного в Интернете каталога, должны быть прочитаны скриптом, который их использует. Если кто-то включает этот файл, то выгружает данные из файла, они будут видеть пароль. – Rick Mac Gillis 8 November 2014 в 20:33

Мы решили это следующим образом:

  1. Использовать memcache на сервере с открытым подключением с другого сервера паролей.
  2. Сохранить в memcache пароль (или даже все файл password.php зашифрован), а также ключ дешифрования.
  3. Веб-сайт вызывает ключ memcache, содержащий парольную фразу пароля и дешифрует в памяти все пароли.
  4. Сервер паролей отправьте новый зашифрованный файл паролей каждые 5 минут.
  5. Если вы используете зашифрованный пароль.php в своем проекте, вы отправляете аудит, который проверяет, был ли этот файл затронут извне - или просмотрен. Когда это произойдет, вы автоматически можете очистить память, а также закрыть сервер для доступа.
3
ответ дан Asi Azulay 21 August 2018 в 11:26
поделиться

Лучший способ - не хранить пароль вообще! Например, если вы находитесь в системе Windows и подключаетесь к SQL Server, вы можете использовать Integrated Authentication для подключения к базе данных без пароля, используя идентификатор текущего процесса.

Если вам нужно подключиться к паролю, сначала зашифровать его, используя сильное шифрование (например, используя AES-256, а затем защитить ключ шифрования или использовать асимметричное шифрование и защитить ОС от сертификата), а затем сохранить его в файле конфигурации (за пределами веб-каталог) с сильными ACL.

3
ответ дан AviD 21 August 2018 в 11:26
поделиться
  • 1
    Нет смысла шифровать пароль снова . Кто-то, кто может получить незашифрованный пароль, также может получить любую фразу для шифрования пароля. Однако, используя ACL & amp; .htaccess - хорошая идея. – uliwitness 23 September 2012 в 14:46
  • 2
    @uliwitness Я думаю, что вы, возможно, неправильно поняли - что вы подразумеваете под & quot; encrypt again & quot ;? Это просто шифрование. И вы не хотите использовать кодовые фразы (предназначенные для использования человеком), чтобы зашифровать их, а довольно сильное управление ключами, например. защищенной ОС, таким образом, чтобы простой доступ к файловой системе не предоставлял доступ к ключу. – AviD 23 September 2012 в 16:29
  • 3
    Шифрование не является магии - вместо того, чтобы защищать ключ AES с помощью списков ACL, вы можете просто сохранить там пароль. Нет никакой разницы между доступом к AES-ключу или расшифрованным паролем, шифрование в этом контексте - просто змеиное масло. – MarioVilas 27 April 2014 в 19:47
  • 4
    @MarioVilas whaat? Если пароль зашифрован, ключ шифрования, защищенный ОС, как нет разницы? Шифрование не является магическим - оно просто сжимает всю секретность в меньший ключ шифрования. Вряд ли snakeoil, в этом контексте это всего лишь перемещение всей этой секретности в ОС. – AviD 28 April 2014 в 07:25
  • 5
    @AviD, почему ОС может защитить ключ, но не данные сами? Ответ: он может защитить оба, поэтому шифрование действительно не помогает. Было бы иначе, если бы были сохранены только данные и был получен ключ шифрования, например, из пароля, который должен был быть напечатан пользователем. – MarioVilas 22 September 2014 в 11:45

, если возможно создать соединение с базой данных в том же файле, где хранятся учетные данные. Вставьте учетные данные в оператор соединения.

mysql_connect("localhost", "me", "mypass");

В противном случае лучше отключить учетные данные после инструкции connect, поскольку учетные данные, которые не находятся в памяти, не могут быть считаны из памяти ;)

include("/outside-webroot/db_settings.php");  
mysql_connect("localhost", $db_user, $db_pass);  
unset ($db_user, $db_pass);  
11
ответ дан Bob Fanger 21 August 2018 в 11:26
поделиться
  • 1
    Если у кого-то есть доступ к памяти, вы все равно ввернуты. Это бессмысленная подделка. Вне webroot (или, по крайней мере, защищенный .htaccess, если у вас нет доступа к вашему веб-сайту) является единственным безопасным вариантом. – uliwitness 23 September 2012 в 14:48
  • 2
    – Luke A. Leber 9 January 2017 в 07:22
  • 3
    Как насчет echo $ db_user или печати $ db_pass? Даже разработчики из одной команды не могут определить производственные учетные данные. Код не должен содержать ничего, что можно было бы распечатать о информации для входа. – Mohammed Joraid 28 June 2017 в 15:40

Поместите пароль базы данных в файл, сделайте его доступным только для чтения пользователю, обслуживающему файлы.

Если у вас есть какие-то средства, позволяющие процессу php-сервера обращаться к базе данных, это довольно много всего, что вы можете сделать.

5
ответ дан Chris 21 August 2018 в 11:26
поделиться

Раньше мы сохраняли DB пользователя / pass в файле конфигурации, но с тех пор попадали в параноидальный режим - применяя политику Defense in Depth .

Если ваше приложение скомпрометировано , пользователь получит доступ к вашему конфигурационному файлу и, следовательно, есть вероятность, что взломщик сможет прочитать эту информацию. Файлы конфигурации также могут попасть в управление версиями или скопировать серверы.

Мы переключились на сохранение пользовательских / pass в переменных среды, установленных в Apache VirtualHost. Эта конфигурация читается только root: надеюсь, что ваш пользователь Apache не работает как root.

Кон таким образом, что теперь пароль находится в глобальной переменной PHP.

To смягчите этот риск, мы имеем следующие меры предосторожности:

  • Пароль зашифрован. Мы расширяем класс PDO, чтобы включить логику для дешифрования пароля. Если кто-то читает код, где мы устанавливаем соединение, не будет очевидно, что соединение устанавливается с зашифрованным паролем, а не с самим паролем.
  • Зашифрованный пароль перемещается из глобальных переменных в частная переменная Приложение делает это немедленно, чтобы уменьшить окно, доступное в глобальном пространстве.
  • phpinfo() отключен. PHPInfo - это легкая цель получить обзор всего, включая переменные среды.
4
ответ дан Courtney Miles 21 August 2018 в 11:26
поделиться

Храните их в файле вне веб-корня.

36
ответ дан da5id 21 August 2018 в 11:26
поделиться
  • 1
    А также, как упоминалось выше, вне контроля источника. – Frank Farmer 26 May 2009 в 21:46
  • 2
    мы могли бы включить его? например в PHP мы можем тогда сделать include('../otherDirectory/configfile.conf')? – mtk 5 January 2013 в 19:23
  • 3
    Вы все предлагаете хранить учетные данные вне wwwroot. Хорошо, я понимаю фон безопасности. Но как он должен храниться в контроле версий тогда (образец конфигурации)? Обычно wwwroot является корнем git repo, поэтому, если есть что-то снаружи - оно будет вне VC. Представьте себе, что новый разработчик пытается создать локальный экземпляр для разработки - как он должен знать магию, как «взять этот файл, скопировать его за пределы и заполнить»? – The Godfather 10 August 2018 в 18:17
3
ответ дан e-satis 21 August 2018 в 11:26
поделиться

Самый безопасный способ - вообще не иметь информацию, указанную в вашем PHP-коде.

Если вы используете Apache, это означает установить данные соединения в файле httpd.conf или virtual hosts файл. Если вы это сделаете, вы можете вызывать mysql_connect () без параметров, что означает, что PHP никогда не будет выводить вашу информацию.

Вот как вы указываете эти значения в этих файлах:

php_value mysql.default.user      myusername
php_value mysql.default.password  mypassword
php_value mysql.default.host      server

Затем вы открываете свое соединение mysql следующим образом:

<?php
$db = mysqli_connect();

Или вот так:

<?php
$db = mysqli_connect(ini_get("mysql.default.user"),
                     ini_get("mysql.default.password"),
                     ini_get("mysql.default.host"));
34
ответ дан Funk Forty Niner 21 August 2018 в 11:26
поделиться
  • 1
    Проверьте правильные значения ini_get («значения по умолчанию») php.net/manual/en/class.mysqli.php – Val 15 June 2012 в 14:08
  • 2
    Можно ли использовать это в своем файле .htaccess? – user 18 August 2012 в 18:49
  • 3
    да, но любой пользователь (или хакер, злоупотребляющий плохо написанным скриптом php) может прочитать пароль через ini_get(). – Marki555 21 March 2016 в 18:50
  • 4
    @ Marki555 but any user (or a hacker abusing badly written php script) can read the password via ini_get() Как вы справляетесь с этим? – tonix 22 May 2016 в 10:20
  • 5
    Marki555 заявляет, что злоумышленник, который может запускать PHP-код, может также вызывать функции PHP, что, очевидно, правдиво и невозможно что-то сделать. Я также хотел бы добавить, что я больше не следую рекомендациям, которые я даю в этом ответе, но вместо этого использую переменные среды. Концепция аналогична: не храните свои учетные данные в коде, а вводите их как-то. На самом деле не имеет значения, используете ли вы ini_get() или getenv(). – Lars Nyström 23 May 2016 в 08:32

Если вы говорите о пароле базы данных, в отличие от пароля, поступающего из браузера, стандартная практика, похоже, заключается в том, чтобы поместить пароль базы данных в файл конфигурации PHP на сервере.

Вы просто должны быть уверены, что файл php, содержащий пароль, имеет соответствующие разрешения на него. То есть он должен быть доступен только для веб-сервера и вашей учетной записи пользователя.

4
ответ дан Jason Wadsworth 21 August 2018 в 11:26
поделиться
  • 1
    К сожалению, файл конфигурации PHP может быть прочитан phpinfo (), и если кто-то оставит некоторый тестовый скрипт за счастливым злоумышленником, он сможет прочитать пароль. Вероятно, лучше оставить пароль для подключения в файле за пределами корня веб-сервера. Тогда единственный способ получить к нему доступ - либо с оболочкой, либо с помощью произвольного кода, но в этом случае вся безопасность все равно будет потеряна. – MarioVilas 27 April 2014 в 19:51

Если вы используете PostgreSQL, он автоматически заглядывает в ~/.pgpass для паролей. Дополнительную информацию см. В руководстве .

5
ответ дан Jim 21 August 2018 в 11:26
поделиться

Если вы размещаете на чужом сервере и не имеете доступа за пределы вашего веб-сайта, вы всегда можете поместить свой пароль и / или соединение с базой данных в файл, а затем заблокировать файл с помощью .htaccess:

<files mypasswdfile>
order allow,deny
deny from all
</files>
92
ответ дан kellen 21 August 2018 в 11:26
поделиться
  • 1
    Спасибо, это именно то, что я искал. – David Gladfelter 11 August 2009 в 15:48
  • 2
    Полезно, если оно действительно безопасно, хотя кажется, что логин в shell будет по-прежнему иметь доступ. – Kzqai 14 April 2010 в 17:10
  • 3
    Определенно, но если у кого-то есть доступ к оболочке, вся ваша учетная запись была скомпрометирована. – kellen 16 April 2010 в 19:59
  • 4
    Это плохая практика, потому что вы можете случайно передать свои учетные данные в репозиторий. – Porlune 7 June 2016 в 02:54
  • 5
    @Porlune: разработчики должны заставить свою систему контроля версий игнорировать файл паролей, то есть с помощью .gitignore. Но да, следует позаботиться о файлах, содержащих конфиденциальные данные. – kellen 7 June 2016 в 15:41

Это решение является общим, поскольку оно полезно как для открытых, так и для закрытых исходных приложений.

  1. Создайте пользователя ОС для своего приложения. См. http://en.wikipedia.org/wiki/Principle_of_least_privilege
  2. Создайте (несеансную) переменную среды ОС для этого пользователя с паролем
  3. Запуск приложения в качестве этого пользователя

Преимущества:

  1. Вы не будете проверять свои пароли в исходном контроле случайно, потому что вы не можете
  2. Вы случайно не повредите права доступа к файлам. Ну, вы можете, но это не повлияет на это.
  3. Может быть прочитано только root или этим пользователем. Root может все равно читать все ваши файлы и ключи шифрования.
  4. Если вы используете шифрование, как вы безопасно храните ключ?
  5. Работает x-платформа
  6. Be обязательно не передавать envvar ненадежным дочерним процессам

Этот метод предложен Хероку, который очень успешен.

13
ответ дан Neil McGuigan 21 August 2018 в 11:26
поделиться

Для чрезвычайно безопасных систем мы шифруем пароль базы данных в файле конфигурации (который сам защищен системным администратором). При запуске приложения / сервера приложение затем запрашивает системный администратор для ключа дешифрования. Затем пароль базы данных считывается из файла конфигурации, дешифруется и сохраняется в памяти для будущего использования. Все еще не на 100% безопаснее, поскольку он хранится в дешифрованной памяти, но вы должны называть его «достаточно безопасным» в какой-то момент!

33
ответ дан pdavis 21 August 2018 в 11:26
поделиться
  • 1
    что, если администратор умрет? – Radu Murzea 3 May 2013 в 19:47
  • 2
    @RaduMurzea, это смешно. Когда вы слышали о смерти умирающих администраторов? Они похожи на Макдональдса, они просто появляются / исчезают из ниоткуда! – ILikeTacos 23 January 2015 в 19:43
  • 3
    @Radu Murzea Просто у вас есть 2 или более администратора, тогда у вас есть паритет, как массив рейдов. Шансы более чем одного диска, которые не работают одновременно, намного ниже. – element11 24 September 2015 в 15:23
  • 4
  • 5
    Не уверен, что вы подразумеваете под «хранением в памяти». Веб-приложения PHP обычно не хранят ничего в памяти дольше, чем время, необходимое для ответа на отдельный запрос, чтобы увидеть страницу. – bdsl 12 August 2017 в 10:16

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

  1. запретили доступ к базе данных с любых серверов за пределами вашей сети,
  2. старайтесь не показывать пароль пользователям (в сообщении об ошибке или через Файлы PHP случайно выполняются как HTML и т. Д.).
3
ответ дан Raptor 21 August 2018 в 11:26
поделиться

Я думаю, что OP означает пароль базы данных.

Если кто-то не получает доступ к вашему серверу через FTP или SSH (в этом случае вы уже подключены), я бы не стал беспокоиться о сохранении паролей в открытый текст в файлах PHP. Большинство приложений PHP, которые я видел, делают это так, например phpbb.

5
ответ дан Ryan Bigg 21 August 2018 в 11:26
поделиться
  • 1
    В случае сбоя на сервере / конфигурации, в результате чего php-файлы отображаются как текст, а не выполняются, этот подход будет раскрывать пароль. Ввод пароля в отдельный файл из веб-каталога (как было предложено другими) будет немного более безопасным – Jamil Said 30 November 2017 в 05:16
  • 2
    Джамиль, вы все предлагаете хранить учетные данные вне wwwroot. Хорошо, я понимаю фон безопасности. Но как он должен храниться в контроле версий тогда (образец конфигурации)? Обычно wwwroot является корнем git repo, поэтому, если есть что-то снаружи - оно будет вне VC. Представьте себе, что новый разработчик пытается создать локальный экземпляр для разработки - как он должен знать магию, как «взять этот файл, скопировать его за пределы и заполнить»? – The Godfather 10 August 2018 в 18:52

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

Кроме того, что вы находитесь на правильных строках с минимальным доступом для используемой учетной записи. Добавьте к этому

  • Не используйте комбинацию имени пользователя / пароля для чего-либо еще
  • Настройте сервер базы данных только для приема соединений с веб-узла для этого пользователя (localhost еще лучше, если БД находится на одной машине) Таким образом, даже если учетные данные будут раскрыты, они никому не нужны, если у них нет другого доступа к машине.
  • Обфускать пароль (даже ROT13 будет делать ), он не будет много защищать, если некоторые из них получат доступ к файлу, но, по крайней мере, это предотвратит его случайный просмотр.

Peter

7
ответ дан Vagnerr 21 August 2018 в 11:26
поделиться
Другие вопросы по тегам:

Похожие вопросы: