Как предотвратить атаку SQL Injection в приложениях, запрограммированных в Zend Framework?

Question

У меня нет понятия о безопасности ZF. Нужно ли использовать фильтр при работе с базой данных? Может быть, связывания достаточно? Как насчет этого:

$users->update($data, 'id=1');

Должен ли массив данных как-то фильтроваться? Не стесняйтесь писать все, что вы знаете о проблеме.

Не могли бы вы дать несколько ссылок на хорошие статьи о безопасности в ZF (в основном о SQL Injection и XSS)?

Answer 1

Краткий ответ
Хотя ZF принимает и предоставляет некоторые меры для защиты вашего приложения, вы все равно должны применять те же меры предосторожности, которые вы использовали бы без Zend Framework.

---

Что касается вашего кода, ознакомьтесь с главой по Zend_Db в Справочном руководстве :

По умолчанию значения в вашем массиве данных вставляются с использованием параметров. Это снижает риск некоторых типов проблем безопасности. Вам не нужно применять экранирование или кавычки к значениям в массиве данных.

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

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

Примечание , поскольку вы используете Zend_Db_Table, очевидно, третий аргумент является вторым аргументом. Внутри экземпляр таблицы будет делегировать вызов адаптеру БД, причем первым параметром будет имя таблицы экземпляра таблицы.

---

Относительно векторов атаки Zend_View и XSS:

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

Опять , большинство из которых не означает все. Zend_View предоставляет Zend_View :: escape () , чтобы помочь вам очистить вывод, но в этом нет ничего особенного.

Answer 2

Та же концепция действительна для Zend Framework и для любого другого веб-приложения / библиотеки / любой другой информации, которая манипулирует пользовательскими данными:

Всегда проверяйте пользовательский ввод. Не верь один.

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

Проверка должна ВСЕГДА выполняться на стороне сервера. Также должна присутствовать проверка на стороне клиента, чтобы обеспечить лучшее взаимодействие с пользователем.

В случае Zend, пожалуйста, обратитесь к странице проверки из руководства.

Answer 3

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

Параметр запроса

$alpha = new Zend_Filter_Alpha();
$name = $alpha -> filter($this -> _request -> getParam('name')); //while processing url parameters

База данных

$int = new Zend_Filter_Int();
$select -> where("id = ?", $int -> filter($id)); //during db processing also

Также в элементах формы. Я пропущу это, поскольку пример этого может быть найден обильно.

Answer 4

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

echo $this->escape($this->foo);