작성
·
26
0
XXE Injection 취약점을 효과적으로 방어하기 위한 핵심 보안 대책은 무엇일까요?
답) XML 파서에서 외부 엔티티 및 DTD 처리 기능 비활성화
문제가 이런식으로 되어있고, 답이 외부 엔티티 참조 기능 비활성화인데 왜 그런지 이해가 되질 않습니다. XXE Injection 취약점을 효과적으로 방어하는 것은 XML 데이터 형식을 JSON 으로 변경하거나 서비스가 불필요한 경우 XML Parsing 기능을 제거하는 것이 가장 효과적인게 아닌가요? 만약 아니라면 외부 개체 참조 기능을 비활성화 하는것이 가장 효과적이란 것이고, 그렇다면 단순히 소스 코드에서 외부 개체 참조 기능을 비활성화만 하면 되는데 왜 굳이 JSON 형식으로 변환하는 등의 대응 방안이 추가로 제시되는 건가요?? 개발자 입장에선 데이터 포맷을 XML 에서 JSON 으로 변경하는 것보다 코드 1~2줄 추가하는 것이 더 간단하지 않나요?? 아니면 시스템 운영 상황에 따라 외부 엔티티 참조 기능을 비활성화를하지 못하는 경우가 따로 있는걸까요?? 만약, 그렇다면 혹시 예시도 함께 들어주실 수 있을까요??
질문이 너무 난잡하지만 요약하면 아래와 같습니다.
효과적인 대응 방안이 왜 외부 엔티티 참조 기능 비활성화 인지
만약 그렇다면 어째서 간단하고 효과적인 대응 방안(외부 엔티티 참조 기능 비활성화)이 있는데 굳이 더 복잡한 대응 방안인 JSON 형식으로 변환하는 등의 추가적인 대응 방안이 제시되는지
외부 엔티티 참조 기능을 비활성화 했을때 운영중인 서비스에 문제가 가는 경우도 있는지 만약 그렇다면 예시도 함께 들어주실 수 있는지
긴 질문 읽어주셔서 감사합니다.
답변 1
0
안녕하세요.
XXE 취약점에 대한 대응 방안은 "외부 엔티티 및 DTD 처리 기능 비활성화"가 맞습니다. 기존의 기능 자체가 XML 파서이기에 기존 기능을 유지한 상태에서의 대응 방안이 근본적 대응 방안이 맞습니다.
추가 대응 방안에 대한 부분은 컨설턴드들의 기본적인 부분입니다. 고객사에 따라서 A 대응 방안이 안되면 B 혹은 C 등의 선택지를 두는 것이 좋습니다. 현재 기능은 XML 파서를 사용하지만 레거시 시스템이고 새로운 기능들에서 JSON 파서를 사용하는 상태라면 개발자가 JSON 파서 기능 구현 또한 충분히 고려해볼 수 있는 요소입니다.
레거시 시스템에서 외부 문서들을 참조하는 경우들이 있는데 이 기능들의 경우 문제가 발생될 수 있습니다. 이경우 허용된 DTD만 참조하는 대응 방안을 고려해 볼 수 있습니다. 아니면 관리자 기능에서 발생이 되었을 경우 기존 기능을 강화하고 인증 기능들에 대한 부분의 보안 강화하는 차선책등을 고려해 볼 수 있습니다.
일반적이론 저희가 대응 방안에 대해 여러개를 제시합니다. 예를들어, SQL 인젝션의 경우 근본적인 대응 방안은 Prepared Statement 입니다. 머 저희 입장에선 이것만 대응 방안으로 제시를 하면 좋죠. 간단하기도 하구요. 그러나 추가로 사용자 입력 값에 따른 검증 로직을 추가로 제시 합니다. 이유는 개발자의 환경에 따라 Prepared Statement를 적용하지 못하는 경우도 있습니다.(이유는 엄청 다양한 경우가 많습니다. 핑계인 경우도 있구요.) 따라서 다양한 대응 방안 제시를 통해 취사선택을 할 수 있게끔하는 것이 컨설턴트라서 다양한 방안을 제시한 것입니다.
자세하게 설명해주셔서 감사합니다!! 덕분에 궁금한 점이 시원하게 해결됐습니다!!