Xpath 인젝션(XI)

주요정보통신기반 웹 취약 분석 평가 방법 7번째 항목인 Xpath 인젝션(Xpath Injection/XI)이다.

Xpath 인젝션은 XML 데이터를 다룰 때 사용하는 Xpath 쿼리문을 이용하여 인젝션을 수행하는 공격이다.

 

뭐 으레 그랬듯이 Xpath 인젝션이 여전히 자주 발생되는 공격인지에 대해 알아보고 가긴 하는데..

다른 정리 잘 된 블로그들 보면 나처럼 이렇게 쓸데없이(?) 서론을 가지고 시작하진 않는데 그냥 나도 깔끔하게 이러한 공격이 있고 뭐 대응방안은 이러하고 이 정도만 해도 되지 않을까 라는 생각이 좀 든다.

솔직히 내가 알고 싶어서 정리하는게 큰 건 맞지만 이런 차별점이라도 둬야될 것만 같은 느낌이랄까

모르겠다. 그냥 열심히 해보자..

 

우선 XML(eXtenstion Markup Language)은 여러 특수한 목적의 마크업 언어를 만드는 용도로 권장되는 다목적 마크업 언어라고 한다. HTML과 유사하면서 미리 정의된 태그 없이 필요한 태그를 직접 정의하여 데이터의 구조나 시각적 모양, 의미를 정의한다.

이런 XML을 이용하여 동일한 데이터를 서로 다른 형식으로 저장하는 시스템 간 전송이나 데이터를 저장하는 등으로 활용할 수 있다.

 

다만 이것 역시 쓰이기는 하나 많이 활용되진 않는다.

일단 구문 자체가 절대 가볍지 않고 직관적이지도 않다. >> JSON으로 대체됨.

그리고 Xpath 쿼리로 사용자 입력을 받게 하는 앱도 요즘 들어서는 거의 없다.

그래서 Xpath 인젝션 자체는 굉장히 희박하게 일어난다. 그러나 XML을 파싱하는 애플리케이션을 공격하는 XXE는 최근에도 일어나고 중요하게 지켜볼 만한 취약점이다. 당장 살펴봐도 최근에 일어났음,,

 

이제 bWAPP(요거 좋네 ㅎ)에서 Xpath 인젝션을 살펴볼건데 그 전에! 대략 어떤 식으로 XML이 구성되어 있을지 보자

우선 XML로 구성된 로그인 폼이다.

 

<group>
	<user>
		<username>cat</username>
		<password>ragdo11</password>
	</user>
	<user>
		<username>s</username>
		<password>ws</password>
	</user>
</group>

xml로 유저들을 저장한다면 위와 같은 형태로 저장이 된다. 여기서 cat 사용자를 출력하는 xpath 쿼리는

 

/group/user[username='cat' and password='ragdo11']

이와 같이 된다. 보면 느낌이 오겠지만 저장할 데이터의 정보나 속성에 따라 태그를 지정해서 사용하므로 데이터를 구분하기는 좋으나 상세한 만큼 간결한 느낌이 없다.

 

다시 로그인 폼으로 돌아가면 위의 코드 형태를 따를텐데 그러면 SQLi에서 했던 우회 방법을 사용해볼 수 있을 것 같다.

원래는 당연히 블랙박스 형태로 테스트 하는게 기본이지만 처음 접하는 거기도 하고 공부용이니까 먼저 소스 코드를 조금만 보면

위에서 한 것과 완전 같다는 것을 알 수 있다. 그리고 추가로 id > neo / pw > trinity 로 로그인할 수 있다는 것도 알 수 있었다.

그럼 or로 참을 만들어서 우회해볼까??

 

 

id > neo' or '1'='1
pw > 1
==================
payload = /heroes/hero[login='neo' or '1'='1' and password='1']

비밀번호를 모르는 공격자라 하더라도 우회가 가능하다. SQL과 조금 다른 점은 주석이 없기 때문에 아래와 같은 우회는 불가능하다.

 

id > ' or '1'='1'#
pw > NA

그렇기 때문에 만약 아이디도 모르겠다면 다른 형태의 페이로드를 고안해봐야 한다!

 

/heroes/hero[login='' or '1'='1' and password='']
::after=====================================================
/heroes/hero[login='' or '1'='1' or '1'='1' and password='']

그냥 아이디에 or '1'='1' 이 한 번 더 들어가도록 구성해주었다. 그럼 무슨 차이가 날까?

or 보다는 and가 우선순위가 빠르다. SQL도 그렇고 지금 Xpath 표현식도 그렇고 다 그런지는 모르겠다. 무조건이란 생각은 위험하다 보니까

아무튼 그렇기 때문에 첫 페이로드는 T and F > F가 될꺼고 그 다음 F or F 이기 때문에 구문 자체가 거짓이 되어버린다.

 

그럼 두 번째 페이로드는?? 역시 T and F > F가 되지만 앞의 F or T가 계산되어 T가 계산되고 마지막으로 중간의 or이 T or F를 받으니까 최종적으로 True! 인 문장이 된다.

 

그나마 얘가 SQL이랑 가장 유사한 것 같다. Blind Xpath 공격도 가능했음

id = ' substring(login,1,1)='n' or '1'='1
pw = 1
=========================================
payload = /heroes/hero[login='' substring(login,1,1)='n' or '1'='1' and password='1']

굳이 설명하지 않아도 될 거라 생각한다. 이런 식의 blind가 작동도 함!!

 

보안설정방법을 보기 전에! 점검 방법에 처음 보는 구문이 있길래 해석해보자.

‘ or count(parent::*[position()=1])=0 or ‘a’='b
‘ or count(parent::*[position()=1])>0 or ‘a’='b
1 or count(parent::*[position()=1])=0
1 or count(parent::*[position()=1])>0

 

먼저 parent::* 이것은 현재 부모 노드 중에서 모든 노드를 선택한다는 의미이다.

[position()=1] 이건 그 중에서 첫 번째 노드만 선택하라는 의미이고

count는 그냥 수를 세는 것. 만약 선택이 되어서 부모 노드가 잡혔다면 0이 아니니 False가 나올 것이고 선택이 되지 않아서 0이 나왔으면 True가 나올 것이다.

 

결국은 Xpath 구문을 인젝션할 수 있는지 테스트하기 위한 테스트용 구문인 것 같다.

 

자 보안설정방법

• XPath 쿼리에 사용자가 값을 입력할 수 있는 경우, 엄격한 입력 값 검증을 통해 필요 문자만을 받아들이게 함 ( ) = ‘ [ ] : , * / 등 XPath 쿼리를 파괴하는 특수문자는 입력하지 못하게 하여야 하며, 특정 특수문자만을 필터링하는 것이 아닌 허용된 문자 이외의 모든 입력을 허용하지 않아야 함

역시 입력값 검증