[ 이론 ]
Concept
이 과정에서는 XML 외부 엔티티 공격 수행법과 XML 외부 엔티티가 악용 및 보호되는 방법에 대해 설명한다.
Goals
- XML에 대한 기본적인 지식을 갖는다.
- XML parser 작동 방식에 대해 이해할 수 있다.
- XXE 공격 수행과 이에 대한 대응법을 배운다.
What is an XML entity?
XML Entity는 XML 문서를 구문 분석할 때 구문으로 대체되는 태그를 정의할 수 있다. 기본적으로 3가지 type의 엔티티가 있다.
1. 내부 엔티티
2. 외부 엔티티
3. 파라미터 엔티티
엔티티는 DTD(Document Type Definition)에서 만들어진다. 예시에서 시작하자 :
XML 문서 구문 분석기에 의해 처리될 때 볼 수 있듯, "js" 엔티티는 정의된 "Jo Smith" 구문으로 대체될 것이다. 보시다시피 js를 한 곳에서 "John Smith"로 변경할 수 있어 많은 장점이 있다.
Java application에서 XML을 사용하여 클라이언트에서 서버로 데이터를 가져올 수 있으며, 우리는 모두 Json api들에 익숙하고 XML을 사용해 정보를 전달 할 수 있다. 대부분의 경우 프레임워크는 xml 구조에 따라 java 객체를 자동으로 채운다.
What is an XXE injection?
XML 외부 엔터티 공격은 XML 입력을 구문 분석하는 응용 프로그램에 대한 공격 유형입니다. 이 공격은 약하게 구성된 XML 구문 분석기에서 외부 엔터티에 대한 참조를 포함하는 XML 입력을 처리할 때 발생합니다. 이 공격은 기밀 데이터 노출, 서비스 거부, 서버 측 요청 위조, 파서가 위치한 시스템의 관점에서 포트 스캔 및 기타 시스템 영향을 초래할 수 있습니다.
공격은 시스템 식별자의 file: schemes 또는 relative path를 사용하여 암호 또는 개인 사용자 데이터와 같은 중요한 데이터를 포함할 수 있는 로컬 파일을 노출하는 것을 포함할 수 있습니다. XML 문서 처리하는 Application 관련되어 공격이 일어날 때, 공격자는 그 외의 내부 시스템으로 pivot하여 http 요청을 통해 다른 내부 내용을 노출하거나 보호되지 않은 내부 서비스에 대한 CSRF 공격을 시작할 수 있습니다. 경우에 따라 클라이언트 측 메모리 손상 문제에 취약한 XML 프로세서 라이브러리가 악의적인 URI를 역참조하여 악용될 수 있으며, 이를 통해 응용 프로그램 계정에서 임의코드가 실행될 수 있다. 다른 공격은 데이터 반환을 중지하지 않는 로컬 리소스에 액세스하여 너무 많은 스레드 또는 프로세스가 릴리스되지 않을 경우 응용프로그램 가용성에 영향을 줄 수 있다.
일반적으로 다음과 같은 종류의 XXE 공격을 구별할 수 있다.
- Classic : 이 경우 외부 엔티티가 로컬 DTD에 포함됩니다.
- Blind : 응답에 출력 및 오류가 표시되지 않음
- Error : 오류 메시지에 리소스 내용 가져옴
* CSRF : 인터넷 사용자(희생자)가 자신의 의지와는 무관하게 공격자가 의도한 행위(수정, 삭제, 등록 등)를 특정 웹사이트에 요청하게 만드는 공격.
- 희생자의 권한을 도용하여 중요 기능 실행 가능 (ex) 페이스북에 희생자의 계정으로 광고성 글 업로드
- CSRF의 조건
(1) 위조 요청을 전송하는 서비스에 희생자가 로그인한 상태 (2) 희생자가 해커가 만든 피싱 사이트에 접속
- CSRF 방어기법
(1) Referrer 검증 (2) Security Token 사용 (A.K.A CSRF Token)
-- CSRF 공격 방어는 조회성 데이터 방어 X, 쓰기/변경 가능한 POST, PATCH(특정 필드 수정), DELETE Method에만 적용
(Get을 통해 쓰기 및 변경 한다면 GET도 방어 필요)
(1) Referrer 검증 : Back-end 단에서 request의 reffer를 확인하여 domain이 일치하는 지 검증, 다른 도메인에서 이 요청이 들어오기 시작한 것인지 확인하기 위해서, BUT 같은 도메인 내의 페이지에 XSS 취약점이 있으면 CSRF에 취약해질 수 있음.
(2) Security Token 사용 : 사용자의 세션에 임의의 난수 값을 저장, 사용자의 요청마다 난수값 포함 전송, 토큰값 일치 확인 및 검증. BUT 같은 도메인 XSS면 취약
(3) Double Submit Cookie 검증 : 세션 사용 불가 환경에서 사용, Same Origin 정책으로 타 도메인 쿠키 확인/수정 불가. 난수 값을 쿠키에 저장하고 동일한 난수 값 요청 파라미터(혹은 헤더)에 저장하여 서버로 전송. 서버단에서 쿠키의 토큰값과 파라미터 토큰값 일치 여부 검사. 피싱 사이트는 도메인이 달라 정상 쿠키에 값 저장이 불가하여 가능한 방어 기법.
그니깐 어차피 정상 쿠키는 우리만 만들 수 있으니깐 거기에 난수값을 저장한 다음에 얘가 파라미터로 보내는 난수값이 그 수정 불가한 쿠키 속 난수랑 같은지 확인한다.
일반적으로 다음과 같은 종류의 XXE 공격을 구별할 수 있습니다.
1. Classic: 이 경우 외부 엔티티가 로컬 DTD(Document Type Definition)에 포함됨
2. Blind: 응답에 출력 및 오류가 표시되지 않음
3. Error: 오류 메시지에서 리소스 내용을 가져옴
XXE example
XXE Injection의 예시를 살펴본다. 다음과 같이 사용할 수 있
<?xml version="1.0" standalone="yes" ?>
<!DOCTYPE author [
<!ELEMENT author (#PCDATA)>
<!ENTITY js "Jo Smith">
]>
<author>&js;</author>
External DTD declaration
이러한 엔티티를 정의하면 외부 파일에 다른 DTD를 정의 할 수 있다.
<?xml version="1.0"?>
<!DOCTYPE note SYSTEM "email.dtd">
<email>
<to>webgoat@webgoat.org</to>
<from>webwolf@webwolf.org</from>
<subject>Your app is great, but contains flaws</subject>
<body>Hi, your application contains some SQL injections</body>
</email>그리고 "email.dtd"는 다음과 같이 정의되어 있다.
<!ELEMENT email (to,from,title,body)>
<!ELEMENT to (#PCDATA)>
<!ELEMENT from (#PCDATA)>
<!ELEMENT subject (#PCDATA)>
<!ELEMENT body (#PCDATA)>
XXE
XML parser(구문분석기)가 외부 DTD 또는 엔티티를 허용하도록 구성된 경우 다음 XML 조각을 변경할 수 있다.
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE author [
<!ENTITY js SYSTEM "file:///etc/passwd">
]>
<author>&js;</author>file에서 불러오는거로 바뀜.
로컬 파일 시스템에서 include를 정의했다. XML parser는 파일을 로드하고 엔티티가 참조되는 모든 위치에 내용을 추가한다. XML 메시지가 사용자에게 반환된다고 가정한다.
추가 문서 유형 정의(DOCTYPE)는 XML 문서에 항상 추가할 수 있으며 외부 엔티티를 처리하도록 파서 설정을 활성화한 경우 XXE Injection을 찾는 것이 좋다.
[ 문제 & 풀이 ]
Let's try
이 과제에서 사진에 설명을 추가하고 양식을 제출할 때 설명 필드로 XXE Injection 실행하라. 파일 시스템의 루트 디렉토리를 나열해보라.
버프 스위트로 comment 올라가는 submit에 태그를 변경한다.
'강의 및 교육 > Inflearn - Webgoat' 카테고리의 다른 글
| XXE - 11. Blind XXE assignment (0) | 2022.02.19 |
|---|---|
| XXE - 7. Modern REST framework (0) | 2022.02.19 |
| JWT tokens - 10. Refreshing a token (0) | 2022.02.14 |
| JWT tokens - 8. JWT cracking (0) | 2022.02.11 |
| JWT tokens - 7. Code review (0) | 2022.02.11 |
