На выходные экспериментировал с SQL иньекциями сайтов двух производителей сайтов в Новосибирске (не буду говорить кто именно — почему, поймёте чуть позже), результатами своих изысканий был сильно удивлён — не имея какой то специальной подготовки, обладая практически нулевыми знаниями в этой области, я в течение дня, с помощью только гугла взломал 45 сайтов.

Взломал — конечно сильно сказано, но хэши админских учёток от бэкофиса этих CMS в данный момент проходят процесс дешифрации (8 штук уже готовы).

Началось всё с телефонного звонка — мой друг, порекомендовал меня в качестве SEO оптимизатора одной производственной фирме — встретились, обговорили условия — хлопнули по рукам. Далее интереснее — ознакомился я с движком сайта, и пришел в полнейший ужас — в общем ЭТО движком у меня язык не поднимался назвать. Стиль программирования вообще пугающий — «группа школьников экспериментирующая на поприще создания сайтов», почитал договор — улыбнуло… Узнав сколько было выложено денег за этот «сайт» — сильно удивился !

В общем решили с заказчиком, что прежде, чем заниматься какой либо поисковой оптимизацией —

необходимо привести в порядок сам сайт — буквально на той неделе закончил перенос данных на новый самописный движек на codeigniter.

Далее я решил проверить бывший «движек» на предмет уязвимостей — зашел на сайт фирмы, ваяющей на таком «движке» — портфолио оказалось довольно внушающее, сграбил линки, открыл статейку по SQL Injections и начал эксперименировать … В конце рабоче дня 45 хэшей было запущено на декодирование 🙂

Вот думаю — может стоит выйти на владельцев сайта — предупредить, или предложить свои услуги, или в своих корыстных целях заюзать — например замаскированными ссылочками напичкать (а вот это уже

Сегодня уже чуть более профессиональным взглядом провел аудит безопасности ещё одного местного производителя сайтов, как оказалось с не менее сильным и убедительным портфолио — результат плачевен: прошли «на ура» элементарные SQL иньекции. Сильно заморачиваться со взломом не стал — т.к. таких целей не преследую, но факт меня удивил. Эксклюзивные, дорогие сайты с отличным уникальным дизайном оказались уязвимы к простейшему взлому.

Кстати — побывав в роли хакера, сейчас очень хорошо понимаю как именно и от чего нужно защищаться!
С удовольствием поделюсь некоторыми элементарными правилами, которые сильно затруднят хакеру возможность взлома Вашего сайта (и не только).

1. В за конченом проекте рекомендую вырубить все служебные сообщения (ошибки, предупреждения) — хороший источник служебной информации облегчающий взлом (например с помощью них легко выкупается абсолютный путь проекта на серваке).
2. Взять за правило проверять ВСЕ «входящие» переменные — цифровые сразу переводить в нужный тип intval(), (int), floatval(), (float), строковые фильтровать — такая педантичность практически исключает возможность иньекций.
3. Переменные в MYSQL запросов помещать в кавычки, «id=’$id’». Cтроковые переменные предварительно обрабатывать функцией mysql_real_escape().
4. Отдельное внимание уделить вопросам безопасности через .htaccess — запрет просмотра папок, по возможности доступ к админке с определенных IP адресов / областей.
5. Так же не помешает взять за правило во все папки бросать пустой index.html (если нет не пустого).
6. Не оставляйте «мусор» в доступных местах — старые php файлики, чего хуже — переименованные в какие нибудь .bak, .old и т.д.)
7. НИКОГДА и НИГДЕ не храните пароли в открытом виде — как минимум md5() хэширование ! А лучше перед md5() добавьте свою изюминку 🙂 например побитный XOR или тупо: прибавить по единичке к коду символа, добавить пару символов — хакер, потратив несколько дней на раскодировку md5 хэша, сильно удивиться когда раскодированный пароль не подойдёт.
8. Не используйте тривиальные названия таблиц/полей. Напр. табличка users с полями login и password сильно облегчат жизнь хакеру 🙂
9. Аккуратно используйте права на файлы, папки. Право на запись — потенциальное уязвимое место для того же php шелла — папки 755, фалы 644 !
10. Не менее аккуратно используйте права юзеров СУБД. Например привилегия работы с файлами file_priv несомненно ускорит взлом. (в 99% случаев такие привилегии абсолютно не нужны), ну и не ленитесь для каждого сайта создавать своего юзера с соответствующими правами.
11. Внимательно изучите настройки сервера по умолчанию (magic_quotes и прочие не помешают).
Ну и напоследок пару банальных:
12. НИГДЕ не используйте лёгких паролей (ftp, ssh, и т.д. и т.п.) — добавьте в пароль хотя бы один спец.символ, циферку и буковку, ну и выдерживайте длину хотя бы 6-8 символов.

13. Используйте резервные копии (как БД, так и файловые) — желательно ежедневно, автоматически и конечно же куда нибудь на географически удалённый источник.

// добавлено после взлома моего сайта

14. Скидываете ежедневные полные логи доступа на сторонний сервер (например на мыло, либо на другой сервак по ftp) — имхо лучше на мыло, т.к. даже в случае взлома злоумышенник получит только почтовый адрес.

15. Поставьте в крон скрипт, контролирующий изменения файлов — сверяющий контрольные суммы (md5) всех файлов (за исключением заданной маски) и отправляющий отчёт на мыло в случае нахождения изменений (не нашел готового — на днях сваяю). Так же можно поставить скриптик поиска веб-шеллов (но ИМХО уже перебор т.к. первого скрипта вполне достаточно).

16. Используйте кодирование своих исходных php файлов — злоумышленнику будет труднее внедрить свою инъекцию.

Так же «в догонку» могу порекомендовать пару скриптиков, которые запихиваются в крон и постоянно «палят» и в случае чего кричат «алярм» на мыло или SMS кидают. (имхо должны быть уже готовые варианты не знаю — можно погуглить на эту тему. В принципе, не трудно написать с нуля):
1. Анализ логов на предмет попыток взлома (напр. операторы select, union и т.д)
2. Изменение контрольных сумм в файловой структуре, а так же таблиц БД

Надеюсь ничего не пропустил…
Какие будут ваши рекомендации/пожелания ?

P.S.

Выкладываю некоторые ИМХО интересные ссылочки по теме, найденные мной в процессе:

• Hack FAQ
• Статья SQL Injection
• Заметка по EASY Shell
• Непосредственно  WSO Shell (php web shell)

и кое что из того, что давно искал и встретил на ачате

• socks на PHP
• proxy на PHP

P.S.S.

Кому интересно — могу провести аудит на предмет информационной безопасности Вашего сайта. Выходите на связь — договоримся.