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