개발 직무에서 기본적인 보안 개념을 이해하고 있는지를 확인합니다. 용어 암기보다 인젝션이 어떻게 작동하고 왜 위험한지를 설명할 수 있는지를 평가합니다.
이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인젝션 공격은 외부 입력값이 의도치 않게 명령어나 쿼리의 일부로 실행되도록 유도하는 공격 방식입니다. 가장 대표적인 SQL 인젝션은 로그인 폼에 ' OR '1'='1 같은 문자열을 입력해서 WHERE 조건을 무력화시켜 인증을 우회하는 방식입니다. OS 커맨드 인젝션은 입력값이 셸 명령어로 전달되는 경로를 이용하고, LDAP·XML 인젝션도 같은 원리입니다. 방어 방법은 Prepared Statement 또는 Parameterized Query를 사용해 입력값과 쿼리 구조를 분리하는 것이 핵심입니다. 웹 개발 실습에서 직접 SQL 인젝션 취약 코드를 작성해보고, ORM 레이어가 자동으로 파라미터를 이스케이프 처리하는 방식을 확인한 적이 있습니다. 또한 입력값 화이트리스트 검증과 에러 메시지 노출 최소화도 보완 수단으로 함께 적용하는 것이 좋다는 것을 배웠습니다.
웹 보안 수업에서 직접 취약한 환경에 SQL 인젝션 공격을 시도해보는 실습을 했는데, 공격이 성공했을 때의 흐름이 생각보다 단순해서 처음에는 당황스러웠습니다. ' OR '1'='1을 입력란에 넣었더니 인증 로직 전체가 우회되는 것을 직접 확인한 순간, 입력값 검증이 단순한 형식 체크가 아니라는 것을 실감했습니다. 공격을 직접 해보니 방어 코드가 어느 지점에서 끊어야 하는지가 더 명확하게 보였습니다.
Prepared Statement가 단순한 권장 방법이 아니라 입력값이 쿼리 구조에 닿지 않게 분리하는 구조 자체라는 것을 그때 이해했습니다. 이후 팀 프로젝트에서 입력 폼을 설계할 때 항상 이 값이 쿼리에 들어가는 경로를 먼저 따지는 습관이 생겼습니다. 공격 방식을 알아야 방어 구조가 왜 그렇게 생겼는지 설명할 수 있다고 생각합니다.
처음에 인젝션 공격을 공부할 때 SQL 인젝션만 알면 된다고 생각했는데, OS 커맨드 인젝션이나 LDAP 인젝션도 같은 원리임을 알게 되면서 개념이 더 넓게 보이기 시작했습니다. 공통점은 외부에서 들어온 값이 시스템이 실행하는 명령의 일부가 되는 구조인데, 이 관점에서 보면 방어 원리도 일관됩니다. 핵심은 입력값과 실행 구조를 분리하는 것입니다. 실습에서 셸 명령어를 실행하는 PHP 스크립트에 세미콜론 뒤에 별도 명령을 붙이는 방식으로 OS 커맨드 인젝션을 시도해봤는데, escapeshellarg() 하나로 공격이 막히는 것을 보고 방어 함수 한 줄이 어떤 구조적 역할을 하는지 비로소 이해했습니다. 이해도를 스스로 점검할 때는 이 입력값이 어느 레이어에서 실행 명령과 만나는지를 손으로 추적해보는 것이 가장 와닿는 방식이었습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 KT 보안 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.