XSS 패치 작업에서 놓치기 쉬운 것들

최근 알고 지내던 업체의 요청으로 XSS 취약점 패치 작업을 진행했습니다. 

일회성 핫픽스가 아니라 근본적으로 코드베이스를 분석하고 문제를 막는 방향으로 작업을 진행했습니다.

 

서비스를 개발하다 보면 XSS 취약점 패치 작업을 마주하게 됩니다. 

처음에는 단순한 시큐어 코딩 작업이라고 생각하기 쉽습니다. 

취약한 입력값을 이스케이프 처리하고, 위험한 태그를 필터링하면 끝나는 작업처럼 보입니다.

 

그런데 공격자의 관점에서 바라보면 개발자 입장에서 쉽게 놓칠 수 있는 부분들이 추가로 눈에 들어옵니다.

XSS는 크게 Stored XSS(저장형), Reflected XSS(반사형), DOM-based XSS(DOM 기반) 세 가지로 나뉩니다. 각각 발생하는 시점과 경로가 다르기 때문에 패치 방식도 달라집니다.

 

Stored XSS(저장형)는 DB에 저장된 데이터가 출력될 때 발생하고, 

Reflected XSS(반사형)는 URL 파라미터 등 요청값이 그대로 응답에 반영될 때 발생합니다. 

DOM-based XSS(DOM 기반)는 서버를 거치지 않고 

클라이언트 사이드에서 발생하기 때문에 서버 사이드 필터링만으로는 대응이 되지 않습니다. 

이 세 가지를 구분하지 않고 일괄적으로 처리하려 할 때 첫 번째 누락이 발생합니다.

 

두 번째로 놓치기 쉬운 부분은 입력값 처리 시점입니다. 

입력 시점에 이스케이프할 것인지, 출력 시점에 이스케이프할 것인지에 따라 

데이터의 저장 형태와 재사용 방식이 달라집니다. 

입력 시점에 처리하면 원본 데이터가 변형되어 저장되고, 

출력 시점에 처리하면 원본은 유지되지만 출력되는 모든 경로를 빠짐없이 처리해야 합니다. 

어느 방식이 맞다기보다 서비스의 구조와 데이터 활용 방식에 따라 판단해야 하는 문제입니다.

 

세 번째는 패치 범위입니다. 

전체 입출력을 일괄 처리하면 기존에 정상적으로 동작하던 기능에 영향을 줄 수 있고, 

부분적으로 처리하면 누락되는 지점이 생길 수 있습니다. 

특히 레거시 코드가 많은 프로젝트일수록 영향 범위를 파악하는 것 자체가 큰 작업입니다. 

공격자는 개발자가 놓친 단 하나의 지점을 찾아내면 되기 때문에 패치의 완결성이 중요합니다.

 

마지막으로 패치 이후 검증입니다. 

코드 리뷰만으로는 모든 취약점을 확인하기 어렵습니다. 

실제 공격 시나리오를 기반으로 한 테스트와 함께 

OWASP ZAP, Burp Suite 같은 도구를 활용한 자동화 스캔을 병행하는 것이 효과적이었습니다.

 

XSS 패치는 한 번으로 끝나는 작업이 아닙니다. 

신규 기능이 추가될 때마다, 외부 라이브러리가 업데이트될 때마다 

새로운 취약점이 생길 수 있습니다. 

 

따라서 XSS 대응은 시큐어 코딩 문화를 개발 프로세스에 녹여내어 꾸준히 관리해야 합니다.