У меня есть одностраничное приложение, в котором браузер выполняет всю логику.За исключением начальной загрузки, сервер в значительной степени представляет собой необычный интерфейс для базы данных.
Браузер отправляет, например, ключи словаря данных, пары имя / значение столбца и предложения where для SELECT.Сервер собирает части в SQL, выполняет запросы и отвечает.NEW: например, в SELECT имя таблицы и извлекаемые столбцы взяты из словаря данных - браузер предоставляет ключ словаря данных и предложение SELECT where.
Эта очень открытая среда очень чувствительна к SQL-инъекциям.атаки.Цель состоит в том, чтобы предотвратить урон от указанных атак.
Проблемы, которые необходимо преодолеть
Во-первых, как обсуждалось , невозможно параматизировать случайноеSELECT where clause - SELECT не может использовать подготовленные операторы.
Во-вторых, mysqli, библиотека для параметризованных операторов с MySQL, не поддерживает ни NULL, ни функции MySQL, например, CURRENT_DATE или NOW (), как обсуждено .
Предлагаемое решение
Сначала, если SELECT не может быть параметризован, затем выполните SELECT пользователем, который не имеет прав DML или DDL.Это предотвратит атаки базы данных SQL Injection Attacks.
Во-вторых, напишите функцию-оболочку для mysqli, которая позволит передавать функции NULL и MySQL в качестве параметров.Это позволит легко использовать параметры для всех DML.
В-третьих, теневые высокочувствительные данные, когда они не могут быть просмотрены или затронуты обычными запросами или обычными пользователями.Это выведет конфиденциальные данные, такие как пароли, из диапазона атак.
Далее, напишите порядок обертки для обеспечения связи типа пользователь / запрос.Это обеспечит выполнение SELECT пользователем select, например
Результатом этого усилия будет здесь .Вопрос в том, логично ли этот подход успешно защитить от атак SQL-инъекций?
Не отвечающие ответы
Я предлагал этот же вопрос до .Из-за моей плохой работы по презентации полученные ответы и комментарии в конечном итоге были сосредоточены на ложных вопросах, а не на решении (по общему признанию) сложного вопроса - действительно ли это работает?
В качестве ссылки, вот некоторые из этих комментариев иответы.
Использовать подготовленные операторы PDO
Во-первых, подготовленные операторы нельзя использовать для всех SELECT - как помогает PDO?Во-вторых, mysqli не принимает функции NULL или MySQL - как помогает PDO?
Зачем заново изобретать колесо
Если вам известен подход, который преодолевает эти проблемы, я бы действительноочень хотелось бы знать - это сложная проблема.
нет mysql_real_escape_string() в поле зрения
Значения должны быть обработаны перед передачей в функции запроса к базе данных.mysql_real_escape_string() - это одна из множества доступных дезинфицирующих функций, например, можно использовать другое дезинфицирующее средство для дат.
слишком много работы
Пожалуйста, поделитесь со мной своими знаниями о любом подходе, которыйпреодолевает эти проблемы - мне бы очень хотелось лучше понять.Тем не менее, после того, как я снова все настроил, после моих записей это заняло от 30 до 45 минут.Впоследствии никаких затрат времени не будет.
Я доволен mysqli
Как вы собираетесь предотвратить атаки с использованием SQL-инъекций, когда вы не можете параметризовать свой SELECT?Ожидаете ли вы никогда не использовать NULL при обновлении столбца?У каждого свой яд, но я надеюсь решить эти проблемы, а не жить с ними.
@ Konerack указывает на ограниченное число параметров
Верно.Изменено на код для использования eval() (дрожь), что решило проблему.Требуется проверка безопасности.
Вопрос снова
Будет ли этот подход защищать от атак с использованием SQL-инъекций при преодолении проблем отсутствия параметризованного SELECT и ограничений параметров mysqli?