입력값 검증

입력값 검증(Input Validation)은 외부에서 들어온 값을 응용 프로그램이 쓰기 전에 형식·길이·범위·의미가 업무 요구에 맞는지 서버에서 검사하고, 맞지 않으면 거부하는 보안 기법이다.

개요

사용자 입력, 요청 파라미터, 쿠키, 숨은 필드, 외부 API 응답은 모두 공격자가 바꿀 수 있는 값이다. 이런 값을 그대로 연산·질의·파일 경로·명령에 쓰면 SQL 인젝션, 경로 조작, 크로스사이트 스크립트, 정수 오버플로, 업무 규칙 우회 같은 취약점이 생긴다. CWE-20(부적절한 입력 검증)은 입력이 안전하고 올바르게 처리되는 데 필요한 속성을 검증하지 않거나 잘못 검증하는 약점으로, 많은 취약점의 뿌리가 된다. 행정안전부·KISA의 소프트웨어 개발보안 기준도 구현 단계 보안약점의 첫 유형을 '입력데이터 검증 및 표현'으로 묶는다 → 시큐어 코딩, 소프트웨어 개발 보안

무엇을 검사하는가

OWASP는 구문(기대하는 타입과 형식)과 의미(그 값이 해당 작업에서 말이 되는지)를 함께 검증하라고 권한다. 예약이라면 날짜 형식이 맞는 것에 더해 종료일이 시작일보다 뒤여야 한다.

입력 종류	검사 규칙
정해진 선택지	허용 집합에 정확히 속하는지(드롭다운 값도 다시 검사)
숫자·날짜	타입, 형식, 최솟값과 최댓값
문자열	길이 제한, 필요한 문자 구성
객체·배열	허용 필드, 필수 필드, 항목 수 상한, 내부 항목 각각

• 허용 목록(allowlist)으로 받을 것을 정의하고 나머지를 거부한다. 나쁜 문자열을 모두 찾아내려는 차단 목록은 언제나 빠진 것이 생긴다.
• 서버 측에서 검사한다. 브라우저 스크립트의 검사는 사용 편의 기능일 뿐 프록시 도구로 쉽게 우회된다.
• 보안 결정에 쓰는 값은 클라이언트에서 받지 않는다. 가격, 권한, 할인율처럼 결과를 좌우하는 값을 요청 파라미터로 받으면 공격자가 바꿔 보낸다. CWE-807은 외부 사용자가 바꿀 수 있는 입력에 의존하는 보호 장치를 별도 약점으로 둔다.

범위 검사가 빠진 예

String price = request.getParameter("price");
int p = Integer.parseInt(price);   // 숫자인지만 확인된다
total = total + p;                 // 음수·과대값 그대로 합산

• 숫자가 아닌 값이면 NumberFormatException 이 나고, 처리하지 않으면 오류 정보가 노출된다.
• 숫자로 바꿨다고 받아들일 수 있는 값이 되는 것은 아니다. OWASP도 문자열을 정수로 바꾸는 것은 타입을 정할 뿐 허용 가능한 수량을 정하지 않는다고 적는다. 가격을 -10000 으로 보내면 합계가 줄고, int 범위를 넘는 값을 더하면 정수 오버플로로 엉뚱한 값이 된다.
• 대응은 0 이상·상한 이하인지 확인하는 범위 검사와, 애초에 가격을 클라이언트가 아니라 서버의 상품 정보에서 읽는 것이다.

다른 대책과 구별하기

대책	막는 것	입력값 검증과의 관계
매개변수화 질의 → 자바 PreparedStatement	SQL 인젝션	1차 대책이다. 입력값 검증은 보조로 함께 쓴다
출력 인코딩	XSS	값이 형식에 맞아도 출력 맥락에 맞게 인코딩해야 한다
인가 검사 → API 보안	남의 객체 접근	형식이 맞는 계정 번호라도 그 계정에 접근해도 되는지는 따로 검사한다
업로드 통제 → 파일 업로드 취약점	웹셸 업로드	파일 이름 검사는 파일 내용 검사가 아니다

• 입력값 검증만으로 주입 공격을 다 막을 수는 없다. 반대로 매개변수화 질의를 써도 범위 검사가 빠진 업무 로직 결함(음수 금액 등)은 그대로 남는다.

같이 보기

• 시큐어 코딩
• 소프트웨어 개발 보안
• SQL 인젝션
• 디렉토리 트래버설
• 파일 업로드 취약점