CVE-2016-9879

Wysokie

Opublikowano: 06/01/2017(UTC)Przetłumaczono: 15/06/2026(UTC)NVD NIST

Streszczenie

W Pivotal Spring Security przed wersją 3.2.10, 4.1.x przed 4.1.4 oraz 4.2.x przed 4.2.1 odkryto problem związany z brakiem uwzględnienia parametrów ścieżki URL przy przetwarzaniu ograniczeń bezpieczeństwa. Atakujący może obejść te ograniczenia, dodając zakodowany parametr '/' do żądania.

Ocena ryzyka

Organizacje mogą być narażone na nieautoryzowany dostęp do zasobów, co może prowadzić do poważnych naruszeń bezpieczeństwa. W szczególności, możliwość ominięcia ograniczeń bezpieczeństwa stwarza ryzyko dla integralności danych.

Rekomendacja

Zaleca się aktualizację Pivotal Spring Security do najnowszej wersji, aby usunąć tę podatność. Dodatkowo, warto przeprowadzić audyt zabezpieczeń aplikacji korzystających z tej biblioteki.

Inne podatności w Pivotal Spring Security

CVE-2017-4995Wysokie
W Pivotal Spring Security w wersjach od 4.2.0.RELEASE do 4.2.2.RELEASE oraz 5.0.0.M1 odkryto podatność na deserializację, która może prowadzić do wykonania dowolnego kodu. Problem występuje, gdy domyślne typowanie Jacksona jest włączone, co umożliwia wykorzystanie nieznanych 'gadżetów deserializacyjnych'.

Oryginalny opis (angielski, źródło NVD)

An issue was discovered in Pivotal Spring Security before 3.2.10, 4.1.x before 4.1.4, and 4.2.x before 4.2.1. Spring Security does not consider URL path parameters when processing security constraints. By adding a URL path parameter with an encoded "/" to a request, an attacker may be able to bypass a security constraint. The root cause of this issue is a lack of clarity regarding the handling of path parameters in the Servlet Specification. Some Servlet containers include path parameters in the value returned for getPathInfo() and some do not. Spring Security uses the value returned by getPathInfo() as part of the process of mapping requests to security constraints. The unexpected presence of path parameters can cause a constraint to be bypassed. Users of Apache Tomcat (all current versions) are not affected by this vulnerability since Tomcat follows the guidance previously provided by the Servlet Expert group and strips path parameters from the value returned by getContextPath(), get