Вот у меня возник такой вопрос. Вы очень часто говорите о защите от атак всяких злых дядек, именующих себя "хакерами". Мой будущий сайт представляет собой биржу труда и образовательных услуг на WEB технологиях, следовательно его нужно сделать достаточно устойчивым от всяких некорректных действий. Если можно, расскажите мне о наиболее часто применяемых методах хакерских атак, наверняка Вы сталкивались с ними очень часто. А я попробую учесть Ваш опыт и принять меры по защите от деструктивных действий. Был бы очень Вам благодарен. С уважением, Денис.
Вообще "хакер" это человек непонятный. В большинстве случаев это просто "обчитавшийся" хакерских мануалов юзер, которому нечего делать в интернете. Реже встречаются настоящие профи, но вероятность того, что они заинтересуются Вашим проектом невелика, если Вы конечно не веб-мастер сайта Микрософта %)
Сайт могут ломать с несколькими целями. Первой и наиболее простой является получение какой-либо "скрытой" информации с него. Вторая более сложная, ломание сайта как некий этап взлома всей системы или сети. Например, с помощью ваших неграмотных скриптов хакер может получить какие-либо настройки системы для дальнейшего взламывания. Но главное правило построения защищенных копроративных сетей есть вытаскивание веб-сервера в демилитаризованную зону, т.е. размещение его во внешней части корпоративной сети с отделяющим сетевым экраном. Иногда (хотя скорее почти всегда) веб-сервер вообще не подключен к корпоративной сети, а например к провайдеру. Поэтому взлом веб-сервера не может нанести угрозы внутренней сети и хакеру с ним возиться "себя не уважать". В итоге можно с большой уверенностью сказать, что взломом сайтов занимаются для получения "скрытой" информации с него или для крушения системы (например, чтобы сайт не мог функционировать).
Все атаки по основным признакам можно разделить на внутренние и внешние. Внешние атаки идут из сети. Они чаще всего связаны с нарушением функционирования и реже с получением информации (потому как издалека файл сложно прочитать), поэтому их последствия не так страшны (если не учитывать потерь от простоя сайта). Внутренние атаки могут исходить от пользователей сервера и, что самое страшное, от администратора. Эти атаки уже больше связаны с получением информации, чем с нарушением функционирования (т.к. администратору это ничего не стоит %), поэтому могут носить более тяжкие последствия. Пользователи сервера могут без разрешения просматривать Ваши данные или даже исходники (если скрипт на Перле).
Сейчас мы разобрались только с теми, кто нас может атаковать. Теперь давайте разберемся с методами "защиты".
Самый главный принцип (и не только защиты CGI :). Заключается в проверке любых данных получаемых скриптом.
Обязательно надо проверять содержимое на наличие запрещенных символов и их последовательностей. Например, почтовый адрес должен обязательно содержать @ и хоть одну точку. Если этих признаков нет, то адрес введен не верный и его нельзя использовать.
Надо осуществлять проверку на допустимую длинну. Опять применительно к почтовому адресу, если Вам передали адрес длинной больше 100 символов, то это очень странно. Лучше попросить ввести другой и покороче :)
Если Вы используете элементы <select>, то проверяйте действительно ли содержимое данного поля принадлежит набору допустимых значений.
Если полученные данные содержат имя файла или системную команду, то проверяйте куда ведет путь и что может вытворить команда.
Это большей частью относится к пользователям Unix систем. Никогда не храните скрипты в каталогах с открытым на запись доступом. Ваш скрипт могут перезаписать или удалить другие пользователи сервера. Создавайте для своих скриптов отдельные каталоги с запретом на запись. При этом не забывайте сделать правильные настроками веб-сервера в этом каталоге, чтобы сервер мог использовать скрипты.
Конечно же совершенно секретные данные на веб-сервер размещать нельзя. Защищать надо все, что носит хоть какой-то признак приватности. Например, к приватным данным можно отнести пароли, номера кредитных карт, почтовые адреса пользователей, их имена и т.д. Когда я рассказывал про внутренние атаки я имел в виду именно этот тип данных. Если Вы скопили достаточно большой список пользователей с их почтовыми адресами, то он может служить объектом атак внутренних пользователей. Не секрет, что можно продавать списки адресов спамерам или пользователям, которые любят регистрироваться от чужого имени. Про пароли и номера кредитных карт я вообще молчу (их уже можно отнести к секретным). Зная такие данные можно творить вообще, что душе угодно. Из-за этого не надо надеяться на честность админа или пользователей. Человеческий фактор самый страшный, если машина предать не способна, то человеку это "раз плюнуть".
Поэтому при записи приватных данных на локальные диски или в базы данных все шифруйте. Давайте именам файлов непонятные названия, например, вместо password.dat назовите файл colors.dat или 12pqe23.dat %) Такие имена не привлекают внимание и при условиях шифровки внутренностей будут считаться простым мусором %)
Также при использовании Cookies не забывайте, что все данные, которые Вы отправили клиенту может просмотреть любая программа. Например, дырявый браузер может вызвать утечку секретных данных, таких как пароль, логин и т.д. Передавайте все такие данные в зашифрованном виде. Браузеру все равно, что он записывает, а Вам не все равно. Помните, что каждый перехваченный пароль увеличивает возможность проникновения в Ваш скрипт (или систему, в которой он работает). Особенно если Ваш скрипт обеспечивает удаленное управление системой (например, банерообменником, гостевой книгой и т.д.). Человек с повышенными правами может Вам все попортить...
Система отчета сильно Вам поможет при обнаружении ошибок или попытках взлома. Записывайте в лог-файл все нестандартные действия. При этом сохраняйте значения:
В принципе можно ограничиться записыванием только нестандартных действий, но на первое время (время отладки) записывайте все обращения к скрипту. Возможно Ваш скрипт кто-то захочет обдурить, и пусть даже у него это получится, зато при полном отчете Вы будете знать как он это сделал и сможете убрать "дырки".
Обязательно на этапе разработки встраивайте код, который будет каким-либо образом ограничивать работу скрипта, если система уже запустила этот скрипт раньше. Например, при записи данных в файл делайте блокировку файла на запись для других программ или вводите какой-то специальный признак, чтобы другие скрипты знали про блокировку.
Дайте скрипт на проверку своему компетентному другу. Или даже разработайте скрипт с ним вместе. Таким образом Вы избежите большого количества ошибок.
Прежде чем "вывесить" скрипт в сеть проверьте его со всех сторон. Станьте на время взломщиком своего скрипта и оцените его устойчивость со всех сторон. Проанализируйте работу скрипта при всевозможных неправильных данных (хорошим помощником будет двух летний брат за клавиатурой %)