명령 주입·XXE·역직렬화와 실행 경계

01개념과 구성 요소

• 공통 경계외부 자료가 shell·XML resolver·객체 복원기·템플릿 등 해석기의 기능을 제어할 때 문제가 생긴다.
• 성립 조건지원 기능·호출 방식·권한·노출된 자원이 실제 영향을 결정한다.
• RCE원격 코드 실행은 가능한 결과이며 모든 주입·역직렬화 문제가 같은 조건으로 RCE를 만드는 것은 아니다.

02외부 파일 검사를 안전한 실행 경로로 바꾸는 순서

1. 입력 의미 제한사용자에게 파일 경로·명령 구문 대신 허용된 자료의 ID를 받도록 설계한다.
2. 서버 자료로 해석ID를 형식·길이·권한 기준으로 검증하고 서버가 관리하는 파일 목록에서 실제 대상을 선택한다.
3. 실행 경계 선택가능하면 언어의 라이브러리로 처리한다. 외부 프로그램이 필요하면 고정 실행 파일과 인자를 분리해 shell 해석을 피한다.
4. 옵션·자원 통제Argument injection, PATH·환경·작업 디렉터리, timeout·출력 크기·최소권한을 별도로 제한한다.
5. 결과와 흔적 연결반환 코드·파일 변화·자식 프로세스를 원래 요청과 연결하고 예상한 자료 처리만 발생했는지 확인한다.

03RCE는 원인 하나가 아니라 실행 결과의 범위

• RCE와 원인RCE는 원격 입력이 실행 경계에 도달하여 대상 프로세스 권한으로 코드를 실행하는 결과를 뜻한다. OS 명령 주입·코드 평가·안전하지 않은 역직렬화·템플릿 처리·실행 가능한 업로드는 서로 다른 원인으로 실행에 도달할 수 있다.
• 프로세스 권한어느 기능이든 실제 실행은 프로세스 권한·샌드박스·접근 가능한 자원에 제한된다.
• 실행 후 도구Reverse shell·web shell·특정 프레임워크 세션은 실행 이후 가능한 도구나 통신 형태이며 RCE와 같은 분류 축의 취약점 이름은 아니다. 원격 코드 실행이 있다고 항상 관리자 권한이나 전체 네트워크 제어를 얻는다는 뜻도 아니다.
• 성립 조건인증 전후·사용자 상호작용·기능 활성화 같은 성립 조건을 함께 기술한다.

04Shell 문자열에 연결하면 구문을 공유한다

• Shell 재해석프로그램이 inspect-file 같은 외부 도구에 파일명을 넘길 때 shell 문자열을 만들면 shell이 공백·메타문자·확장·리다이렉트 등을 다시 해석한다. 애플리케이션은 이름 하나를 전달한다고 생각하지만 shell에는 여러 명령 또는 다른 구조로 보일 수 있다.
• 문법·자료 결합입력과 명령 문법을 같은 문자열에 합친 것이 경계의 문제다.
• 라이브러리·인자 배열가장 직접적인 개선은 외부 명령 없이 언어의 파일·네트워크 라이브러리를 사용하는 것이다. 꼭 외부 프로그램이 필요하면 실행 파일과 인자를 배열로 분리하여 shell을 거치지 않도록 한다.
• Argument Injection단, shell 제거는 다음 절의 argument injection까지 자동 해결하지 않는다.

# 취약 구조의 개념 예: 실행하지 않음
command = "inspect-file " + user_value
run_shell(command)

# 개선 설계
validated_id = validate_allowed_id(user_value)
path = server_owned_file_table[validated_id]
inspect_with_library(path)

원리를 설명하는 가상 학습 예시입니다.

05Argument Injection은 새 명령이 없어도 성립한다

