Tips & tricks по безопасности в сети
В интернете довольно много материалов о том, как защитить свой сайт от взлома.
К сожалению методов взлома довольно много и, как правило, каждый материал описывает способы защиты от конкретной уязвимости. Понятно что универсального приёма нет, но я постараюсь привести те приёмы, которыми пользуюсь сам. Насколько они эффективны судить трудно, но по крайней мере ни один из моих сайтов не взломали, хотя пытались.
Правда надо оговориться, что все сайты построены на движке , который сам по себе уже обеспечивает довольно неплохую базовую безопаность. Оставаясь, правда, уязвимым для некоторых типов атак.
Итак, поехали!
1. consig.php - global_xss_filtering=TRUE
Если вы не включили данный параметр - дальше читать нет смысла, так как ниже пойдет речь только об оставшихся 10% уязвимостей, которые не вычищает CodeIgniter. Если вы не пользуетесь данным фреймворком - то можно в принципе скачать исходник и посмотреть как именно вычищаются XSS в CI и реализовать нечто подобное.
Знание-сила!
Сохраняя стандартную структуру каталогов при установке шаблонных скриптов - вы значительно облегчаете задачу хакеру. Выход простой, переименовывайте папки, переносите их на уровень выше www и т.п.
Список скриптов
В кодеигнайтере не случайно в каждой папке лежит файл index.html. Просто придерживайтесь этой хорошей традиции. Создали папку - положили внутрь index.html "No direct access alowed".
Доступ к скрипту напрямую
Если хакер всё же добрался до вашей любимой библиотеки, и вызвал её напрямую - обломайте её разместив проверку некой переменной под дефайном, определенной в главном скрипте.
if (!defined('BASEPATH')) exit('No direct script access allowed');
SQL-инъекции
Самый распространённый способ взлома через sql - это передать в урл типа http://site/page/1 - что то вроде http://site/page/1;delete%20from%20users
Защититься от подобных конструкций проще простого:
1. Используйте класс актив рекордс.
Я понимаю что пальцы и олдскульно писать на чистом SQL, однако в 99% случаев в этом нет необходимости. Если ваш запрос настолько сложен, что его невозможно описать стандартным актив рекорд классом CI - выкидывайте его в помойку и переписывайте на несколько лёгких. Всё равно join на БД в которой миллион записей при паре сотен одновременных коннектов в майэскюэль равносилен самоубийству. Маленькие простые запросы, кеш + собираем в памяти через массивы (что то я отвлекся). Вобщем нет причин НЕ пользоваться классом Актив рекордс в КИ, а причин пользоваться - множество. Это и независимость от СУБД, и защита и просто удобно(меньше букв). Если вы питаете иллюзии насчет защитами всякими mysqlrealescapestring - расслабтесь. Заменяем пробелы на спецсимволы и защита летит к чертям. Итак - актив рекордз это раз.
2. Вычищайте переменные
Написать intval($page), substr($string,0,255) - проще простого. Со временем входит в привычку и начинаешь чувствовать себя сухо и комфортно. Помимо этого хорошо бы ещё раз и навсегда забыть о таком явлении как глобальные переменные и методе GET. POST вполне достаточно.
HTML
Да да, я не опечатался. Первое что напишут на сайте на котором разрешен html - будет <font size=48>ХУЙ</font>. Ну может быть не первое, но напишут обязательно. В принципе если детям ваш сайт неинтересен - это не так уж и страшно, но согласитесь неприятно. htmlspechialchars(все_входные_параметры)
И никаких хуёв на главной
XSS
Сегодняшние хакеры - это не любопытные мальчишки, а волосатые потные мужики с вонючими подмышками, которые ползают по сети в поисках популярных сайтов подверженных уязвимостям - с одной единственной целью - SPAM. Nothing personal, just business. Способов XSS атак - , однако защититься от них довольно просто. Достаточно включить xss фильтр в CI + htmlspechialchars и xss идет лесом. Если CI нет - см. пункт 1
Картинки
Дадат, невинные картинки могут содержать как невинные текстовые комментарии, так и . Если вы посмотрите на адрес картинки в заголовке поста и подумаете что это "пальцы" - то ошибетесь. Делать мне нечего - плодить субдомены. Просто на субдомене можно банально запретить все php, cgi и пр. скрипты. Или даже поставить какой-ть нджиникс. Помимо запрета скриптов мы таким образом ещё и скрываем абсолютный путь к папке с картинками.
Печеньки
Кукис хранятся на клиенте, и значит по определению являются неблагонадёжным источником информации. К счастью никто уже не хранит в кукис пароли в явном виде, но password:MD5(password) - встречается повсеместно. Во первых хэш пароля 1234 наверно лежит наверно в топе гугля, во вторых, кто вас за язык тянет называть переменные своими именами? Итак, пароли хэшируем как то так MD5('1234'+'$%^x_Yl1234_?kl%$'), где "'$%^x_Yl1234_?kl%$'" - генерируем ударом лба об клавиатуру. 2 - не пишем как идиоты логин, пароль и т.п. в куки. Лучше глобально зашифровать всё её содержимое. В CI - как то так: $config['sess_encrypt_cookie'] = TRUE;
Троянские кони
Казолось бы причем тут лошадки? Ну если у вас есть модераторы - наверняка среди них встретится любитель тыкать по ссылкам в ИЕ6. Украв куку целиком - никакие шифрования не помогут. Но у нас ещё остаются сессии. В сессии можно хранить кучу ненужной информации, например IP пользователя, User Agent и валидировать их с кукисами. Тогда украв куку - хакеру ещё нужно будет украсть и айпи и браузер жертвы, что уже немного сложнее. К счастью в CI для валидации достаточно активировать пару строк:
$config['sess_match_ip'] = TRUE;//Из дома и на работе авторизовываться придется юзерам
$config['sess_match_useragent'] = TRUE;//Разным браузерам разная сессия
$config['sess_time_to_update'] = 600;// каждые 10 мин долбим БД и сверяем куку с сессией, увеличить если тормозит
Конечно я описал не все приемы защиты, и наверно пропустил какие то важные типы уязвимостей.
Если есть что добавить - You are welcome.
