Основной принцип написания безопасных программ - это контроль данных, приходящих от пользователя.
Может, имеет смысл как-то сразу записать мысль, что нужно контролировать не только данные, приходящие от пользователя, но, по возможности, вообще все данные. Как-то увязать это с SQL-инъекциями второго порядка и вообще сказать, что, в принципе, очень многие виды атак бывают не только первого, но и второго порядка. Иначе часто рассуждают в духе: "Ага! Эти данные не пришли от пользователя, они получены из безопасной базы данных (безопасной сессии и т.п.)!"
Можно также было бы добавить, что любая уязвимость - это *всегда* ошибка (как умышленная ошибка, как, например, с EVAL, когда человека предупреждали, а он не верил, так и неумышленная, когда, к примеру, забыли кавычки поставить при экранировании кавычек в SQL-запросе). То есть, задача поиска и исправления уязвимостей является частным случаем задачи поиска и исправления ошибок в программе. Можно было бы даже сказать, что любая ошибка - это потенциальная дыра в безопасности. Как вытекающий совет - вести логи всех ошибок, всегда реагировать на наличие ошибок и исправлять их.
Может, было бы полезно указать на то, что существут отличия между виртуальными и физическими файлами и для обращения к физическим файлам виртуальное имя, пришедшее от пользователя, никогда прямо использовать не нужно, а всегда реконструировать его из данных, полученных из других источников (например, хотя бы из БД) или ещё лучше делать физическое имя полностью независимым от виртуального - например, строить физическое имя только на основании числового идентификатора соответствующей записи в базе данных (типа 00/00/00/00/01.bin).
По поводу SQL-инъекции второго порядка, может, написать более выпуклые примеры, что данные могли быть взяты из БД, из сессии. Иначе обобщённое "уже лежащие на сервере" смотрится очень впукло (почти незаметно).
По поводу EVAL многих приходится уговаривать, что пользоваться им не нужно. Возражения типа "а как же ш мне тогда посчитать формулу а+б - иначе ж не возможно..." - это обычные возражения. Может, имеет смысл как-то тут указать, что в большинстве случаев эта функция используется *исключительно только* для уменьшения труда программистов, для которых это самое уменьшение труда *важнее* безопасности. И указать к примеру, мой пример про сложение и сказать, что более трудоёмко, зато безопасно - написать собственный или взять один из готовых калькуляторов.
В качестве отдельного раздела можно было бы указать на некоторые психологические особенности обеспечения безопасности:
- часто считают, что опасности нет, если о ней не думать. Пример с EVAL - яркий пример. Программисты, утверждающие, что ошибка не является дырой в безопасности, действуют примерно по такому же принципу. Думаю, в первую очередь подобным "страусиным" поведением прикрывается нежелание приложить усилия к обеспечению безопасности;
- не менее часто считают, что невозможно приложить слишком много усилий для обеспечения безопасности. В таком случае получается безопасная программа, которой невозможно пользоваться, так как в ней запрещено абсолютно всё. Тут можно было бы явно указать на то, что очень часто приходится искать компромисс между безопасностью и удобством использования, и что слишком жёсткие меры обеспечения безопасности не всегда оправданы;
- сильно часто путают действительно опасные вещи (уязвимости XSS, SQL-инъекция) с "яркими опасностями" (например, кража пароля, удаление базы данных и т.п.). То есть, считают, что чем "ярче" уязвимость (часто "ярче" означает "понятнее суть этой уязвимости"), тем она опаснее. И думать начинают, соответственно, не о том, что действительно может помочь обеспечению безопасности (то есть, к примеру, об одних только кавычках и слешах в случае SQL-инъекции), а обо всех опасностях, порождаемых этой инъекцией сразу (то есть, сразу пытаются думать и о паролях, и об удалении базы данных, воспринимая их как совершенно разные виды опаностей). Это и понятно, кража пароля - это гораздо интереснее и занятнее кавычек и слешей. Результат часто состоит в том, что вместо того, чтобы исправить причину (то есть, поставить кавычки и слеши), начинают говорить огород для каждой опасности отдельно (в случае с EVAL, например, проверяют все возможные входящие данные, которые могут привести к ошибке, вместо того, чтобы избавиться от самого EVAL).
применения. практически
применения. Практически
идентификатора. подробнее
идентификатора. Подробнее
Ссылки:
http://www.securitylab.ru/
Анализ уязвимостей в веб приложениях за 2007 и 1 квартал 2008 г.
http://www.securitylab.ru/analytics/313489.php
http://www.securitylab.ru/analytics/351464.php
http://www.securitylab.ru/analytics/293535.php - об MX-инъекциях
http://www.securitylab.ru/analytics/216311.php - На эту статью, может, не надо давать прямую ссылку - из-за размещённых там утилит для тестирования, которые не нужны начинающим. Но её можно посмотреть с точки зрения других аспектов безопасности.
http://www.securitylab.ru/analytics/216332.php - подробнее об СКЛ-инъекции. В общем-то, все выводы о том, как защититься, можно сделать из первой части этой статьи. Вторая часть только ещё подробнее описывает, как можно эксплуатировать СКЛ-инъекции.
http://www.cgisecurity.com/articles/xss-faq.shtml
Вот тут по поводу защиты Апаче:
http://www.securitylab.ru/analytics/216358.php
цикл статей по психологии безопасности:
http://www.securitylab.ru/analytics/350799.php