• 옵션 해석외부 프로그램은 전달받은 인자를 자체 옵션 문법으로 해석한다. 파일명 자리에 --help 같은 값이 들어가면 shell 없이도 프로그램 동작이 달라질 수 있다.
• 지원 기능더 위험한 옵션을 지원하는 프로그램에서는 쓰기 위치·설정 파일·외부 연결 같은 기능이 선택될 수도 있다.
• 고정 실행·옵션고정된 실행 파일 경로와 허용 옵션, 입력 값의 형식·길이·범위를 따로 검증한다. 해당 도구가 지원한다면 --로 옵션 종료를 표시할 수 있지만 모든 프로그램이 같은 규칙을 사용한다고 가정하지 않는다.
• 환경 문맥PATH·환경변수·작업 디렉터리도 실행 파일 선택과 동작에 영향을 주므로 서비스의 실행 문맥을 함께 통제한다.

06정상 명령 실행에도 자원·출력 경계가 있다

• 자원 한도명령 이름이 고정되어 있어도 입력이 큰 파일·느린 주소·복잡한 변환을 선택하게 하면 CPU·메모리·worker를 오래 점유할 수 있다. timeout, 출력 크기 제한, 최소 권한, 파일·네트워크 범위 제한은 주입 예방과 별도로 실행 기능의 피해 범위를 줄인다.
• 프로세스 증거관찰 자료는 웹 요청 ID, 부모·자식 프로세스, 실행 파일, 인자, 반환 코드, 파일·연결 변화를 연결한다. 자식 프로세스가 하나 생겼다는 사실만으로 공격을 확정하지 않고 원래 기능이 생성하는 정상 프로세스와 비교한다.
• 행위 변화입력 한 개가 어떤 행위를 바꾸었는지 설명하는 것이 핵심이다.

07XML에서 Entity와 외부 Resolver

• DTD·EntityXML 파서는 태그 구조뿐 아니라 설정에 따라 DTD와 entity를 처리할 수 있다. 내부 entity는 이름을 텍스트로 치환하는 구조를 보여 준다.
• 외부 Resolver외부 entity 해석이 허용된 파서가 신뢰하지 않는 선언을 따라가면 파일이나 네트워크 자원을 읽을 수 있어 XML 입력이 서버 권한의 외부 접근으로 바뀐다.
• XXE 영향XXE의 결과는 로컬 자료 노출·SSRF·자원 소모 등이며 파서·설정·권한·응답 노출 조건에 따라 달라진다. 아래는 외부 접근을 하지 않는 내부 entity의 단순 학습 예다.
• 내부·외부 구분이를 지원한다는 사실만으로 외부 entity도 허용되는 것은 아니다.

1. XML 입력파서가 XML 구조와 지원 설정에 따라 DOCTYPE·DTD·entity 선언을 읽는다.
2. Entity 해석내부 entity는 정의된 텍스트로 치환한다. 외부 entity 해석이 허용되면 resolver가 파일·네트워크 자원에 접근할 수 있다.
3. 내용 사용해석 결과가 응답 또는 후속 처리에 사용된다. 자료 노출·SSRF·자원 소모의 실제 영향은 파서·권한·반환 경로에 달려 있다.

<!DOCTYPE note [
  <!ENTITY lesson "training-marker">
]>
<note>&lesson;</note>

개념상 치환 결과: <note>training-marker</note>
보안 정책이 DTD를 금지하면 이 입력 자체가 거부될 수 있다.

원리를 설명하는 가상 학습 예시입니다.

08XXE 방어는 실제 파서의 기능을 제한한다

• DTD 제한기능에 DTD가 필요 없다면 DOCTYPE을 거부하는 구성이 가장 단순하다. 필요하다면 외부 entity와 외부 DTD 로딩을 제한하고 확장량·깊이·크기를 제한한다.
• 다른 ResolverXInclude·스키마 검증·스타일시트 변환 등 다른 외부 자원 해석 경로도 별도 설정을 가질 수 있다.
• 네트워크 차단의 한계네트워크 송신만 막아도 로컬 파일 읽기나 내부 entity의 과도한 확장은 남을 수 있다. 반대로 entity 기능 하나를 껐다고 모든 XML 관련 외부 접근이 꺼지는 것도 아니다.
• 옵션·대조군라이브러리·버전에 맞는 보안 옵션을 적용하고 지원하지 않는 옵션 오류를 무시한 채 파싱을 계속하지 않는다. 학습에서는 정상 문서와 외부 참조가 거부되는 결과를 각각 관찰한다.

12직렬화는 표현, 역직렬화는 복원

