Как банка может распространять уязвимость в веб-приложении, где она используется?

У меня есть веб-приложение Spring MVC, защищенное Spring Security. Жизнь кажется такой спокойной, пока я не был вынужден сделать Static Application Security Testing (SAST), и инструмент бросил кучу проблем безопасности. Посмотрите здесь:

Я прошел через все CVE и получил грубую картину об уязвимостях. У меня есть несколько запросов:

Как веб-приложение уязвимо для такой эксплуатации, когда с ним интегрирована инфраструктура безопасности (Spring Безопасность)?
Можно ли игнорировать все эти уязвимости, поскольку Spring У безопасности может быть какое-то обходное решение для всех этих уязвимостей?

Ответ 1

Из Spring Руководство по безопасности:

Spring Безопасность - это мощная и настраиваемая аутентификация и структура контроля доступа. Это де-факто стандарт для обеспечения безопасности Spring.

Подумайте о безопасности spring как об аутентификации, она охватывает одну часть головоломки безопасности.

В качестве примера давайте посмотрим на № 1 из 10 лучших приложений безопасности OWASP: A1 - Injection
Предположим, вы используете банку для доступа к базе данных SQL (например, спящий режим), и она имеет уязвимость в отношении инъекций, тогда ваше приложение также может быть уязвимым. Однако даже если в спящем режиме нет ошибок безопасности, если программист объединяет SQL-запрос вместе, без правильного выхода из пользовательского ввода, приложение уязвимо для атаки на инъекции.
Spring безопасность не защищает ваше приложение от любой из этих инъекционных атак.

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

Для быстрого просмотра других OWASP Топ-10 рисков безопасности приложений:
A1-Injection - защита от spring безопасности
A2-Broken Authentication and Session Management - spring Безопасность может помочь в управлении некоторыми из них, однако защищенная с ошибкой защита spring будет раскрывать их.
A3-Cross-Site Scripting (XSS) - защита от spring безопасности
Ссылки на прямые ссылки на A4-Insecure - Нет дополнительной защиты от spring Безопасность (Spring Безопасность предоставляет вам инструмент для управления этим)
A5-Security Misconfiguration - защита от spring безопасности
Экспозиция с данными с A6-чувствительностью - spring Безопасность может помочь в этом, но это также сильно зависит от того, как вы храните и управляете своими данными (например, файлы журналов)
Контроль доступа к функциональному уровню A7. Если элемент управления доступом был пропущен, spring Безопасность не поможет вам, однако spring безопасность упрощает добавление этих
A8-Cross-Site Request Forgery (CSRF) - spring Безопасность (в зависимости от того, как настроено ваше приложение) поможет вам или даже справится с этим риском для вас.
A9 - Использование компонентов с известными уязвимостями - это CVE, который вы указали в своем вопросе - Без защиты от spring Безопасность
A10-Неутвержденные перенаправления и переадресации - spring Для управления этим может использоваться защита, однако она не защищает ваше приложение из этого пакета

Список CVE, найденных во время STAT вашего приложения, является примером A9 - Использование компонентов с известными уязвимостями. Посмотрите Wiki для более подробной информации.

Примеры сценариев атаки

Уязвимости компонентов могут вызывать практически любой тип риска возможно, от тривиального до сложного вредоносного ПО, разработанного для ориентации на конкретную организацию. Компоненты почти всегда работают с полная привилегия приложения, поэтому недостатки в любом компоненте могут быть серьезным, были загружены следующие два уязвимых компонента 22 м в 2011 году.

Обход аутентификации Apache CXF - не предоставив токен идентификации, злоумышленники могут ссылаться на любой веб-сервис с полным разрешение. (Apache CXF - это инфраструктура служб, чтобы не путать с сервером приложений Apache.)

Spring Удаленное выполнение кода - злоупотребление реализацией языка выражения в spring позволило злоумышленникам выполнить произвольный код, эффективно захватив сервер.
Каждое приложение, использующее любую из этих уязвимых библиотек, уязвимы для атаки, поскольку оба этих компонента напрямую доступный пользователям приложения. Другие уязвимые библиотеки, используемые глубже в приложении, может быть труднее использовать.

Примечание из предыдущего абзаца выше, чем глубже компонент (jar), тем труднее его использовать, однако это не означает, что определенный объект не может их использовать.

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