Конспект по веб-безопасности

сегодня в 12:01

Простите, но накипело.

Много шишек уже набито на тему безопасности сайтов. Молодые специалисты, окончившие ВУЗы, хоть и умеют программировать, но в вопросе безопасности сайта наступают на одни и те же грабли.

Этот конспект-памятка о том, как добиться относительно высокой безопасности приложений в вебе, а также предостеречь новичков от банальных ошибок. Список составлялся без учета языка программирования, поэтому подходит для всех. А теперь позвольте, я немного побуду КО.

Итак, каким должен быть безопасный сайт?

1. О сервере

1. FTP – не безопасный протокол, передает информацию не в зашифрованном виде, поэтому стоит выбрать либо FTPS, либо SFTP. Теперь по SSH, авторизация по ключам, ─ используем denyhost или его аналог, можно сменить дефолтный порт.
   
   

   
   

   Все, что брутят, нужно закрывать. Если у вас есть свой сервер и вы хоть раз смотрели в логи, вы наверняка замечали многочисленные попытки авторизации по SSH и по FTP, идущие с китайских IP.

   
   

   
   


2. Во вне должны смотреть только действительно нужные порты, остальное закрываем фаерволом.


3. Используем всегда актуальные версии софта, вовремя обновляемся.
   
   

   
   

   Недавняя история с OpenSSL тому подтверждение

   
   

   
   
   


4. Обязательно настроить логи и мониторить любую подозрительную активность.


5. Никаких левых папок и файлов а-ля .svn, .git, .idea, dump.tar.gz в корне проекта не должно быть.
   
   

   
   

   Были случаи, когда на сайтах клиента оставлялись архивы с базой и файлом в открытом доступе. То же самое и с бекапами.

   
   

   
   


6. Устанавливаем минимально допустимые права на файлы, никаких 777.


7. Динамику, если возможно, лучше выносить за пределы корня.


8. Статика (js, css, image) должна лежать отдельно, в идеале ─ на другом сервере.


9. Если работаем с важными данными, используем htts/ssl с коротким expiration.


10. Сообщения об ошибках на экран не выводим ─ только подсказки пользователю.


11. Бекапы нужно делать обязательно и сохранять на другом сервере.

2. О входных данных

1. В контроллерах:
   
   
   
   
   • Всегда фильтруем входные параметры
   
   
   • Используем минимально допустимое значение. Например, если получаем число, то и приводим к числу. Валидировать можно на клиенте и обязательно – на сервере.
   
   
   • Не забываем проверять переменные на граничные значения.
   
   
   • Если данные из списка, то обязательно сопоставляем по множеству допустимых значений.
   
   
   • Для файлов по возможности проверяем MIME-тип, не доверяем расширениям, это легко изменить.
   
   
   • Не даем безгранично добавлять какие-либо данные (например, комментарии).
   
   
   • Не позволяем загружать длинные строки и тяжелые файлы.
   
   
   
   
   


2. В модели:
   
   
   
   
   • Для SQL-запросов используем prepared statements.
   
   
   • Оптимизируем запросы к базе — никаких select в цикле.
   
   
   • Не забываем про индексы.
   
   
   • Сложный поиск? Используйте поисковые движки (ElasticSearch, Sphinx и т.д.).
   
   
   
   
   


3. В представлении:
   
   
   
   
   • Используем escaping для любых данных. Проверяем на xss, никаких html тегов или js скриптов от клиента.
   
   
   • В отправке формы или изменений состояний используем уникальные для каждого пользователя токены (csrf). Не хотите токенов, тогда проверяйте HTTP_REFERER.
   
   
   • Если используете AJAX, не забывайте проверять данные и на входе, и на выходе. В 99% случаев eval в JS – зло.
   
   
   
   
   

3. о клиенте

Как говорил Доктор Хаус, пациент всегда врет.

Большинству клиентов наплевать на свою безопасность.

1. Валидация на клиенте – только для его удобства, обязательно перепроверяем на сервере.


2. POST так же легко подделывается, как и GET.


3. Если есть форма в открытом доступе без капчи, в нее обязательно начнут писать спамеры.


4. Усложните авторизацию, несколько неудачных попыток входа — пусть вводят капчу.


5. Хотите еще усложнить? Прикручиваем двухфакторную аутентификацию.


6. Для подтверждений используем одноразовый длинный токен, завязанный на конкретного пользователя.


7. Заставляем клиента делать сложные пароли.

4. О шифровании

1. Ничего не храним в открытых файлах.


2. Пароли — в виде хешей с солью, желательно проверять на криптостойкость и коллизии.


3. Никаких данных на клиенте, даже в зашифрованном виде, только id-сессии в куках.

Список получился достаточно сумбурный. Примерно так должен выглядеть небольшой конспект студента по безопасности вэб сайта. Наверняка что-то пропустил, что-то можно будет добавить. Пишите в комментарии, что еще можно добавить и мы составим общий чек-лист действительно безопасного сайта.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.