웹 보안 주니어 트러블슈팅 면접
새 면접Q. 회사 게시판에서 사용자가 작성한 게시글을 조회할 때, 특정 게시글을 열면 alert 창이 뜨고 다른 사용자의 쿠키 정보가 외부로 전송되는 장애가 발생했습니다. 이 문제의 원인과 해결 방법을 설명해주세요.
사용자 입력값이 HTML로 렌더링될 때 발생할 수 있는 보안 취약점을 생각해보세요.
이것은 XSS(Cross-Site Scripting) 공격입니다. 공격자가 게시글 작성 시 스크립트 태그를 포함한 악성 코드를 삽입했고, 이것이 그대로 실행되어 발생한 문제입니다. 해결을 위해서는 사용자 입력값을 출력하기 전에 HTML 엔티티 인코딩을 적용해야 합니다. 예를 들어 '<'는 '<'로, '>'는 '>'로 변환하여 스크립트가 실행되지 않도록 합니다. 추가로 CSP(Content Security Policy) 헤더를 설정하여 인라인 스크립트 실행을 차단하고, HttpOnly 플래그를 쿠키에 설정하여 JavaScript로 쿠키 접근을 막아야 합니다.
- • XSS 공격으로 악성 스크립트가 실행됨
- • HTML 엔티티 인코딩으로 입력값 처리
- • CSP 헤더와 HttpOnly 쿠키 설정으로 방어
사용자가 직접 콘텐츠를 작성할 수 있는 게시판, 댓글, 프로필 등의 기능에서 XSS 방어는 필수입니다.
Stored XSS와 Reflected XSS의 차이점은 무엇이며, 이 사례는 어떤 유형에 해당하나요?
Q. 로그인 기능에서 특정 사용자가 비밀번호 입력란에 ' OR '1'='1 을 입력했더니 비밀번호 없이 로그인이 되는 심각한 보안 장애가 발생했습니다. 어떤 문제이며, 어떻게 해결해야 하나요?
사용자 입력이 SQL 쿼리에 직접 결합되어 실행될 때 발생하는 취약점입니다.
이것은 SQL Injection 공격입니다. 사용자 입력값이 SQL 쿼리 문자열에 직접 결합되어 쿼리 구조 자체가 변조된 것입니다. 공격자가 입력한 문자열로 인해 WHERE 조건이 항상 참이 되어 인증을 우회했습니다. 해결 방법은 Prepared Statement(파라미터화된 쿼리)를 사용하는 것입니다. 이 방식은 SQL 쿼리와 데이터를 분리하여 입력값이 쿼리 구조를 변경할 수 없게 합니다. 추가로 ORM을 사용하거나, 입력값 검증을 통해 특수문자를 필터링하는 방어 계층을 추가할 수 있습니다.
- • SQL Injection으로 쿼리 구조가 변조됨
- • Prepared Statement로 쿼리와 데이터 분리
- • 입력값 검증과 ORM 사용으로 추가 방어
로그인, 검색, 게시글 조회 등 데이터베이스 쿼리를 실행하는 모든 기능에서 SQL Injection 방어가 필요합니다.
ORM을 사용하면 SQL Injection이 완전히 방지되나요? 주의해야 할 점은 무엇인가요?
Q. 사용자가 로그인한 상태에서 이메일에 포함된 링크를 클릭했더니, 본인도 모르게 비밀번호가 변경되는 장애가 발생했습니다. 서버 로그를 확인하니 정상적인 세션 쿠키로 요청이 들어왔습니다. 원인과 해결 방법을 설명해주세요.
인증된 사용자의 권한을 악용하여 의도하지 않은 요청을 실행하게 만드는 공격입니다.
이것은 CSRF(Cross-Site Request Forgery) 공격입니다. 공격자가 악성 링크를 만들어 사용자가 클릭하면 자동으로 비밀번호 변경 요청이 전송되고, 브라우저가 자동으로 쿠키를 포함시켜 인증이 통과된 것입니다. 해결을 위해 CSRF 토큰을 구현해야 합니다. 서버에서 폼 렌더링 시 랜덤한 토큰을 생성하여 세션에 저장하고 HTML에 포함시킨 후, 요청 시 이 토큰을 검증합니다. SameSite 쿠키 속성을 Strict 또는 Lax로 설정하여 크로스 사이트 요청 시 쿠키 전송을 차단할 수 있습니다. 중요한 작업에는 재인증을 요구하는 것도 효과적입니다.
- • CSRF 공격으로 인증된 사용자 권한 악용
- • CSRF 토큰으로 요청 출처 검증
- • SameSite 쿠키 속성 설정으로 방어
비밀번호 변경, 결제, 회원 탈퇴 등 중요한 상태 변경 작업에서 CSRF 방어가 필수입니다.
GET 요청과 POST 요청 중 어느 것이 CSRF 공격에 더 취약하며, 그 이유는 무엇인가요?
Q. 사용자가 로그아웃을 했는데도 브라우저 히스토리의 뒤로가기를 누르면 로그인 상태로 이전 페이지가 보이는 문제가 발생했습니다. 이 문제의 원인과 해결 방법을 설명해주세요.
브라우저 캐시와 서버 측 세션 검증 사이의 불일치 문제를 고려해보세요.
이것은 브라우저 캐시에 저장된 페이지가 표시되는 문제입니다. 로그아웃 시 서버의 세션은 무효화되었지만, 브라우저에 캐시된 HTML이 그대로 표시되어 로그인 상태처럼 보이는 것입니다. 해결을 위해 민감한 페이지의 응답 헤더에 Cache-Control: no-store, no-cache, must-revalidate와 Pragma: no-cache를 설정해야 합니다. 또한 모든 보호된 페이지에서 서버 측 세션 유효성을 검증하고, 세션이 없으면 로그인 페이지로 리다이렉트해야 합니다. 로그아웃 시 세션 쿠키를 명시적으로 삭제하고, 프론트엔드에서도 localStorage나 sessionStorage를 정리해야 합니다.
- • 브라우저 캐시로 인한 페이지 표시 문제
- • Cache-Control 헤더로 캐시 방지
- • 모든 요청에서 서버 측 세션 검증 필요
마이페이지, 관리자 페이지 등 인증이 필요한 페이지에서 적절한 캐시 제어가 필요합니다.
세션 고정 공격(Session Fixation)은 무엇이며, 로그인 시 어떻게 방어해야 하나요?
Q. 프론트엔드 개발 서버(localhost:3000)에서 백엔드 API 서버(api.company.com)로 AJAX 요청을 보냈는데 브라우저 콘솔에 'CORS policy' 에러가 발생하여 요청이 차단되었습니다. 원인과 해결 방법을 설명해주세요.
브라우저의 동일 출처 정책과 크로스 도메인 요청 처리 방식을 고려하세요.
이것은 CORS(Cross-Origin Resource Sharing) 정책 위반입니다. 브라우저는 보안상 다른 출처(프로토콜, 도메인, 포트 중 하나라도 다름)로의 AJAX 요청을 기본적으로 차단합니다. 해결을 위해 백엔드 서버에서 응답 헤더에 Access-Control-Allow-Origin을 설정해야 합니다. 개발 환경에서는 특정 도메인(http://localhost:3000)을 허용하고, 운영 환경에서는 실제 프론트엔드 도메인을 지정합니다. 인증 정보를 포함하는 요청이라면 Access-Control-Allow-Credentials: true도 필요하며, 이 경우 와일드카드(*)는 사용할 수 없습니다. Preflight 요청에 대응하기 위해 OPTIONS 메서드도 처리해야 합니다.
- • CORS 정책으로 크로스 도메인 요청 차단
- • Access-Control-Allow-Origin 헤더 설정 필요
- • 인증 정보 포함 시 Credentials 설정과 명시적 도메인 지정
마이크로서비스 아키텍처나 프론트엔드와 백엔드 서버가 분리된 환경에서 CORS 설정은 필수입니다.
Simple Request와 Preflight Request의 차이는 무엇이며, 어떤 경우에 Preflight가 발생하나요?
Q. 이미지 업로드 기능에서 사용자가 .jpg 확장자로 위장한 PHP 파일을 업로드한 후, 해당 파일에 직접 접근하여 서버에서 악성 코드가 실행되는 장애가 발생했습니다. 어떻게 방어해야 하나요?
파일 확장자 검증만으로는 부족하며, 다층 방어 전략이 필요합니다.
파일 업로드 보안은 다층 방어가 필요합니다. 첫째, 확장자뿐 아니라 파일의 MIME 타입과 실제 파일 시그니처(매직 넘버)를 검증해야 합니다. 둘째, 업로드된 파일은 웹 루트 외부의 별도 디렉토리에 저장하고, 파일명을 UUID 등으로 무작위화해야 합니다. 셋째, 업로드 디렉토리에 실행 권한을 제거하고 .htaccess나 웹 서버 설정으로 스크립트 실행을 차단합니다. 넷째, 파일 접근 시 직접 경로가 아닌 다운로드 API를 통해 제공하고, Content-Disposition 헤더를 attachment로 설정하여 브라우저에서 실행되지 않도록 합니다. 파일 크기 제한과 업로드 빈도 제한도 적용해야 합니다.
- • 파일 시그니처와 MIME 타입 검증
- • 웹 루트 외부 저장 및 실행 권한 제거
- • 다운로드 API를 통한 간접 접근
프로필 이미지, 첨부파일, 문서 업로드 등 파일 업로드 기능이 있는 모든 서비스에서 필수적인 보안 조치입니다.
이미지 파일 내부에 악성 코드를 삽입하는 공격은 어떻게 방어할 수 있나요?
Q. JWT 기반 인증을 사용하는 서비스에서 사용자가 비밀번호를 변경했는데도 기존에 발급된 토큰으로 계속 API 접근이 가능한 문제가 발생했습니다. 또한 토큰이 탈취되어 악용되는 사례도 보고되었습니다. 이러한 문제들을 어떻게 해결해야 하나요?
JWT의 무상태성 특징과 토큰 무효화 전략, 그리고 토큰 보안 저장 방법을 함께 고려해야 합니다.
JWT는 무상태(stateless)이므로 서버에서 개별 토큰을 무효화하기 어렵습니다. 해결을 위해 Refresh Token과 Access Token을 분리하고, Access Token의 만료 시간을 짧게(15분 이내) 설정합니다. 비밀번호 변경 시 서버에 토큰 버전이나 발급 시점을 기록하고, 검증 시 이를 확인하여 이전 토큰을 거부합니다. Redis 같은 인메모리 DB에 블랙리스트를 구현하거나, 중요 작업 시 화이트리스트 방식으로 유효한 토큰만 관리할 수 있습니다. 토큰 탈취 방지를 위해 Access Token은 메모리에만 저장하고, Refresh Token은 HttpOnly, Secure, SameSite 속성을 가진 쿠키에 저장합니다. HTTPS를 필수로 사용하고, 토큰에 민감한 정보를 포함하지 않아야 합니다.
- • Access Token 짧은 만료시간과 Refresh Token 분리
- • 토큰 버전 관리나 블랙리스트로 무효화 구현
- • HttpOnly 쿠키와 메모리 저장으로 탈취 방지
모바일 앱이나 SPA에서 JWT를 사용할 때 토큰 관리와 보안은 매우 중요한 설계 요소입니다.
JWT 대신 세션 기반 인증을 사용하는 것과 비교했을 때, 각각의 장단점은 무엇인가요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!