입력 검증·출력 인코딩·인젝션 방어

핵심 요약

입력 검증은 들어온 값이 허용된 규칙에 맞는지 확인하고, 출력 인코딩은 값이 출력 위치에서 코드나 제어 문법으로 해석되지 않게 표현한다. 매개변수화는 질의·명령의 구조와 데이터를 분리한다. 이 세 가지는 적용 위치와 목적이 다르므로 서로 대체하지 않는다.

인젝션은 비신뢰 데이터가 SQL·운영체제 명령 등의 제어 문법으로 해석되어 원래 처리 구조를 바꾸는 문제다.

1. 비신뢰 입력의 범위

사용자가 화면에 입력한 문자열뿐 아니라 URL·헤더·쿠키·파일·API 응답·메시지·DB에 저장된 과거 사용자 입력도 비신뢰 데이터일 수 있다. ‘DB에서 읽었으므로 안전하다’는 전제가 항상 성립하지 않는다.

브라우저의 입력 검사는 잘못된 값을 빠르게 알려주는 데 도움이 되지만 요청을 직접 조작할 수 있으므로 서버 측 검증을 대체하지 못한다.

2. 구문 검증과 의미 검증

2026-02-31은 날짜처럼 보이는 형태지만 실제 날짜로 유효하지 않다. ‘종료일’이 실제 날짜여도 ‘시작일’보다 앞서면 업무 규칙에 어긋날 수 있다. 형식과 의미를 함께 확인해야 한다.

허용 목록(Allowlist)은 허용할 값과 형식을 정의하고 그 외를 거부한다. 금지 목록(Denylist)은 알려진 위험 요소를 차단하지만 알려지지 않은 우회를 빠짐없이 막기 어렵다. 예를 들어 정렬 방향을 ASC·DESC 두 가지 선택으로 제한하는 것이 임의 문자열에서 몇 가지 위험 문자를 지우는 것보다 명확하다.

단, 사람 이름이나 자유 문장에 필요한 정상 문자를 무조건 삭제하는 방식은 데이터 의미를 훼손할 수 있다. 자료형과 업무 목적에 맞게 규칙을 정한다.

3. 처리 순서와 각 방어의 역할

정의된 방식으로 해석·파싱 → 필요한 정규화 → 구문·의미 검증 → 권한 확인 → 사용 지점에 맞는 안전한 처리로 이해한다.

정규화는 같은 의미의 여러 표현을 일관된 형태로 맞추는 것이다. 검증 후 다시 디코딩하여 다른 값으로 바뀌면 앞선 검증이 무효가 될 수 있다. 실제 사용할 표현을 기준으로 검증해야 한다.

좌우로 이동해 그림을 확인하세요.그림 크게 보기

4. 출력 인코딩

출력 인코딩은 값이 놓이는 문맥에 맞춰 적용한다. HTML 본문에 적합한 처리를 JavaScript 코드 위치에 그대로 사용하면 안전하지 않을 수 있다.

일반 텍스트를 화면에 넣을 때는 innerHTML로 HTML처럼 해석하게 만들기보다 textContent처럼 텍스트로 처리하는 기능이 적절하다. 단, 텍스트 처리 API 하나가 다른 종류의 인젝션까지 막는 것은 아니다.

HTML 인코딩된 문자열을 원본처럼 DB에 저장하면 다른 문맥에서 잘못 재사용하거나 이중 인코딩할 수 있다. 데이터를 사용하는 최종 출력 지점의 문맥을 고려한다. Base64 인코딩은 표현 변환이지 암호화나 인젝션 방어가 아니다.

5. SQL 삽입

SQL Injection은 입력이 SQL 문법으로 해석되어 조회·수정·삭제 등의 원래 의도를 바꾸는 약점이다. 핵심 방어는 고정된 SQL 구조와 외부 값의 분리다.

개념 예는 다음과 같다.

SELECT name FROM members WHERE member_id = ?;

