mvcRequestMatcher Spring 취약점 자세히 살펴보기

게시일: 2023년 4월 19일
by Brysen Ackx
사례 연구

mvcRequestMatcher Spring 취약점 자세히 살펴보기

게시일: 2023년 4월 19일
by Brysen Ackx
리소스 보기
리소스 보기
노란색 기하학적 추상 배경 위의 해골 아이콘
노란색 기하학적 추상 배경 위의 해골 아이콘

2023년 3월 20일, 봄 보안 권고에서는 내부적으로 발견된 취약점인 CVE-2023-20860을 언급하는 블로그 게시물을 발표했습니다. 자세한 정보는 공개되지 않았으며, mvcMatchers 사용과 관련된 액세스 제어 문제라는 것 외에는 공개되지 않았습니다. Spring 개발자가 이 문제를 해결했으며, 버전 업데이트를 권장하고 있습니다.

직접 체험해보고 싶으신가요? 여기에서 미션을 수행해 보세요.

보안이 저희의 주요 관심사이므로 Secure Code Warrior에서 보안에 중점을 두고 있는 만큼, 저희는 이 mvcRequestMatchers 취약점에 대해 자세히 살펴보고 핵심 문제가 어디에 있는지 파악하기로 결정했습니다.

Spring은 요청이 경로 패턴과 일치하는지 확인하기 위해 RequestMatcher 인터페이스를 제공합니다. 아래 코드 스니펫에서 인증 및 권한 부여 요구 사항과 함께 엔드포인트를 등록하는 데 mvcMatchers 헬퍼 메서드가 사용되는 부분을 살펴보세요. 예를 들어 ADMIN 역할의 사용자만 /logs/감사 엔드포인트에 액세스할 수 있음을 알 수 있습니다. 

MvcMisMatchers?

