Конспект по веб-безопасности
сегодня в 12:01
Простите, но накипело.Много шишек уже набито на тему безопасности сайтов. Молодые специалисты, окончившие ВУЗы, хоть и умеют программировать, но в вопросе безопасности сайта наступают на одни и те же грабли.Этот конспект-памятка о том, как добиться относительно высокой безопасности приложений в вебе, а также предостеречь новичков от банальных ошибок. Список составлялся без учета языка программирования, поэтому подходит для всех. А теперь позвольте, я немного побуду КО.
Итак, каким должен быть безопасный сайт?
1. О сервере FTP — не безопасный протокол, передает информацию не в зашифрованном виде, поэтому стоит выбрать либо FTPS, либо SFTP. Теперь по SSH, авторизация по ключам, ─ используем denyhost или его аналог, можно сменить дефолтный порт. Все, что брутят, нужно закрывать. Если у вас есть свой сервер и вы хоть раз смотрели в логи, вы наверняка замечали многочисленные попытки авторизации по SSH и по FTP, идущие с китайских IP.
Во вне должны смотреть только действительно нужные порты, остальное закрываем фаерволом. Используем всегда актуальные версии софта, вовремя обновляемся. Недавняя история с OpenSSL тому подтверждение
Обязательно настроить логи и мониторить любую подозрительную активность. Никаких левых папок и файлов а-ля .svn, .git, .idea, dump.tar.gz в корне проекта не должно быть. Были случаи, когда на сайтах клиента оставлялись архивы с базой и файлом в открытом доступе. То же самое и с бекапами.
Устанавливаем минимально допустимые права на файлы, никаких 777. Динамику, если возможно, лучше выносить за пределы корня. Статика (js, css, image) должна лежать отдельно, в идеале ─ на другом сервере. Если работаем с важными данными, используем htts/ssl с коротким expiration. Сообщения об ошибках на экран не выводим ─ только подсказки пользователю. Бекапы нужно делать обязательно и сохранять на другом сервере. 2. О входных данных В контроллерах: Всегда фильтруем входные параметры Используем минимально допустимое значение. Например, если получаем число, то и приводим к числу. Валидировать можно на клиенте и обязательно — на сервере. Не забываем проверять переменные на граничные значения. Если данные из списка, то обязательно сопоставляем по множеству допустимых значений. Для файлов по возможности проверяем MIME-тип, не доверяем расширениям, это легко изменить. Не даем безгранично добавлять какие-либо данные (например, комментарии). Не позволяем загружать длинные строки и тяжелые файлы. В модели: Для SQL-запросов используем prepared statements. Оптимизируем запросы к базе — никаких select в цикле. Не забываем про индексы. Сложный поиск? Используйте поисковые движки (ElasticSearch, Sphinx и т.д.). В представлении: Используем escaping для любых данных. Проверяем на xss, никаких html тегов или js скриптов от клиента. В отправке формы или изменений состояний используем уникальные для каждого пользователя токены (csrf). Не хотите токенов, тогда проверяйте HTTP_REFERER. Если используете AJAX, не забывайте проверять данные и на входе, и на выходе. В 99% случаев eval в JS — зло. 3. о клиенте Как говорил Доктор Хаус, пациент всегда врет.Большинству клиентов наплевать на свою безопасность.Валидация на клиенте — только для его удобства, обязательно перепроверяем на сервере. POST так же легко подделывается, как и GET. Если есть форма в открытом доступе без капчи, в нее обязательно начнут писать спамеры. Усложните авторизацию, несколько неудачных попыток входа — пусть вводят капчу. Хотите еще усложнить? Прикручиваем двухфакторную аутентификацию. Для подтверждений используем одноразовый длинный токен, завязанный на конкретного пользователя. Заставляем клиента делать сложные пароли. 4. О шифровании Ничего не храним в открытых файлах. Пароли — в виде хешей с солью, желательно проверять на криптостойкость и коллизии. Никаких данных на клиенте, даже в зашифрованном виде, только id-сессии в куках. Список получился достаточно сумбурный. Примерно так должен выглядеть небольшой конспект студента по безопасности вэб сайта. Наверняка что-то пропустил, что-то можно будет добавить. Пишите в комментарии, что еще можно добавить и мы составим общий чек-лист действительно безопасного сайта.
Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.