여기서 ?는 지원하는 DB 드라이버의 값 자리표시자 예다. 실제 값은 문자열 연결로 넣지 않고 드라이버의 매개변수 바인딩 기능으로 전달한다. 자리표시자 표기는 DB·드라이버마다 다를 수 있다.

안전한 구조에서는 입력에 SQL 문법처럼 보이는 문자가 있어도 해당 값으로 취급해야 한다. 작은따옴표를 삭제하면 모든 SQL 삽입이 해결된다는 설명은 틀리다.

구조 요소와 권한의 별도 통제

테이블명·열명·정렬 방향은 보통 값 바인딩의 대상이 아니다. 사용자가 임의 SQL 조각을 보내게 하지 말고 서버에서 정한 허용 목록에 대응시킨다. 예를 들어 최근순을 고정된 작성일 내림차순으로 매핑한다.

저장 프로시저·ORM을 사용해도 내부에서 비신뢰 문자열을 동적 SQL에 연결하면 취약할 수 있다. 도구의 이름이 아니라 최종 질의가 어떻게 만들어지는지가 중요하다.

DB 계정의 최소 권한, 민감한 DB 오류의 외부 비노출도 피해를 줄이는 보조 통제다. 이들이 매개변수화를 대신하지는 않는다. 또한 SQL 삽입을 막아도 다른 사용자의 레코드를 조회할 권한까지 자동으로 확인되는 것은 아니다.

6. 운영체제 명령 삽입

운영체제 명령 삽입은 외부 입력을 명령 문자열에 연결하면서 의도하지 않은 명령·처리가 실행되는 약점이다.

가능하면 외부 명령 호출을 제거하고 해당 작업을 수행하는 전용 라이브러리를 사용한다. 명령 실행이 꼭 필요하면 실행 프로그램과 허용 작업을 고정하고, 셸을 거치지 않는 인자 전달 방식을 사용하며, 각 인자의 허용 형식·값을 검증한다.

셸을 사용하지 않아도 프로그램이 특정 인자를 관리 옵션으로 해석할 수 있다. 따라서 셸 미사용과 인자 검증을 함께 고려한다. 이를 인자 삽입 문제와 연결해서 이해한다.

7. 상황과 오답 판별

사용자 입력을 HTML 인코딩한 뒤 SQL에 문자열로 붙이는 방식은 방어 문맥이 잘못되었다. SQL에는 매개변수화가 필요하다. 반대로 SQL에 안전하게 저장한 게시글도 화면에서 원시 HTML로 해석하면 XSS가 발생할 수 있다.

온라인 조회 기능은 ‘입력 ID의 형식 확인’, ‘현재 사용자의 조회 권한 확인’, ‘값 바인딩으로 질의’, ‘화면 문맥에 맞는 출력’을 각각 수행해야 한다. 하나의 필터가 모든 단계를 대신하지 않는다.

입력이 해석되는 위치에 따른 방어

입력 검증은 길이·형식·범위와 업무 의미를 확인하는 활동이다. 구조적으로 날짜 모양에 맞더라도 존재하지 않는 날짜일 수 있으므로 실제 달력 규칙도 확인한다. 문자열 정규화는 표현이 여러 개인 입력을 일관된 형태로 바꾸는 것이다. 예를 들어 서비스가 정규화된 유니코드로 동일성을 판단하도록 정했다면 NFC 같은 지정 규칙을 검증·비교 전에 일관되게 적용한다. 임의의 정규화로 의도된 서로 다른 식별자를 합치지 않도록 정책이 필요하다.

중첩된 JSON 등의 입력은 바이트 수뿐 아니라 중첩 깊이·항목 수·처리 시간도 자원 소모에 영향을 준다. 구조화된 입력이라고 자동으로 안전한 것은 아니다.

인접한 입력 처리 약점

SSRF는 사용자의 브라우저가 아니라 서버의 네트워크 접근 권한을 악용하는 점이 중요하다. 외부 주소처럼 보이는 문자열이라고 내부 자원으로 이어지지 않는다는 보장은 없다. 이러한 항목은 기본 원인과 방어를 구분하는 범위로 학습하며 실제 침투 절차가 아니다.