개발자가 입력값을 안전하게 처리하지 않았다면 공격자는 입력창을 통해 프로그램의 동작을 바꾸려 할 수 있다.
입력값 검증은 ‘사용자가 잘못 입력할 수 있다’는 정도의 문제가 아니다. 프로그램이 예상하지 못한 문장을 명령이나 쿼리의 일부로 해석하면 공격으로 이어질 수 있다.
SQL을 만들 때 입력값을 문자열로 직접 이어 붙이기보다 파라미터 바인딩을 사용하고, 허용할 값의 형식과 길이를 확인하는 이유도 여기에 있다. 입력은 언제나 신뢰하지 않는다는 원칙이 기본이다.
입력 검증은 클라이언트 화면에서 한 번 검사했다고 끝나지 않는다. 공격자는 화면을 거치지 않고 직접 요청을 보낼 수도 있으므로, 실제로 데이터를 처리하는 서버에서도 같은 규칙을 다시 확인해야 한다.
SQL 문을 입력값으로 조작한다
사용자가 입력한 문자열을 그대로 SQL 문에 이어 붙이면 위험할 수 있다.
입력값을 SQL 문자열에 직접 연결하기보다 파라미터 바인딩과 안전한 쿼리 방식을 사용하는 것이 중요하다.
SQL Injection의 방어 핵심은 명령과 데이터를 분리하는 것이다. 파라미터 바인딩을 사용하면 사용자가 입력한 값은 SQL 문법이 아니라 하나의 데이터 값으로 전달되어 악의적인 구문이 명령으로 해석될 가능성을 크게 줄일 수 있다.
SQL Injection은 데이터베이스만의 문제가 아니라 입력을 명령으로 해석하게 만든 경계 설계의 문제다. 사용자 입력은 항상 ‘데이터’로만 전달되게 만들고, 명령 구조는 프로그램이 고정해서 관리해야 한다.
파라미터 바인딩이 중요한 이유도 사용자가 입력한 값이 SQL 문장의 구조를 바꾸지 못하게 하기 위해서다. 프로그램이 쿼리의 형태를 정하고 입력값은 그 안의 값으로만 전달되면, 명령과 데이터의 경계를 더 분명하게 유지할 수 있다.
웹페이지에 공격용 스크립트를 넣는다
게시글이나 이름 같은 입력값이 아무 처리 없이 웹 화면에 출력되면 브라우저가 입력값 안의 스크립트를 실행할 수 있다.
출력 위치에 맞는 인코딩과 입력·출력 검증이 중요하다.
로그인한 사용자의 권한을 악용한다
사용자가 로그인된 상태에서 공격자가 만든 링크나 페이지를 열었다.
사용자의 의도와 다르게 예약 취소 같은 요청이 서버로 전달될 수도 있다.
입력은 믿지 않는다
전화번호 칸에는 전화번호 형식이 들어와야 하고, 예약 인원에는 허용된 범위의 숫자가 들어와야 한다.
길이, 형식, 범위, 허용된 문자 등을 검사하면 예상하지 못한 입력이 시스템 안으로 들어오는 것을 줄일 수 있다.
입력 검증은 허용 목록을 먼저 정하는 방식이 안전하다. ‘나쁜 문자를 모두 막는다’보다 필요한 문자·길이·범위를 명확히 정하고 그 조건을 만족하는 입력만 받는 편이 예측하기 쉽다.
검증 규칙은 가능한 한 서버의 실제 업무 규칙과 연결되어야 한다. 숫자 범위, 날짜 관계, 권한 여부처럼 단순 형식 검사를 넘어서 ‘이 값이 현재 상태에서 허용되는가’까지 확인해야 한다.
검증 위치도 중요하다. 화면에서 한 번 확인했더라도 실제 업무 처리를 담당하는 쪽에서 다시 조건을 검사해야 한다. 시스템 내부로 들어오는 값이 기대한 규칙을 만족하는지 마지막 경계에서 확인해야 이후 처리와 저장도 안정적으로 이어진다.