이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
학교에서 보안 관련 수업을 들으면서 실습 환경에서 침투 테스트를 처음 해보았습니다. 취약한 서버를 만들어두고 SQL 인젝션으로 데이터를 꺼내는 실습이었는데, 처음에는 흥미로웠지만 범위를 벗어나서 다른 팀 서버에 접근하려는 시도가 왜 위험한지 교수님이 강하게 강조하셨습니다. 침투 테스트는 사전에 명확한 범위와 허가가 있어야 한다는 것이 가장 중요하다고 배웠습니다. 실습 후 제 포트폴리오 사이트에 직접 SQL 인젝션 시도를 해보았는데, 취약한 부분이 1군데 있었습니다. 수업에서 배운 것을 바로 제 코드에 적용해보는 것이 인상 깊었습니다.
보안은 공격자 시각으로 봐야 방어도 할 수 있다는 것을 느꼈습니다.
보안 동아리 활동에서 내부 서비스에 취약점 점검을 하는 프로젝트에 참여했어요. 처음엔 팀원 한 명이 범위에 없는 외부 연동 서비스까지 스캔을 했는데, 그쪽에서 비정상 트래픽 알림이 왔어요. 실제 문제는 없었지만 범위 외 시스템에 영향을 줄 수 있다는 걸 직접 경험했어요. 이후 팀에서 테스트 시작 전에 IP 범위, 테스트 방법, 진행 시간대를 문서로 정하고 시작하는 규칙을 만들었어요. 실습이었지만 실제였다면 법적 문제가 생길 수 있다는 것도 인식했어요. 침투 테스트는 기술보다 절차와 커뮤니케이션이 더 중요하다는 걸 배웠어요.
그 과정이 값진 배움이었습니다. 그 과정이 값진 배움이었습니다.
포트폴리오용 웹 서비스를 배포하고 나서 OWASP Top 10 리스트를 보면서 하나씩 체크해봤어요. SQL 인젝션, XSS, CSRF, 인증 취약점 순서로 확인했는데 XSS 취약점이 2군데 있었어요. 텍스트 입력을 innerHTML로 넣는 패턴이었는데, 수정하면서 textContent로 바꿨어요. 리다이렉트 URL 검증이 없어서 오픈 리다이렉트가 가능한 부분도 있었어요. 이 점검은 도구 없이 직접 수작업으로 했는데, 내 코드를 공격자 시각으로 보는 연습이 됐어요. 자기 점검이라 범위가 명확하고 누구한테도 영향이 없었는데, 실제 서비스에서는 범위와 권한 설정이 더 엄격해야 한다는 걸 이해하게 됐어요.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 HL그룹 SW·IT 일반 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.