XSS와 출력 이스케이프

전부 막을 수 없으니 허용 목록 방식의 검증된 라이브러리로 걸러냅니다. 직접 만들지 않습니다.

허용 목록을 쓸 때 놓치기 쉬운 부분입니다.

여기에 CSP 를 함께 걸어 인라인 스크립트 실행을 막으면 한 겹이 더 생깁니다.

흔한 실수: 정규식으로 script 태그만 지우는 것. 대소문자 섞기, 속성 안 실행, SVG 안 스크립트 등으로 뚫립니다.

위험한지 아닌지는 값이 어디에 쓰이는지에 달려 있기 때문입니다. 입력 시점에는 그것을 모릅니다.

같은 값 javascript:alert(1) 이 어디에 놓이는지에 따라 달라집니다.

그래서 원칙은 원본을 저장하고 출력 시점에 그 자리에 맞게 처리하는 것입니다.

입력 검증도 여전히 필요합니다. 길이와 형식을 제한해 공격 표면을 줄이는 역할입니다. 다만 그것만으로는 부족합니다.

흔한 실수: 입력 시점에 이스케이프해 저장하는 것. 그 값이 JSON 이나 로그로 나갈 때 이중 인코딩되어 화면이 깨집니다.

CSP 는 실행 경로를 제한하는 장치이고, 정책에 구멍이 있으면 통과됩니다.

그리고 CSP 는 DOM 조작으로 생기는 XSS 를 다 막지 못합니다. 이미 로드된 우리 스크립트가 사용자 입력을 innerHTML 로 넣으면 정책 안에서 벌어집니다.

흔한 실수: CSP 를 도입했으니 이스케이프를 안 해도 된다고 보는 것. CSP 는 마지막 방어선이고, 출력 이스케이프가 1차 방어입니다. 순서를 바꿀 수 없습니다.

저장형을 먼저 막습니다. 피해 범위와 지속성이 다릅니다.

저장형은 이미 심어진 것을 찾아 지우는 작업이 따라옵니다. 그래서 발견 즉시 유입을 막고, 기존 데이터를 훑어 정리하고, 그 사이 노출된 세션을 무효화할지 판단합니다.

대응 순서
  1. 저장 경로를 막는다 (유입 차단)
  2. 저장된 데이터를 조사하고 정리한다
  3. 출력 이스케이프를 전 경로에 적용한다
  4. 반사형 경로를 정리한다

흔한 실수: 코드만 고치고 끝내는 것. 저장형은 데이터에 남아 있어 코드 수정만으로 사라지지 않습니다.