2013-08-06 2 views
0

У меня есть файл на моем сайте под названием dbSettings.php с линиями:базы данных безопасности

<?php 
    $host = "localhost"; 
    $dbName = "database"; 
    $user = "user"; 
    $pwd = "pass"; 
    $db = new mysqli($host, $user, $pwd, $dbName); 
?> 

Я получаю эту страницу в моей главной странице с помощью функции require_once(). Есть ли какой-либо способ для тех, кто достигает этой страницы через сервер (мой домен), чтобы получить значения, хранящиеся в этих переменных? Это безопасный способ сохранить настройки базы данных?

ответ

3

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

  • Правильных прав доступа к файлам в файл, такие как
    chmod the file 640 instead of 600. Keep file ownership to your user and change group to webserver. This way, the webserver can only read and not modify it
  • Перемещения файлы из корневой директории поэтому его не доступен непосредственно другого
  • только дают нужно привилегии базы данных для этого пользователя базы данных
    If user just needs to access one database only give privileges for that database and data not give Structure or Administration related privileges if not needed
  • Если можно защитить с помощью
    .htaccess
    <files dbSettings.php> order allow,deny deny from all </files>
+0

Вы имеете в виду дать разрешение пользователю, что веб-сервер запущен как – Mike

+0

, который будет chmod до 600 и сделает владельца веб-сервера, но я считаю, что chmod до 640 хранит владельца файла отдельно и дает веб-серверу как группу лучше, потому что в случае компромисса они могут быть прочитаны только – PoX

+0

Я не говорю о файловом режиме, я говорю о владельце файла. Веб-сервер должен иметь доступ к учетным данным, а не к пользователю базы данных. Довольно это не тот же пользователь. – Mike

2

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

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

0

Из того, что я знаю о PHP безопасности, Есть несколько способов для этой информации протечек:

  1. Если dbSettings.php может быть каким-то образом загружен клиентом, без сервера обработки страницы. Это, очевидно, даст детали, так как они могут просто посмотреть на файл. Вообще говоря, если вы правильно настроили сервер и не создали резервных файлов, это не должно быть проблемой.
  2. Если dbSettings.php загружен клиентом, вы хотите удостовериться, что никакие ошибки не могут утечка информации (так, например, создание mysqli не может завершиться ошибкой и утечка информации). Поскольку ваше приложение не инициализировано, возможно, что вы регулярно маскируете ошибки.

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

+0

Это редкий случай, когда вы * не сможете писать где-то вне вашего веб-корня, даже на общем сервере. – Mike

+0

@Mike, Правда, но я не верю тому, что доступно на общем хостинге, пока я не увидел его собственными глазами. Конечно, по своему усмотрению это то, что вы настроили. Кроме того, если вы являетесь хостом, он очень строг, они не могут позволить вам получить доступ к таким файлам. Также (надеюсь) редкий случай. – MJD

+0

Я не уверен, что вы имеете в виду, не доверяя, пока не увидели это своими глазами. Независимо от того, какой общий хостинг вы используете, вы по-прежнему находились во власти администратора сервера. Любой, у кого есть корневой доступ, может обращаться к вашим файлам независимо от того, где и как они хранятся. – Mike

0

Убедитесь, что ваш dbSettings.php недоступен через URL-адрес, поэтому php должен иметь возможность читать этот файл, но этот файл не должен быть доступен, набрав его адрес в браузере (путем угадывания, удачи и т. Д.). Но если вы правильно настроили WW-сервер, вы должны быть в порядке, потому что php будет обработан, а пустая страница будет возвращена пользователю.

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

Кроме того, у вас никогда не должно быть эхо, дампа и т. Д. Этих значений из вашего php-кода на рабочем сервере, и вы также должны уловить любые ошибки из драйвера mysql, чтобы они не были распечатаны пользователю на рабочем сервере.

0

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

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

Если по какой-либо причине вы решите придерживаться конфигурационного файла в доступном месте, вы можете использовать трюк define() для предотвращения несанкционированного выполнения. Это делается путем определения константы в файле для включения файла конфигурации до фактического include(), а затем проверки наличия константы в самом файле конфигурации.

example.php:

<?php 
    define ('my_const', 1); 
    include ('config.php'); 

    echo $super_secret_data; 
?> 

config.php:

<?php 
    if (!defined ('my_const')) 
    die(); 

    $super_secret_data = 42; 
?> 

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

Смежные вопросы