• 직렬화·복원직렬화는 객체·값을 저장·전송할 표현으로 바꾸는 작업이고 역직렬화는 그 표현을 다시 메모리 구조로 복원하는 과정이다. 단순 JSON 값과 언어별 객체 직렬화는 같은 능력을 가지지 않는다.
• 복원기의 기능어떤 복원기는 클래스 선택·특수 메서드·상태 복구 코드를 실행할 수 있다.
• Gadget안전하지 않은 역직렬화는 신뢰하지 않는 입력이 이런 기능을 통제할 때 발생한다. Gadget은 객체 복원 과정에서 호출 관계로 연결될 수 있는 기존 코드 조각을 가리킨다.
• 다른 영향모든 역직렬화가 RCE는 아니며 자료 변조·권한 속성 조작·자원 소모처럼 다른 영향도 가능하다.

13Pickle과 자료 전용 형식

• Pickle 위험Python pickle은 신뢰할 수 없는 바이트를 안전하게 읽는 일반 데이터 포맷이 아니다. 복원 중 코드 실행이 가능하므로 외부 입력에 pickle.load/loads를 사용하는 설계는 피한다.
• 메모리 포렌식 구분포렌식에서 프로세스 메모리를 수집하는 기능과 객체 직렬화도 서로 다른 작업이다.
• JSON 스키마자료 전용 JSON을 선택해도 user.role 같은 속성을 그대로 권한에 반영하면 업무 무결성 문제가 남는다. 허용 필드·타입·길이·중첩 깊이를 검증하고 서버가 결정해야 할 값은 입력에서 받지 않는다.
• 후속 실행 경계JSON의 값들을 다시 eval·동적 객체 생성에 넣으면 처음의 안전한 자료 경계가 다시 사라진다.

import json

data = json.loads('{"item":"lesson-42","quantity":2}')
if not isinstance(data, dict) or set(data) != {"item", "quantity"}:
    raise ValueError("unexpected fields")
if not isinstance(data["item"], str):
    raise ValueError("invalid item")
if type(data["quantity"]) is not int or not 1 <= data["quantity"] <= 10:
    raise ValueError("invalid quantity")
# 가격·소유자·권한은 서버 자료와 현재 세션에서 결정

가상 자료의 필드·타입·범위를 검사하는 학습 예입니다.

14템플릿 입력과 템플릿의 값

• 템플릿·자료 값템플릿 엔진은 작성자가 정한 표현식·조건·반복과 자료 값을 결합한다. 사용자 이름을 템플릿의 데이터 값으로 전달하는 것과 사용자 문자열을 새로운 템플릿 소스로 컴파일하는 것은 다르다.
• 소스 컴파일후자는 사용자가 엔진의 표현식 문법에 영향을 줄 수 있다.
• SSTI 영향SSTI의 실제 영향은 엔진이 노출한 함수·객체·sandbox·권한에 따라 달라진다. 템플릿 표현식이 평가되었다는 관찰과 OS 명령 실행을 증명했다는 결론을 구분한다.
• 기능 제한사용자에게 서식 기능이 필요하면 허용하는 언어와 접근 객체를 제한하고, 일반 텍스트 입력은 코드가 아닌 값으로 다룬다.

15검증·서명·권한은 서로 다른 방어층

• 서명·검증 순서서명이나 MAC은 신뢰한 생산자가 만든 바이트인지 검증하는 데 도움이 되지만 생산자가 위험한 내용을 만들 수 있거나 검증 전에 역직렬화하면 목적을 달성하지 못한다. 형식 검증·출처 검증·실행 권한 제한을 서로 대체할 수 없다.
• 문법별 통제한 문자열 필터로 SQL·shell·XML·HTML의 다른 문법을 모두 막는 접근도 정확하지 않다.
• 정상·거부 결과정상 입력의 기대 결과와 거부해야 할 구조, 오류 시 정리되는 자원, 로그에 남는 원인을 연결한다. 파서가 어떤 문법과 자원 접근을 지원하는지에 따라 입력 한 개의 의미가 달라지므로, 겉으로 같은 문자열이라도 SQL·shell·XML·템플릿에서 다른 검증 기준을 적용해야 한다.