Spring에서 **는 URL에 있는 디렉터리 및 하위 디렉터리를 원하는 수만큼 일치시키는 패턴입니다. 예를 들어 /bankaccount/**는 /bankaccount/로 시작하는 모든 URL과 일치하며, 하위 디렉터리(예: /bankaccount/dashboard/settings)도 포함됩니다. 

패턴은 모든 URL과 일치하며 하위 디렉터리의 레벨이 정확히 한 단계인 패턴입니다. 예를 들어 /bankaccount/*는 bankaccount/dashboard와 일치합니다.

사용하여 일치자를 구성할 때 Spring은 "스프링 보안과 스프링 MVC 간의 패턴 일치 불일치" 가 발생하여 취약점이 발생했다고 명시합니다.

기본적으로 이중 와일드카드 앞에 구분 기호가 없기 때문에 들어오는 모든 요청 앞에 슬래시가 붙기 때문에 경로가 들어오는 요청과 일치하지 않습니다. 즉, 액세스 제어 규칙이 적용되지 않아 인증되지 않은 사용자가 리소스에 액세스할 수 있습니다.

문제를 해결한 커밋을 살펴보겠습니다.

가장 눈에 띄고 중요한 변경 사항은 권한 부여 및 인증 규칙의 우회를 수정하는 315번째 줄이 추가된 것입니다. 제출되는 모든 경로 패턴 앞에 슬래시(/)가 추가되도록 합니다. 

404 일치하는 항목을 찾을 수 없음

PathPatternMatchableHandlerMapping 클래스 (소스 스프링 프레임워크)

은행계좌/보기로 웹 요청을 보낼 때 일치 메서드는 보안 필터에 정의된 패턴을 구문 분석하고 요청된 경로와 비교합니다. 구문 분석기는 주어진 패턴을 경로 요소의 트리로 변환합니다.

구문 분석기는 첫 번째 문자를 SeparatorPathElement로 읽습니다. 그런 다음 다음 구분 기호까지 문자열 문자를 계속 읽어서 새로운 LiteralPathElement를 생성 합니다.

패턴으로 **를 사용할 때 어떤 문제가 발생할까요? 

많은 경로 요소 유형이 있지만, 여기서 가장 흥미로운 것은 각각의 문자열 표현을 가진 WildcardPathElement와 WildcardTheRestPathElement입니다: * 와 /**입니다

와일드카드 경로 요소는 단일 경로 세그먼트 내에서 0개 이상의 문자를 일치시키는 반면, 와일드카드 나머지 경로 요소는 자체적으로 0개 이상의 경로 세그먼트(구분 기호 포함)를 일치시킵니다.

후자는 **를 패턴으로 제출할 때 무엇이 잘못되었는지에 대한 단서를 제공합니다. 구문 분석 중에 패턴을 찾지만 **는 예상되는 슬래시로 시작하지 않습니다. 따라서 WildcardTheRestPathElement가 되는 대신 두 개의 연속된 WildcardPathElement가 됩니다.

그런 다음 구문 분석된 패턴을 사용하여 요청된 URL과 일치시킵니다. 경로는 슬래시로 시작해야 하지만 와일드카드는 구분 기호에 일치하지 않습니다.

WildCardPathElement.java에서 발췌한 내용

즉, RequestMatchResult 대신 null이 반환됩니다. 따라서 이 매칭기에 설정된 액세스 제어 규칙은 요청된 URL에 적용되지 않습니다.

Spring은 슬래시를 추가하여 이 문제를 해결했습니다. 즉, ** 패턴은 /**가 되어 와일드카드TheRestPathElement로 구문 분석될 수 있으며, 이제 패턴이 요청된 URL과 일치하므로 RequestMatchResult가 반환됩니다.

취약점 또는 API 오용?

코드가 의도한 대로 작동하기 때문에 이것이 취약점으로 간주되어야 하는지 여부는 논쟁의 여지가 있습니다. 이 문제는 기본적으로 Spring 문서에 경로를 구분 기호로 시작해야 한다는 명시적인 언급이 없다는 사실에 있습니다. 따라서 버그나 취약점이라기보다는 API 오용의 사례로 간주할 수 있습니다.

리소스 보기
리소스 보기

CVE-2023-20860 임무

미션을 통해 그 영향을 직접 경험하고 비슷한 실수를 피하는 방법을 알아보세요.

지금 체험하기
저자

브라이슨 악스

Brysen은 보안 코드 작성에 중점을 둔 소프트웨어 개발자( Secure Code Warrior )입니다.

더 알고 싶으신가요?

블로그에서 최신 보안 코딩 인사이트에 대해 자세히 알아보세요.

Atlassian의 광범위한 리소스 라이브러리는 안전한 코딩 숙련도를 확보하기 위한 인적 접근 방식을 강화하는 것을 목표로 합니다.

블로그 보기
더 알고 싶으신가요?

개발자 중심 보안에 대한 최신 연구 보기

광범위한 리소스 라이브러리에는 개발자 중심의 보안 코딩을 시작하는 데 도움이 되는 백서부터 웨비나까지 유용한 리소스가 가득합니다. 지금 살펴보세요.

리소스 허브

mvcRequestMatcher Spring 취약점 자세히 살펴보기

게시일: 2023년 4월 19일
By 브라이슨 악스

2023년 3월 20일, 봄 보안 권고에서는 내부적으로 발견된 취약점인 CVE-2023-20860을 언급하는 블로그 게시물을 발표했습니다. 자세한 정보는 공개되지 않았으며, mvcMatchers 사용과 관련된 액세스 제어 문제라는 것 외에는 공개되지 않았습니다. Spring 개발자가 이 문제를 해결했으며, 버전 업데이트를 권장하고 있습니다.

직접 체험해보고 싶으신가요? 여기에서 미션을 수행해 보세요.

보안이 저희의 주요 관심사이므로 Secure Code Warrior에서 보안에 중점을 두고 있는 만큼, 저희는 이 mvcRequestMatchers 취약점에 대해 자세히 살펴보고 핵심 문제가 어디에 있는지 파악하기로 결정했습니다.

Spring은 요청이 경로 패턴과 일치하는지 확인하기 위해 RequestMatcher 인터페이스를 제공합니다. 아래 코드 스니펫에서 인증 및 권한 부여 요구 사항과 함께 엔드포인트를 등록하는 데 mvcMatchers 헬퍼 메서드가 사용되는 부분을 살펴보세요. 예를 들어 ADMIN 역할의 사용자만 /logs/감사 엔드포인트에 액세스할 수 있음을 알 수 있습니다. 

MvcMisMatchers?

Spring에서 **는 URL에 있는 디렉터리 및 하위 디렉터리를 원하는 수만큼 일치시키는 패턴입니다. 예를 들어 /bankaccount/**는 /bankaccount/로 시작하는 모든 URL과 일치하며, 하위 디렉터리(예: /bankaccount/dashboard/settings)도 포함됩니다. 

패턴은 모든 URL과 일치하며 하위 디렉터리의 레벨이 정확히 한 단계인 패턴입니다. 예를 들어 /bankaccount/*는 bankaccount/dashboard와 일치합니다.

사용하여 일치자를 구성할 때 Spring은 "스프링 보안과 스프링 MVC 간의 패턴 일치 불일치" 가 발생하여 취약점이 발생했다고 명시합니다.

기본적으로 이중 와일드카드 앞에 구분 기호가 없기 때문에 들어오는 모든 요청 앞에 슬래시가 붙기 때문에 경로가 들어오는 요청과 일치하지 않습니다. 즉, 액세스 제어 규칙이 적용되지 않아 인증되지 않은 사용자가 리소스에 액세스할 수 있습니다.

문제를 해결한 커밋을 살펴보겠습니다.

가장 눈에 띄고 중요한 변경 사항은 권한 부여 및 인증 규칙의 우회를 수정하는 315번째 줄이 추가된 것입니다. 제출되는 모든 경로 패턴 앞에 슬래시(/)가 추가되도록 합니다. 

404 일치하는 항목을 찾을 수 없음

PathPatternMatchableHandlerMapping 클래스 (소스 스프링 프레임워크)

은행계좌/보기로 웹 요청을 보낼 때 일치 메서드는 보안 필터에 정의된 패턴을 구문 분석하고 요청된 경로와 비교합니다. 구문 분석기는 주어진 패턴을 경로 요소의 트리로 변환합니다.

구문 분석기는 첫 번째 문자를 SeparatorPathElement로 읽습니다. 그런 다음 다음 구분 기호까지 문자열 문자를 계속 읽어서 새로운 LiteralPathElement를 생성 합니다.

패턴으로 **를 사용할 때 어떤 문제가 발생할까요? 

많은 경로 요소 유형이 있지만, 여기서 가장 흥미로운 것은 각각의 문자열 표현을 가진 WildcardPathElement와 WildcardTheRestPathElement입니다: * 와 /**입니다

와일드카드 경로 요소는 단일 경로 세그먼트 내에서 0개 이상의 문자를 일치시키는 반면, 와일드카드 나머지 경로 요소는 자체적으로 0개 이상의 경로 세그먼트(구분 기호 포함)를 일치시킵니다.

후자는 **를 패턴으로 제출할 때 무엇이 잘못되었는지에 대한 단서를 제공합니다. 구문 분석 중에 패턴을 찾지만 **는 예상되는 슬래시로 시작하지 않습니다. 따라서 WildcardTheRestPathElement가 되는 대신 두 개의 연속된 WildcardPathElement가 됩니다.

그런 다음 구문 분석된 패턴을 사용하여 요청된 URL과 일치시킵니다. 경로는 슬래시로 시작해야 하지만 와일드카드는 구분 기호에 일치하지 않습니다.

WildCardPathElement.java에서 발췌한 내용

즉, RequestMatchResult 대신 null이 반환됩니다. 따라서 이 매칭기에 설정된 액세스 제어 규칙은 요청된 URL에 적용되지 않습니다.

Spring은 슬래시를 추가하여 이 문제를 해결했습니다. 즉, ** 패턴은 /**가 되어 와일드카드TheRestPathElement로 구문 분석될 수 있으며, 이제 패턴이 요청된 URL과 일치하므로 RequestMatchResult가 반환됩니다.

취약점 또는 API 오용?

코드가 의도한 대로 작동하기 때문에 이것이 취약점으로 간주되어야 하는지 여부는 논쟁의 여지가 있습니다. 이 문제는 기본적으로 Spring 문서에 경로를 구분 기호로 시작해야 한다는 명시적인 언급이 없다는 사실에 있습니다. 따라서 버그나 취약점이라기보다는 API 오용의 사례로 간주할 수 있습니다.

우리는 당신에게 우리의 제품 및 / 또는 관련 보안 코딩 주제에 대한 정보를 보낼 수있는 귀하의 허가를 바랍니다. 우리는 항상 최대한의주의를 기울여 귀하의 개인 정보를 취급 할 것이며 마케팅 목적으로 다른 회사에 판매하지 않을 것입니다.

양식을 제출하려면 '분석' 쿠키를 활성화하세요. 완료되면 언제든지 다시 비활성화할 수 있습니다.