MVC 요청/매처 스프링 취약점 자세히 살펴보기
2023년 3월 20일, 춘계 보안 권고는 다음을 발표했습니다. 블로그 포스트 내부적으로 발견된 취약점을 참조하여 CVE-2023-20860.사용에 관한 액세스 제어 문제라는 점을 제외하고 자세한 정보는 공개되지 않았습니다. MVC 매처스.Spring 개발자가 문제를 해결했으며 버전 업데이트가 권장됩니다.
직접 체험해 보고 싶으신가요? 여기서 임무를 수행해 보세요..
보안이 우리의 주요 초점이기 때문에 시큐어 코드 워리어, 우리는 이 MVCrequestMatchers 취약점을 자세히 살펴보고 핵심 문제가 어디에 있는지 알아내기로 결정했습니다.
스프링은 요청이 경로 패턴과 일치하는지 확인할 수 있는 RequestMatcher 인터페이스를 제공합니다.아래 코드 스니펫을 살펴보세요. MVC 매처스 헬퍼 메소드는 인증 및 권한 부여 요구 사항과 함께 엔드 포인트를 등록하는 데 사용됩니다.예를 들어 ADMIN 역할의 사용자만 액세스할 수 있음을 알 수 있습니다. /로그/감사 끝점.
Mvc미스매처?
봄에는 ** URL의 여러 디렉터리 및 하위 디렉터리와 일치하는 패턴입니다.예:/은행 계좌/** 로 시작하는 모든 URL과 일치합니다. /은행 계좌/, 다음과 같은 하위 디렉토리 포함 /은행 계좌/대시보드/설정.
더 * 패턴은 모든 URL과 일치하며 정확히 한 레벨의 하위 디렉토리를 갖는 패턴입니다.예를 들어, /은행계좌/ * 일치할 것이다 은행 계좌/대시보드.
다음과 같이 매처를 구성할 때 *, 스프링은 다음과 같이 말합니다. “스프링 시큐리티와 스프링 MVC 간의 패턴 매칭 불일치” 발생하여 취약점이 발생했습니다.
기본적으로 이중 와일드카드 앞에 구분 기호가 없기 때문에 모든 수신 요청 앞에 슬래시가 추가되므로 경로가 수신 요청과 일치하지 않습니다.즉, 액세스 제어 규칙이 적용되지 않으므로 인증되지 않은 사용자는 리소스에 액세스할 수 있습니다.
한 번 살펴 보겠습니다. 범하다 문제가 해결되었습니다.
가장 눈에 띄고 중요한 변경 사항은 권한 부여 및 인증 규칙 우회를 수정하는 315행의 추가입니다.이를 통해 제출되는 모든 경로 패턴 앞에는 슬래시 (/) 가 붙습니다.
404 일치하는 항목을 찾을 수 없습니다.
웹 요청을 보낼 때 /은행 계좌/보기 그 일치 메서드는 보안 필터에 정의된 패턴을 구문 분석하고 요청된 경로와 비교합니다.파서는 주어진 패턴을 경로 요소 트리로 바꿉니다.
파서는 첫 번째 문자를 a로 읽습니다. 구분자 경로 요소.그런 다음 다음 구분자가 나올 때까지 문자열 문자를 계속 읽으면서 새 구분자를 만듭니다. 리터럴 패스 요소.
그렇다면 사용할 때 어디에서 문제가 발생합니까? ** 패턴처럼?
다양한 경로 요소 유형이 있지만 여기서 가장 흥미로운 유형은 다음과 같습니다. 와일드카드 패스 엘레멘t 및 더 와일드카드 REST 경로 요소, 각각의 문자열 표현과 함께: * 과 /**.
A 와일드카드 경로 요소 단일 경로 세그먼트 내에서 0개 이상의 문자와 일치하는 반면 a 와일드카드 REST 경로 요소 0개 이상의 경로 세그먼트를 자체적으로 일치시킵니다 (구분 기호 포함).
후자는 제출할 때 무엇이 잘못되었는지에 대한 단서를 제공합니다. ** 패턴으로.파싱하는 동안 패턴을 찾지만 ** 예상한 포워드 슬래시로 시작하지 않습니다.그러니까, 그렇게 되기보다는 와일드카드 REST 경로 요소, 두 번 연속됩니다 와일드카드 경로 요소.
다음으로, 파싱된 패턴을 사용하여 요청된 URL과 일치시킵니다.경로는 슬래시로 시작할 것으로 예상되지만 구분자의 와일드카드는 일치하지 않습니다.
이것은 대신에 매칭 결과 요청, null이 반환됩니다.따라서 이 매처에 적용된 액세스 제어 규칙은 요청된 URL에 적용되지 않습니다.
Spring은 앞에 슬래시를 추가해 문제를 해결했습니다.다시 말해, 어떤 것이든 ** 패턴이 됩니다 /**, 다음과 같이 파싱될 수 있음을 의미합니다. 와일드카드 REST 경로 요소, 그리고 매칭 결과 요청 패턴이 이제 요청된 URL과 일치하므로 반환됩니다.
취약성 또는 API 오용?
코드가 의도한 대로 작동하기 때문에 이를 취약점으로 간주해야 하는지는 논쟁의 여지가 있습니다.문제는 기본적으로 다음과 같은 사실에 있습니다. 스프링 문서 경로가 구분자로 시작해야 한다는 명시적인 언급이 없습니다.따라서 버그나 취약점이라기보다는 API 오용 사례에 가깝다고 볼 수 있습니다.
2023년 3월 20일, 스프링 시큐리티 어드바이저리는 내부적으로 발견된 취약점인 CVE-2023-20860 취약점을 언급하는 블로그 게시물을 게시했습니다.'MVCMatchers' 사용과 관련된 액세스 제어 문제라는 점을 제외하고 자세한 정보는 공개되지 않았습니다.Spring 개발자들이 이 문제를 해결했으며 버전 업데이트가 권장됩니다.Secure Code Warrior에서는 보안이 주안점이기 때문에 MVCrequestMatchers의 취약점을 자세히 살펴보고 핵심 문제가 어디에 있는지 알아보기로 했습니다.
Secure Code Warrior는 전체 소프트웨어 개발 라이프사이클에서 코드를 보호하고 사이버 보안을 최우선으로 생각하는 문화를 조성할 수 있도록 조직을 위해 여기 있습니다.AppSec 관리자, 개발자, CISO 또는 보안 관련 누구든 관계없이 조직이 안전하지 않은 코드와 관련된 위험을 줄일 수 있도록 도와드릴 수 있습니다.
데모 예약
Brysen is a software developer at Secure Code Warrior with a focus on writing secure code.
2023년 3월 20일, 춘계 보안 권고는 다음을 발표했습니다. 블로그 포스트 내부적으로 발견된 취약점을 참조하여 CVE-2023-20860.사용에 관한 액세스 제어 문제라는 점을 제외하고 자세한 정보는 공개되지 않았습니다. MVC 매처스.Spring 개발자가 문제를 해결했으며 버전 업데이트가 권장됩니다.
직접 체험해 보고 싶으신가요? 여기서 임무를 수행해 보세요..
보안이 우리의 주요 초점이기 때문에 시큐어 코드 워리어, 우리는 이 MVCrequestMatchers 취약점을 자세히 살펴보고 핵심 문제가 어디에 있는지 알아내기로 결정했습니다.
스프링은 요청이 경로 패턴과 일치하는지 확인할 수 있는 RequestMatcher 인터페이스를 제공합니다.아래 코드 스니펫을 살펴보세요. MVC 매처스 헬퍼 메소드는 인증 및 권한 부여 요구 사항과 함께 엔드 포인트를 등록하는 데 사용됩니다.예를 들어 ADMIN 역할의 사용자만 액세스할 수 있음을 알 수 있습니다. /로그/감사 끝점.
Mvc미스매처?
봄에는 ** URL의 여러 디렉터리 및 하위 디렉터리와 일치하는 패턴입니다.예:/은행 계좌/** 로 시작하는 모든 URL과 일치합니다. /은행 계좌/, 다음과 같은 하위 디렉토리 포함 /은행 계좌/대시보드/설정.
더 * 패턴은 모든 URL과 일치하며 정확히 한 레벨의 하위 디렉토리를 갖는 패턴입니다.예를 들어, /은행계좌/ * 일치할 것이다 은행 계좌/대시보드.
다음과 같이 매처를 구성할 때 *, 스프링은 다음과 같이 말합니다. “스프링 시큐리티와 스프링 MVC 간의 패턴 매칭 불일치” 발생하여 취약점이 발생했습니다.
기본적으로 이중 와일드카드 앞에 구분 기호가 없기 때문에 모든 수신 요청 앞에 슬래시가 추가되므로 경로가 수신 요청과 일치하지 않습니다.즉, 액세스 제어 규칙이 적용되지 않으므로 인증되지 않은 사용자는 리소스에 액세스할 수 있습니다.
한 번 살펴 보겠습니다. 범하다 문제가 해결되었습니다.
가장 눈에 띄고 중요한 변경 사항은 권한 부여 및 인증 규칙 우회를 수정하는 315행의 추가입니다.이를 통해 제출되는 모든 경로 패턴 앞에는 슬래시 (/) 가 붙습니다.
404 일치하는 항목을 찾을 수 없습니다.
웹 요청을 보낼 때 /은행 계좌/보기 그 일치 메서드는 보안 필터에 정의된 패턴을 구문 분석하고 요청된 경로와 비교합니다.파서는 주어진 패턴을 경로 요소 트리로 바꿉니다.
파서는 첫 번째 문자를 a로 읽습니다. 구분자 경로 요소.그런 다음 다음 구분자가 나올 때까지 문자열 문자를 계속 읽으면서 새 구분자를 만듭니다. 리터럴 패스 요소.
그렇다면 사용할 때 어디에서 문제가 발생합니까? ** 패턴처럼?
다양한 경로 요소 유형이 있지만 여기서 가장 흥미로운 유형은 다음과 같습니다. 와일드카드 패스 엘레멘t 및 더 와일드카드 REST 경로 요소, 각각의 문자열 표현과 함께: * 과 /**.
A 와일드카드 경로 요소 단일 경로 세그먼트 내에서 0개 이상의 문자와 일치하는 반면 a 와일드카드 REST 경로 요소 0개 이상의 경로 세그먼트를 자체적으로 일치시킵니다 (구분 기호 포함).
후자는 제출할 때 무엇이 잘못되었는지에 대한 단서를 제공합니다. ** 패턴으로.파싱하는 동안 패턴을 찾지만 ** 예상한 포워드 슬래시로 시작하지 않습니다.그러니까, 그렇게 되기보다는 와일드카드 REST 경로 요소, 두 번 연속됩니다 와일드카드 경로 요소.
다음으로, 파싱된 패턴을 사용하여 요청된 URL과 일치시킵니다.경로는 슬래시로 시작할 것으로 예상되지만 구분자의 와일드카드는 일치하지 않습니다.
이것은 대신에 매칭 결과 요청, null이 반환됩니다.따라서 이 매처에 적용된 액세스 제어 규칙은 요청된 URL에 적용되지 않습니다.
Spring은 앞에 슬래시를 추가해 문제를 해결했습니다.다시 말해, 어떤 것이든 ** 패턴이 됩니다 /**, 다음과 같이 파싱될 수 있음을 의미합니다. 와일드카드 REST 경로 요소, 그리고 매칭 결과 요청 패턴이 이제 요청된 URL과 일치하므로 반환됩니다.
취약성 또는 API 오용?
코드가 의도한 대로 작동하기 때문에 이를 취약점으로 간주해야 하는지는 논쟁의 여지가 있습니다.문제는 기본적으로 다음과 같은 사실에 있습니다. 스프링 문서 경로가 구분자로 시작해야 한다는 명시적인 언급이 없습니다.따라서 버그나 취약점이라기보다는 API 오용 사례에 가깝다고 볼 수 있습니다.
2023년 3월 20일, 춘계 보안 권고는 다음을 발표했습니다. 블로그 포스트 내부적으로 발견된 취약점을 참조하여 CVE-2023-20860.사용에 관한 액세스 제어 문제라는 점을 제외하고 자세한 정보는 공개되지 않았습니다. MVC 매처스.Spring 개발자가 문제를 해결했으며 버전 업데이트가 권장됩니다.
직접 체험해 보고 싶으신가요? 여기서 임무를 수행해 보세요..
보안이 우리의 주요 초점이기 때문에 시큐어 코드 워리어, 우리는 이 MVCrequestMatchers 취약점을 자세히 살펴보고 핵심 문제가 어디에 있는지 알아내기로 결정했습니다.
스프링은 요청이 경로 패턴과 일치하는지 확인할 수 있는 RequestMatcher 인터페이스를 제공합니다.아래 코드 스니펫을 살펴보세요. MVC 매처스 헬퍼 메소드는 인증 및 권한 부여 요구 사항과 함께 엔드 포인트를 등록하는 데 사용됩니다.예를 들어 ADMIN 역할의 사용자만 액세스할 수 있음을 알 수 있습니다. /로그/감사 끝점.
Mvc미스매처?
봄에는 ** URL의 여러 디렉터리 및 하위 디렉터리와 일치하는 패턴입니다.예:/은행 계좌/** 로 시작하는 모든 URL과 일치합니다. /은행 계좌/, 다음과 같은 하위 디렉토리 포함 /은행 계좌/대시보드/설정.
더 * 패턴은 모든 URL과 일치하며 정확히 한 레벨의 하위 디렉토리를 갖는 패턴입니다.예를 들어, /은행계좌/ * 일치할 것이다 은행 계좌/대시보드.
다음과 같이 매처를 구성할 때 *, 스프링은 다음과 같이 말합니다. “스프링 시큐리티와 스프링 MVC 간의 패턴 매칭 불일치” 발생하여 취약점이 발생했습니다.
기본적으로 이중 와일드카드 앞에 구분 기호가 없기 때문에 모든 수신 요청 앞에 슬래시가 추가되므로 경로가 수신 요청과 일치하지 않습니다.즉, 액세스 제어 규칙이 적용되지 않으므로 인증되지 않은 사용자는 리소스에 액세스할 수 있습니다.
한 번 살펴 보겠습니다. 범하다 문제가 해결되었습니다.
가장 눈에 띄고 중요한 변경 사항은 권한 부여 및 인증 규칙 우회를 수정하는 315행의 추가입니다.이를 통해 제출되는 모든 경로 패턴 앞에는 슬래시 (/) 가 붙습니다.
404 일치하는 항목을 찾을 수 없습니다.
웹 요청을 보낼 때 /은행 계좌/보기 그 일치 메서드는 보안 필터에 정의된 패턴을 구문 분석하고 요청된 경로와 비교합니다.파서는 주어진 패턴을 경로 요소 트리로 바꿉니다.
파서는 첫 번째 문자를 a로 읽습니다. 구분자 경로 요소.그런 다음 다음 구분자가 나올 때까지 문자열 문자를 계속 읽으면서 새 구분자를 만듭니다. 리터럴 패스 요소.
그렇다면 사용할 때 어디에서 문제가 발생합니까? ** 패턴처럼?
다양한 경로 요소 유형이 있지만 여기서 가장 흥미로운 유형은 다음과 같습니다. 와일드카드 패스 엘레멘t 및 더 와일드카드 REST 경로 요소, 각각의 문자열 표현과 함께: * 과 /**.
A 와일드카드 경로 요소 단일 경로 세그먼트 내에서 0개 이상의 문자와 일치하는 반면 a 와일드카드 REST 경로 요소 0개 이상의 경로 세그먼트를 자체적으로 일치시킵니다 (구분 기호 포함).
후자는 제출할 때 무엇이 잘못되었는지에 대한 단서를 제공합니다. ** 패턴으로.파싱하는 동안 패턴을 찾지만 ** 예상한 포워드 슬래시로 시작하지 않습니다.그러니까, 그렇게 되기보다는 와일드카드 REST 경로 요소, 두 번 연속됩니다 와일드카드 경로 요소.
다음으로, 파싱된 패턴을 사용하여 요청된 URL과 일치시킵니다.경로는 슬래시로 시작할 것으로 예상되지만 구분자의 와일드카드는 일치하지 않습니다.
이것은 대신에 매칭 결과 요청, null이 반환됩니다.따라서 이 매처에 적용된 액세스 제어 규칙은 요청된 URL에 적용되지 않습니다.
Spring은 앞에 슬래시를 추가해 문제를 해결했습니다.다시 말해, 어떤 것이든 ** 패턴이 됩니다 /**, 다음과 같이 파싱될 수 있음을 의미합니다. 와일드카드 REST 경로 요소, 그리고 매칭 결과 요청 패턴이 이제 요청된 URL과 일치하므로 반환됩니다.
취약성 또는 API 오용?
코드가 의도한 대로 작동하기 때문에 이를 취약점으로 간주해야 하는지는 논쟁의 여지가 있습니다.문제는 기본적으로 다음과 같은 사실에 있습니다. 스프링 문서 경로가 구분자로 시작해야 한다는 명시적인 언급이 없습니다.따라서 버그나 취약점이라기보다는 API 오용 사례에 가깝다고 볼 수 있습니다.
아래 링크를 클릭하고 이 리소스의 PDF를 다운로드하십시오.
Secure Code Warrior는 전체 소프트웨어 개발 라이프사이클에서 코드를 보호하고 사이버 보안을 최우선으로 생각하는 문화를 조성할 수 있도록 조직을 위해 여기 있습니다.AppSec 관리자, 개발자, CISO 또는 보안 관련 누구든 관계없이 조직이 안전하지 않은 코드와 관련된 위험을 줄일 수 있도록 도와드릴 수 있습니다.
보고서 보기데모 예약
Brysen is a software developer at Secure Code Warrior with a focus on writing secure code.
2023년 3월 20일, 춘계 보안 권고는 다음을 발표했습니다. 블로그 포스트 내부적으로 발견된 취약점을 참조하여 CVE-2023-20860.사용에 관한 액세스 제어 문제라는 점을 제외하고 자세한 정보는 공개되지 않았습니다. MVC 매처스.Spring 개발자가 문제를 해결했으며 버전 업데이트가 권장됩니다.
직접 체험해 보고 싶으신가요? 여기서 임무를 수행해 보세요..
보안이 우리의 주요 초점이기 때문에 시큐어 코드 워리어, 우리는 이 MVCrequestMatchers 취약점을 자세히 살펴보고 핵심 문제가 어디에 있는지 알아내기로 결정했습니다.
스프링은 요청이 경로 패턴과 일치하는지 확인할 수 있는 RequestMatcher 인터페이스를 제공합니다.아래 코드 스니펫을 살펴보세요. MVC 매처스 헬퍼 메소드는 인증 및 권한 부여 요구 사항과 함께 엔드 포인트를 등록하는 데 사용됩니다.예를 들어 ADMIN 역할의 사용자만 액세스할 수 있음을 알 수 있습니다. /로그/감사 끝점.
Mvc미스매처?
봄에는 ** URL의 여러 디렉터리 및 하위 디렉터리와 일치하는 패턴입니다.예:/은행 계좌/** 로 시작하는 모든 URL과 일치합니다. /은행 계좌/, 다음과 같은 하위 디렉토리 포함 /은행 계좌/대시보드/설정.
더 * 패턴은 모든 URL과 일치하며 정확히 한 레벨의 하위 디렉토리를 갖는 패턴입니다.예를 들어, /은행계좌/ * 일치할 것이다 은행 계좌/대시보드.
다음과 같이 매처를 구성할 때 *, 스프링은 다음과 같이 말합니다. “스프링 시큐리티와 스프링 MVC 간의 패턴 매칭 불일치” 발생하여 취약점이 발생했습니다.
기본적으로 이중 와일드카드 앞에 구분 기호가 없기 때문에 모든 수신 요청 앞에 슬래시가 추가되므로 경로가 수신 요청과 일치하지 않습니다.즉, 액세스 제어 규칙이 적용되지 않으므로 인증되지 않은 사용자는 리소스에 액세스할 수 있습니다.
한 번 살펴 보겠습니다. 범하다 문제가 해결되었습니다.
가장 눈에 띄고 중요한 변경 사항은 권한 부여 및 인증 규칙 우회를 수정하는 315행의 추가입니다.이를 통해 제출되는 모든 경로 패턴 앞에는 슬래시 (/) 가 붙습니다.
404 일치하는 항목을 찾을 수 없습니다.
웹 요청을 보낼 때 /은행 계좌/보기 그 일치 메서드는 보안 필터에 정의된 패턴을 구문 분석하고 요청된 경로와 비교합니다.파서는 주어진 패턴을 경로 요소 트리로 바꿉니다.
파서는 첫 번째 문자를 a로 읽습니다. 구분자 경로 요소.그런 다음 다음 구분자가 나올 때까지 문자열 문자를 계속 읽으면서 새 구분자를 만듭니다. 리터럴 패스 요소.
그렇다면 사용할 때 어디에서 문제가 발생합니까? ** 패턴처럼?
다양한 경로 요소 유형이 있지만 여기서 가장 흥미로운 유형은 다음과 같습니다. 와일드카드 패스 엘레멘t 및 더 와일드카드 REST 경로 요소, 각각의 문자열 표현과 함께: * 과 /**.
A 와일드카드 경로 요소 단일 경로 세그먼트 내에서 0개 이상의 문자와 일치하는 반면 a 와일드카드 REST 경로 요소 0개 이상의 경로 세그먼트를 자체적으로 일치시킵니다 (구분 기호 포함).
후자는 제출할 때 무엇이 잘못되었는지에 대한 단서를 제공합니다. ** 패턴으로.파싱하는 동안 패턴을 찾지만 ** 예상한 포워드 슬래시로 시작하지 않습니다.그러니까, 그렇게 되기보다는 와일드카드 REST 경로 요소, 두 번 연속됩니다 와일드카드 경로 요소.
다음으로, 파싱된 패턴을 사용하여 요청된 URL과 일치시킵니다.경로는 슬래시로 시작할 것으로 예상되지만 구분자의 와일드카드는 일치하지 않습니다.
이것은 대신에 매칭 결과 요청, null이 반환됩니다.따라서 이 매처에 적용된 액세스 제어 규칙은 요청된 URL에 적용되지 않습니다.
Spring은 앞에 슬래시를 추가해 문제를 해결했습니다.다시 말해, 어떤 것이든 ** 패턴이 됩니다 /**, 다음과 같이 파싱될 수 있음을 의미합니다. 와일드카드 REST 경로 요소, 그리고 매칭 결과 요청 패턴이 이제 요청된 URL과 일치하므로 반환됩니다.
취약성 또는 API 오용?
코드가 의도한 대로 작동하기 때문에 이를 취약점으로 간주해야 하는지는 논쟁의 여지가 있습니다.문제는 기본적으로 다음과 같은 사실에 있습니다. 스프링 문서 경로가 구분자로 시작해야 한다는 명시적인 언급이 없습니다.따라서 버그나 취약점이라기보다는 API 오용 사례에 가깝다고 볼 수 있습니다.
시작하는 데 도움이 되는 리소스
%20(1).avif)
.avif)
Threat Modeling with AI: Turning Every Developer into a Threat Modeler
Walk away better equipped to help developers combine threat modeling ideas and techniques with the AI tools they're already using to strengthen security, improve collaboration, and build more resilient software from the start.
