Функция безопасного соединения с БД?

Question

Функция безопасного соединения с БД?

0

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

Я думал, что это обеспечит уничтожение переменных db_ * после использования функции и подключение к соответствующей базе данных:

<?php
function dbconn($db_hostname='localhost',
                $db_username='',
                $db_password='',
                $db_database='database1'
                $db_object='connection') {

    if($db_username=='' && $db_password=='') {
        switch ($db_database) {
            case 'database1':
                $db_username='user1'; 
                $db_password='pass1';
                break;
            case 'database2':
                $db_username='user2'; 
                $db_password='pass2';
                break;
            default: 
                echo "No database defined to connect to";
                break;
        }
    }
    else if($db_password=='') {
        switch ($db_username) {
        case 'root':
            $db_password='rootpass';
            break;
        case 'user':
            $db_password='userpass';
            break;
        default:
            echo "No password known for this user";
            break;
        }
    }

    $db_object= new mysqli($db_hostname, $db_username, $db_password, $db_database);
    if ($db_object->connect_error) die($db_object->connect_error);
} 
?>

Bendy 11 нояб. 2014, в 11:12

Источник

Теги:

php

security

function

sqlconnection

1 ответ

Ещё вопросы

Sven Slootweg · Accepted Answer · 2014-11-11T08-13-00.000Z

Мне непонятно, что вы пытаетесь сделать, из кода, который вы предоставили. Однако я могу ответить на ваш вопрос: "Что такое безопасный способ подключения к базе данных?"

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

1. PHP файл в качестве вашей конфигурации

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

Пример файла конфигурации (db_config.php):

<?php

$db_host = "localhost";
$db_user = "username";
$db_pass = "password";
$db_database = "database_name";

Вам просто require('db_config.php'); в вашей инициализации/заголовке /etc. код.

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

2. Сериализованный конфигурационный файл

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

Однако вы никогда не должны помещать этот файл в свой корень документа. Что касается вашего веб-сервера, то файл JSON или YAML является "видимым" файлом, и он с радостью покажет его любому, у кого есть URL.

Правильный способ использования JSON/YAML/etc. файл в качестве файла конфигурации, должен удостовериться, что он размещен вне корня документа, так что веб-сервер не может обслуживать его до пользователя. Попытки дать ему "неописуемое" имя недостаточно.

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

Другие соображения

Есть еще три основных момента, которые я хочу здесь остановиться.

Несколько учетных данных базы данных

В исходном коде похоже, что вы пытаетесь добавить функцию, в которой вы можете выбрать базу данных, которую вы хотите выбрать. На самом деле это почти никогда не то, что вы хотите. Каждый сервер/установка должен иметь свои собственные учетные данные.

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

Общая безопасность

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

PDO или `mysqli_`?

Судя по вашему фрагменту кода, вы используете mysqli_. Хотя это может быть правильным выбором, если вы правильно используете параметры/подготовленные запросы, я бы не рекомендовал его использовать. PDO - независимая от базы данных библиотека SQL, которая в большей степени фокусируется на параметризованных запросах. Он включал по умолчанию более или менее каждую последнюю установку PHP, и в качестве бонуса он позволит вам переключаться между разными SQL-серверами.

Использование параметризованных ("подготовленных") инструкций абсолютно критично - это единственный надежный способ предотвращения инъекций SQL, который, кажется, является самой важной проблемой, которую вы хотите защитить отсюда. GoooD вводное руководство можно найти здесь.

Привет Свен, спасибо за такой подробный ответ :) Мой код был попыткой адаптировать PHP-файл как «динамический» файл конфигурации ... причина в том, что я думал, что переменные, заполненные именем пользователя и паролем соединения, будут быть восприимчивым к тому, чтобы они echo "$db_password"; через инъекцию хаков (!?) .... я тоже загляну в PDO - большое спасибо :)
@Bendy Возможно, вы захотите взглянуть на stackoverflow.com/questions/60174/…
@Volodya, большое спасибо - я только что прочитал на PDO ... звучит как четкий выбор из sqli из того, что я прочитал. Я постараюсь перейти на PDO сегодня вечером ...!
@Bendy Единственная ситуация, когда можно было бы вывести параметры подключения к базе данных, была бы, если вы используете переменные переменные и используете пользовательский ввод для определения имени переменной (что на самом деле не то, что вы должны когда-либо делать - это почти так же опасно как eval ). Если вы действительно обеспокоены этим - например. у вас есть коллега, который может сделать это - вы можете использовать unset, чтобы (как следует из названия) «сбросить» переменные, содержащие учетные данные базы данных после их использования.
Спасибо, Свен, я просто начинающий хобби, поэтому у меня нет кода для коллег, о котором нужно беспокоиться ... только мой собственный;) ... и спасибо всем остальным - я думаю, что теперь понимаю и читаю вокруг PDO - я продано :) Насколько я понимаю, функциональность bindParam защищает строки переменных от запросов к базе данных - поэтому нет риска внедрения кода.
@ Бенди Ваше понимание верно :) Он в основном передает значения отдельно от самого запроса.

Функция безопасного соединения с БД?

1 ответ

1. PHP файл в качестве вашей конфигурации

2. Сериализованный конфигурационный файл

Другие соображения

Несколько учетных данных базы данных

Общая безопасность

PDO или mysqli_?

Ещё вопросы

PDO или `mysqli_`?