Рецензия на книгу М.Фленова "PHP глазами хакера"
Михаил Фленов. PHP глазами
Увидел в торренте. Скачал. Открыл. Собственно, написание слова "хакера" логотипом известного одноимённого журнала - уже достаточная информация об этом произведении. Но я увидел на обложке, среди перечисления основных тем книги, и такую: "Защита SQL-инъекции в PHP" (от кого защита?)
Заинтересовался. 161-я страница. Ознакомился.
Итак.
Раздел 3.8.2.Атака SQL Injection
Привожу дайджест, следующий за ходом мысли гениального писателя.
1. Начинаем с простого. DELETE from table where id=1 or name="Администратор". Следует глубокий вывод о необходимости применения регов для замены всего, что не цифры, на пустую строку.
2. "Со строками нужно поступать так же. Как добиться, чтобы хакер не смог вести недопустимый символ и взломать базу данных? В строках могут использоваться буквы и иногда пробелы". Далее аффтар демонстрирует рег, который оставляет от строки только цифры, пробелы и латинские буквы (вообще, судя по всему, все примеры кода в книге - цельнотянутые с какого-то англ.яз. источника без каких-либо попыток адаптации).
3.Наконец-то аффтар вспоминает, что кроме пробелов и букв в базе могут лежать и другие символы. Тут мне остаётся только цитировать, с небольшими комментариями:
"Регулярное выражение "/^a-zA-Z9-0 /i" запрещает любые специальные символы, но иногда они бывают необходимы. Например, в поле могут быть символы [ и ]. Да, это может быть вполне безобидно для запроса, но не все символы безопасны. Давайте рассмотрим, что никогда нельзя разрешать:
- Одинарные и двойные кавычки. Такие символы используются в запросах для выделения. (ЙАД они выделяют!)
- знак равенства (далее следует пример, который демонстрирует чудовищную уязвимость с его помощью)
- два тире подряд (также с примером)
- точка с запятой
- символы коментариев /* */
- "Если поле может содержать слишком большое количество перечисленных выше специальных символов, то я рекомендую запретить ещё и имена основных операторов SQL: insert,update,delete, or, and и т.д."
- "Особое значение в SQL играет ключевое слово union..."
- круглые скобки
(далее фантазия отправилась совсем уж в свободный полёт):
- "Чтобы усложнить взломщикам поиск ошибок в запросе, можно запретить использование сравнения '1'='1 (видимо, запрета символа = оказалось недостаточно)
далее следует три страницы ужасов, которые ожидают программиста, который забыл запретить комбинацию '1'='1
по окончании ужасов товарищ переходит к следующему разделу:
4. Всё. Раздел закончился. Тема SQL Injection ис-чер-па-на!
Последующие разделы не менее интересны
3.8.3. Работа с файлами.
Два абзаца, сводящихся к одному предложению "Хакеры очень часто используют SQL-команду into outfile". Никаких рекомендаций по борьбе с этим злом не даётся. АААА! Это незакрываемая дыра!
Зато в следующем пункте такая рекомендация есть.
3.8.4. Практика работы с базами данных.
Нет. Это что-то феерическое. Один этот раздел стоит всего остального текста. Это надо видеть!
Автор ставит перед нами ужасно сложную проблему... Но с блеском её решает:
Занавес.
Дальше, извините, ниасилил.
Если непонятно, почему это бред, читаем статью Защита от SQL-инъекций
Написать комментарий
Пожалуйста, воздержитесь от посылки спама.
Сообщения, содержащие гиперссылки, проходят премодерацию.