it-swarm-korea.com

XML 문서가 "잘 형성된"것으로 확인되지 않거나 스키마에 대해 확인되지 않은 경우 어떤 위험이 있습니까?

내 응용 프로그램에서 XML 문서를 처리 할 때 어떤 위험이 있습니까? 예 : "Well Formed"가 아니거나 스키마에 대해 확인되지 않은 경우.

11
Phoenician-Eagle

"잘 형성된"XML 문서가 있어도 공격을 막을 수는 없습니다. 삽입이 항상 XML 문서를 손상시키는 것은 아닙니다. XML 주입 공격을 방지하려면 다음 조치가 도움이 될 것입니다.

  • 유효한 XML 스키마 정의를 확인하십시오.
  • 입력 유효성 검사/정리;
  • 인코딩 확인 및 시행

내 답변의 완성도를 위해 몇 가지 유용한 링크를 추가하고 싶습니다.

8
anonymous

DTD와 XSD를 사용한 안전한 XML 처리는 까다 롭습니다.

파서로 xml 파일을 처리하기 전에 올바른 dtd 및 xsd가 사용 사례에 대해 참조되는지 확인해야합니다 (대체 xmlns, xml의 로컬 dtd 정의, 엔티티 확장 등과 같은 혼합 된 xml 콘텐츠가 추가되지 않음).

OWASP 팟 캐스트에서 들었던 것처럼 OWASP 팟 캐스트 다운로드는 여기 , 특히이 맥락과 관련이 있으며, 허용 된 데이터 (xml 콘텐츠)를 화이트리스트에 추가하고 해당 콘텐츠에 대해 알려진 문제를 블랙리스트에 올리지 마십시오.

외부 참조를 끄는 것은 좋습니다 (다른 사람이 dtd 대신 file : // 프로토콜을 사용하여 참조하여/etc/passwd 또는/etc/shadow 파일을 읽는 것에 대해 생각해보십시오).

리졸버와 카탈로그 파일을 사용하여 외부 참조를 전복 할 수없는 알려진 양호한 로컬 복사본으로 제어/대체 할 수 있습니다 . http://xml.Apache.org/commons/components/resolver/resolver-article.html

Sun/Oracle의 다중 스키마 유효성 검사기와 같은 외부 유효성 검사 프로그램/라이브러리를 사용할 수 있습니다. http://msv.Java.net/ 내부적으로 검증 할 것이없는 경우에도 검증을 제공 할 수 있으며 RELAX NG)와 같은 다른/보완적인 기술을 사용할 수 있습니다. = xml의 유효성을 검사합니다.

모든 종류의 인젝션 (SQL, Javascript, xmlns, 이미지, svg, url, xslt, xpath 등)에주의하십시오. 모두 잠재적으로 인젝션되어 DB 서버에 위험이 될 수있는 컨텍스트로 전송 될 수 있기 때문입니다. 앱 서버 또는 클라이언트 환경. 인프라 내부의 웹 페이지로 전송되는 IE 손상이있는 base64 인코딩 이미지 (게임 종료)를 고려하십시오.

XML 처리 인프라에 대한 서비스 거부도 문제가 될 수 있지만 시스템과 관련이 없을 수 있습니다.

참고 : @anonymous는 관련 리소스에 대한 훌륭한 URL을 제공했습니다.

6
Andrew Russell

XML 구문 검사를하지 않는 주요 위험은 잘못된 구문 분석입니다.

XML을 읽는 소프트웨어가 유효하지 않은 입력을 처리 할 수없는 경우 충돌하거나 예상치 못한 작업을 수행하거나 자발적으로 폭발 (아마도 불가능) 할 수 있습니다. 이러한 상황은 보안 결함으로 이어질 수 있습니다. 그러나 소프트웨어가 충분히 취약하여 잘못된 XML을 처리하면 "유효한"데이터에서도 다른 보안 결함이있을 가능성이 높습니다.

비유로 대부분의 웹 앱 보안 허점 (예 : SQL 삽입)은 잘못된 HTML을 사용하여 공격을받지 않지만 구문 분석시 문제를 일으키는 구문 상 유효한 입력입니다. 귀하의 경우 XML이 입력입니다. 특히 XSD/DTD/무엇이든 자동 생성 된 경우 스키마 검사는 입력을 확인하는 데 충분하지 않습니다. 애플리케이션 자체에서 입력을 처리하는 것이 무엇이든이를 확인해야합니다.

5
Shewfig