Backend Безопасность загрузки Spring | Кодементор

01. SQL-инъекция

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

Как мы защищаем приложения
Мы следуем стандарту json api, поэтому риск SQL-инъекции строки запроса на основе GET снижается.
Парсеры Json не будут анализировать полезную нагрузку, если она не соответствует стандарту json (это не сработает, если sql находится в значении). Таким образом, риск SQL-инъекций снова снижается.
Мы используем фреймворки ORM вместо подготовленных операторов jdbc или нативных запросов.
Что мы должны делать больше

Следуйте строгим правилам использования нативных запросов или вообще не используйте нативные запросы.
Обновите фреймворки ORM до новых версий (если мы сможем как-то избежать конфликтов библиотек)

02. Сломанная аутентификация и управление сессиями

Это в основном связано с хайджеком sessionId/cookie.

Как мы должны защищать приложения

Мы должны отключить управление сеансом в весенней загрузке.

.sessionManagement()
               .sessionCreationPolicy(SessionCreationPolicy.STATELESS);

Если необходимо включить управление сеансом, включите его с помощью следующих конфигураций.

  1. Защита от фиксации
http.sessionManagement()
      .sessionFixation().migrateSession()

2. Запретите использование параметров URL для отслеживания сеанса

http.sessionManagement()
      .sessionFixation().migrateSession()

Что мы должны делать больше

  • Время ожидания токена доступа быстрее
  • Защита от грубой силы: принудительное отключение учетной записи после установленного количества неверных попыток входа.

03. Межсайтовый скрипт XSS

Как мы должны защищать приложения

  • Очистите входящие данные с помощью фильтра. И параметры, и данные post/put/patch
  • Клиентские фреймворки должны иметь встроенную защиту от xss.

Что мы должны делать больше
Используйте внешние библиотеки для дополнительной защиты (

04. Внешние объекты XML

Как мы должны защищать приложения

  • Безопасно XML с использованием стандартных библиотек
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);

Безопасность Spring уже решила эти проблемы на контролируемом уровне (

05. Сломанный контроль доступа

Ограничения на то, что разрешено делать аутентифицированным пользователям. Злоумышленники могут использовать эти недостатки для доступа к несанкционированным функциям и/или данным.

Как мы защищаем приложения

  • Аутентификация защищенных URL-адресов
  • Защитите учетные данные для входа. (либо с использованием стороннего сервиса, либо путем хэширования данных в базе данных)

Что мы должны делать больше

  • Применить выполнение метода на основе ролей
  • Применить базовую проверку ролей для уровней классов и уровней методов
  • Будьте строги в отношении классов и методов без аннотаций на основе ролей.
    Запустите инструменты проверки уязвимостей безопасности в исходном коде (

06. Неправильная настройка безопасности

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

Как мы должны защищать приложения

  • Протестируйте настройки безопасности

Что мы должны делать больше

  • Изучите весеннюю безопасность
  • Обновите версии фреймворка, а также операционные системы и инструменты
  • Просмотрите настройки безопасности с членами команды
    Проверка на проницаемость

07. Разоблачение конфиденциальных данных

Как мы должны защищать приложения

  • Тестировать, тестировать и еще раз тестировать
  • Обзор кода

Связанная статья

Похожие записи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *