Краткий Обзор Веб-Безопасности

Извините, но кипит. На тему безопасности веб-сайтов уже написано много шума.

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

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

Список составлен без учета языка программирования, поэтому подойдет всем.

Теперь позвольте мне немного побыть нокаутом.

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

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. Если мы работаем с важными данными, мы используем https/ssl с коротким сроком действия.

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

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

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

1. В контроллерах:
   • Мы всегда фильтруем входные параметры
   • Мы используем минимально приемлемое значение.

     Например, если мы получили число, то мы уменьшаем его до числа.

     Вы можете проверить это на клиенте и обязательно на сервере.

   • Не забудьте проверить переменные на наличие граничных значений.

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

   • Для файлов по возможности проверяем MIME-тип, не доверяем расширениям, это легко изменить.

   • Мы не разрешаем неограниченное добавление каких-либо данных (например, комментариев).

   • Мы не разрешаем загружать длинные строки или тяжелые файлы.

2. В модели:
   • Для SQL-запросов мы используем подготовленные операторы.

   • Оптимизируем запросы к базе данных — никакого выбора в цикле.

   • Не забывайте об индексах.

   • Сложный поиск? Используйте поисковые системы (ElasticSearch, Sphinx и т. д.).

3. Ввиду:
   • Приводим данные в необходимые сущности.

     Проверяем наличие xss, отсутствие html-тегов или js-скриптов от клиента.

   • При отправке форм или изменении состояния мы используем уникальные токены для каждого пользователя (csrf).

     Если вам не нужны токены, проверьте HTTP_REFERER.

   • Если вы используете AJAX, не забудьте проверить как ввод, так и вывод. В 99% случаев eval в JS — это зло.

3. О клиенте

1. Проверка на клиенте производится только для его удобства; мы должны перепроверить это на сервере.

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

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

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

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

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

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

1. Мы не храним ничего в открытом виде.

2. Пароли представлены в виде хэшей с солью; желательно проверить их на криптостойкость и коллизии.

3. от ВалдикСС Не используйте ни MD5, ни SHA1. Лучше всего использовать специализированные хеш-функции для паролей, например PBKDF2 или scrypt.
4. Никаких данных о клиенте, даже в зашифрованном виде, только идентификатор сессии в куках.

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

Наверняка я что-то упустил, что-то можно добавить.

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

Теги: #веб-разработка #безопасность #практики #информационная безопасность #разработка веб-сайтов

• Вышла Бета-Версия Windows Server От Microsoft

  19 Oct, 24

• Gps – Отслеживание Времени В Эпоху Спутников

  19 Oct, 24

• Переосмысление Бесплатного

  19 Oct, 24

• Венчурный Фонд Сбербанка Sbt Venture Capital Инвестировал В Систему Защиты Банков От Мошенничества

  19 Oct, 24

• Готовы К Ddos-Атаке!

  19 Oct, 24

• Исследователи Уличили Google В Получении Денег От Ботов За Просмотр Рекламы На Youtube.

  19 Oct, 24

• История Разработки Игры Prince Of Persia: The Sands Of Time

  19 Oct, 24

• Следуйте Python: Как Я Изучаю Новый Язык

  19 Oct, 24

• Законопроект Об «Устойчивой Работе» Рунета – Что Делать До Второго Чтения?

  19 Oct, 24

• Дополненная Реальность + 3D На Silverlight

  19 Oct, 24