SSRF·XXE·기타 응용 취약점

1. 취약점을 신뢰 경계로 분류한다

공통 질문은 다음과 같다.

• 사용자가 전체 대상을 직접 지정해야 하는가?
• 고정 목록이나 서버 측 Mapping으로 선택지를 줄일 수 있는가?
• Parser의 불필요한 기능을 끌 수 있는가?
• 네트워크·File·실행 환경·업무 권한을 최소화했는가?
• 단일 요청뿐 아니라 누적 결과도 검증하는가?

2. SSRF

SSRF(서버-Side Request Forgery)는 애플리케이션이 외부 입력의 영향을 받아 의도하지 않은 대상에 서버 측 Request를 보내는 취약점이다.

사용자 → URL 제출
       → Application Server가 URL 요청
       → 내부 서비스·Loopback·사설망·외부 시스템에 접근

2.1 성립 조건

1. 애플리케이션 서버가 다른 대상에 요청을 보낸다.
2. 사용자가 URL·Host·Port·Path 등 대상에 영향을 줄 수 있다.
3. 대상 제한과 실제 연결 주소 검증이 부족하다.

서버의 네트워크 권한이 넓을수록 내부 자원에 대한 영향이 커질 수 있다. 넓은 권한이 SSRF 성립의 필수 조건은 아니다.

2.2 영향

• 내부 관리 API 접근
• 사설망 Service 탐색
• 서버가 신뢰받는 위치에서 상태 변경 요청 수행
• 내부 정보 또는 응답 내용 노출
• 외부 공격의 중계

2.3 대응

가장 강한 설계는 사용자가 전체 URL을 제출하지 않게 하는 것이다.

외부 Resource ID
      ↓
Server-side Allow-list 또는 Mapping
      ↓
허용된 Scheme·Host·Port만 선택
      ↓
DNS 결과와 실제 연결 대상 확인
      ↓
Redirect 제한
      ↓
Network Egress 정책으로 최종 제한

URL이 꼭 필요하면 정식 Parser로 Scheme·Host·Port를 분리하고, Loopback·사설·Link-local 등 금지 주소를 확인한다. Redirect 후 목적지도 다시 검증한다. Timeout과 응답 크기를 제한하고, 사용자의 쿠키·Authorization Header를 외부 대상에 자동 전달하지 않는다.

SSRF와 CSRF는 실행 주체가 다르다. CSRF는 피해자의 브라우저가 요청하고, SSRF는 애플리케이션 서버가 요청한다.

3. XXE

XXE(XML External Entity)는 XML Parser가 DTD나 외부 Entity를 해석하면서 외부 File 또는 네트워크 자원을 읽는 취약점이다.

3.1 영향

• Local File 노출
• SSRF와 내부 서비스 접근
• Error Message를 통한 정보 노출
• 외부 자원 해석에 따른 정보 노출·자원 소모

내부 엔티티를 반복 확장하는 XML 폭탄도 자원 고갈을 일으키지만, 외부 엔티티를 사용하지 않는 경우까지 모두 XXE라고 부르지는 않는다.

3.2 대응

• XML이 필요하지 않으면 단순한 Data 형식을 사용한다.
• DTD와 외부 Entity 처리를 비활성화한다.
• 외부 DTD·Schema·XInclude 조회를 제한한다.
• 최신 Parser와 안전한 설정을 사용한다.
• XML 처리 프로세스의 File·네트워크 권한을 최소화한다.

Schema Validation을 사용한다는 사실만으로 XXE가 자동으로 사라지지는 않는다. Schema 위치 자체가 외부 요청을 만들 수 있기 때문이다.

4. 안전하지 않은 역직렬화

역직렬화는 저장된 데이터를 실행 환경 Object로 복원하는 과정이다. 외부 데이터가 생성할 객체 유형이나 복원 동작을 선택할 수 있으면 예상하지 않은 Method 호출, 권한 우회, 자원 고갈, 코드 실행으로 이어질 수 있다.

4.1 안전한 방향

외부 JSON·메시지
      ↓
고정 Schema 검증
      ↓
허용된 단순 Data 구조
      ↓
Application DTO로 명시적 Mapping

Native Object 직렬화 형식을 신뢰 경계 밖에서 직접 사용하지 않는 것이 가장 안전하다. 불가피하면 허용 객체 유형과 복원 동작을 제한하고, 크기·깊이·객체 수에 상한을 둔다.

서명·MAC은 데이터 변조 여부를 확인할 수 있지만, 서명된 데이터 안에 위험한 Type이 포함되지 않았다는 사실까지 보장하지 않는다.

5. Data Diddling과 Salami Attack

5.1 Data Diddling

입력·처리·출력 단계의 업무 데이터를 몰래 변경하는 공격이다. 거래 금액, 계좌, 수량, 상태값, 정산 결과가 대상이 될 수 있다.

5.2 Salami Attack

각 거래에서 눈에 띄지 않을 정도의 작은 값을 반복적으로 빼내거나 변조해 누적 이익을 얻는 방식이다.

5.3 대응

• 서버 측 업무 불변식 검증
• 중요한 변경의 역할 분리와 이중 승인
• 원장·외부 자료와의 대사
• 거래별 이상뿐 아니라 누적 패턴 탐지
• 계산 결과의 독립적 재계산
• 변경 전후와 수행 주체를 남기는 감사 로그

단순 입력 형식 검증만으로는 “허용된 숫자지만 업무적으로 부정한 값”을 막을 수 없다.

6. Open Redirect와 Clickjacking

6.1 Open Redirect

사용자가 지정한 URL로 검증 없이 이동시키는 취약점이다. 신뢰 사이트 주소를 거쳐 Phishing 사이트로 이동시키거나 인증 흐름의 Redirect를 악용할 수 있다.

대응은 고정된 경로 ID나 허용 Origin 목록을 사용하고, 외부 URL을 직접 받지 않는 것이다.

6.2 Clickjacking

공격자가 대상 화면을 투명하거나 위장된 Frame에 겹쳐 사용자가 의도하지 않은 버튼을 누르게 하는 공격이다.

대표 대응은 Frame 삽입을 제한하는 frame-ancestors 정책 또는 동등한 응답 Header와, 중요 작업의 재확인이다.

7. Mobile 코드의 역사적 보호 개념

Mobile 코드는 다른 시스템에서 내려받아 클라이언트 또는 실행 환경에서 실행되는 코드다. Java Applet과 ActiveX는 현재 일반적인 웹 배포 방식이 아니지만 보호 원리를 이해하는 시험 개념으로 볼 수 있다.