Django 미드레벨 보안 면접
새 면접Q. Django에서 JWT 기반 인증을 구현할 때, Access Token과 Refresh Token을 어떻게 관리해야 하며, 각각의 유효기간은 어떤 기준으로 설정하시겠습니까? 또한 Refresh Token 탈취 시나리오에 대비한 보안 방안을 설명해주세요.
토큰의 저장 위치, 유효기간 차이의 목적, 그리고 Refresh Token Rotation 개념을 생각해보세요.
Access Token은 짧은 유효기간(15분~1시간)으로 설정하여 탈취 시 피해를 최소화하고, httpOnly 쿠키나 메모리에 저장합니다. Refresh Token은 긴 유효기간(7~30일)으로 설정하되 반드시 httpOnly, Secure 쿠키로 저장하며, 데이터베이스나 Redis에 화이트리스트를 관리합니다. Refresh Token Rotation을 구현하여 토큰 갱신 시마다 새로운 Refresh Token을 발급하고 기존 토큰을 무효화합니다. IP 주소나 User-Agent 변경 감지를 통해 이상 접근을 탐지하고, 의심스러운 경우 모든 토큰을 무효화하고 재인증을 요구합니다. Django에서는 djangorestframework-simplejwt 라이브러리를 사용하거나 커스텀 미들웨어로 구현할 수 있습니다.
- • Access Token은 짧은 유효기간, Refresh Token은 긴 유효기간 설정
- • Refresh Token Rotation으로 재사용 공격 방지
- • httpOnly, Secure 쿠키 사용 및 서버 측 화이트리스트 관리
- • IP/User-Agent 변경 감지 및 이상 접근 탐지
사용자가 로그인 상태를 유지하면서도 보안을 강화해야 하는 모든 Django REST API 서비스에서 필수적으로 고려해야 하는 인증 설계입니다.
만약 모바일 앱에서 JWT를 사용한다면 토큰 저장 전략이 어떻게 달라져야 할까요?
Q. Django 템플릿에서 사용자 입력을 출력할 때 autoescape가 기본적으로 활성화되어 있지만, XSS 공격이 여전히 발생할 수 있는 시나리오를 3가지 설명하고 각각의 방어 방법을 제시해주세요.
safe 필터, JSON 데이터 처리, 그리고 JavaScript 컨텍스트에서의 렌더링을 고려해보세요.
첫째, 개발자가 명시적으로 safe 필터나 mark_safe()를 사용하면 autoescape가 우회되므로, 반드시 필요한 경우에만 사용하고 사용 전 입력값을 검증해야 합니다. 둘째, JSON 데이터를 템플릿에서 직접 렌더링할 때 json.dumps()만 사용하면 스크립트 태그가 삽입될 수 있으므로, json_script 템플릿 태그를 사용하거나 DjangoJSONEncoder를 활용해야 합니다. 셋째, JavaScript 코드 내부에서 변수로 사용자 입력을 삽입하는 경우 HTML escape만으로는 부족하므로, escapejs 필터를 추가로 적용하거나 데이터를 DOM API로 안전하게 전달해야 합니다. 넷째, 사용자 입력이 HTML 속성값(특히 href, onclick 등)으로 사용될 때는 URL 검증과 화이트리스트 기반 프로토콜 체크가 필요합니다.
- • safe 필터와 mark_safe() 사용 시 입력값 검증 필수
- • JSON 데이터는 json_script 태그 사용
- • JavaScript 컨텍스트에서는 escapejs 필터 추가 적용
- • HTML 속성값에서는 URL 검증 및 프로토콜 화이트리스트 체크
사용자 생성 콘텐츠(게시판, 댓글, 프로필)를 표시하는 모든 웹 애플리케이션에서 XSS 방어는 필수이며, autoescape만으로는 불충분한 상황을 이해해야 합니다.
Content Security Policy(CSP)를 Django에서 어떻게 설정하고, XSS 방어에 어떻게 활용할 수 있을까요?
Q. Django에서 세션 하이재킹 공격을 방어하기 위한 전략을 설명하고, SESSION_COOKIE_SECURE, SESSION_COOKIE_HTTPONLY, SESSION_COOKIE_SAMESITE 설정의 역할과 한계점을 각각 설명해주세요.
각 설정이 방어하는 공격 벡터가 다르며, 네트워크 레벨과 브라우저 레벨에서의 보호 메커니즘을 구분해보세요.
SESSION_COOKIE_SECURE=True는 HTTPS 연결에서만 쿠키를 전송하여 중간자 공격(MITM)을 방어하지만, 사용자가 HTTP로 접속하면 쿠키가 전송되지 않아 기능이 작동하지 않습니다. SESSION_COOKIE_HTTPONLY=True는 JavaScript에서 쿠키 접근을 차단하여 XSS 공격으로 인한 세션 탈취를 방어하지만, 네트워크 레벨 공격이나 CSRF는 막지 못합니다. SESSION_COOKIE_SAMESITE='Lax' 또는 'Strict'는 크로스 사이트 요청 시 쿠키 전송을 제한하여 CSRF 공격을 방어하지만, 같은 사이트 내의 XSS 공격은 막지 못하며 Lax 모드에서는 GET 요청에 쿠키가 전송됩니다. 추가적으로 세션 재생성(login 시 session.cycle_key() 호출), 세션 타임아웃 설정, IP 주소 및 User-Agent 검증을 조합하여 다층 방어를 구현해야 합니다.
- • SESSION_COOKIE_SECURE는 HTTPS 전송 강제로 MITM 방어
- • SESSION_COOKIE_HTTPONLY는 JavaScript 접근 차단으로 XSS 세션 탈취 방어
- • SESSION_COOKIE_SAMESITE는 크로스 사이트 쿠키 전송 제한으로 CSRF 방어
- • 각 설정의 한계를 이해하고 세션 재생성, 타임아웃 등 추가 방어 계층 필요
금융, 의료, 전자상거래 등 민감한 정보를 다루는 서비스에서 세션 보안은 필수이며, 각 설정의 역할과 한계를 정확히 이해해야 적절한 보안 정책을 수립할 수 있습니다.
Django에서 동일 사용자의 중복 로그인을 감지하고 이전 세션을 무효화하는 방법을 구현한다면 어떻게 하시겠습니까?
Q. Django에서 사용자 비밀번호를 저장할 때 make_password()와 check_password()가 내부적으로 어떤 해싱 알고리즘을 사용하며, PASSWORD_HASHERS 설정에서 PBKDF2, Argon2, Bcrypt의 차이점과 선택 기준을 설명해주세요.
각 알고리즘의 계산 복잡도, 메모리 사용량, 그리고 GPU 공격 저항성을 비교해보세요.
Django는 기본적으로 PBKDF2 알고리즘을 사용하며, PASSWORD_HASHERS 설정의 첫 번째 항목이 새 비밀번호 저장에 사용됩니다. PBKDF2는 반복 횟수(iterations)를 조정하여 계산 비용을 높이지만 메모리 사용량이 적어 GPU 병렬 공격에 취약할 수 있습니다. Argon2는 2015년 Password Hashing Competition 우승 알고리즘으로 메모리 사용량과 병렬성을 모두 조정할 수 있어 GPU/ASIC 공격에 강력하며, 현재 가장 권장되는 방식입니다. Bcrypt는 적응형 해싱으로 시간이 지나도 비용을 조정할 수 있지만 최대 72바이트 입력 제한이 있습니다. 보안이 중요한 서비스라면 Argon2를 첫 번째로 설정하고, 기존 PBKDF2 해시도 하위 호환성을 위해 유지하여 로그인 시 자동으로 Argon2로 마이그레이션되도록 구성하는 것이 좋습니다.
- • PBKDF2는 Django 기본값이지만 GPU 공격에 상대적으로 취약
- • Argon2는 메모리 하드 함수로 GPU/ASIC 공격 저항성이 가장 강력
- • PASSWORD_HASHERS 순서대로 우선순위가 결정되며 자동 마이그레이션 지원
- • 보안 요구사항에 따라 Argon2를 첫 번째로 설정하는 것이 권장됨
사용자 인증 시스템을 구축할 때 비밀번호 저장 방식은 보안의 기본이며, 적절한 해싱 알고리즘 선택은 데이터 유출 시 피해를 최소화합니다.
비밀번호 해싱 알고리즘의 iterations나 memory_cost 파라미터를 어떤 기준으로 설정해야 할까요?
Q. Django ORM을 사용하더라도 SQL 인젝션이 발생할 수 있는 상황을 3가지 예시로 설명하고, raw() 쿼리와 extra() 메서드 사용 시 안전하게 파라미터를 처리하는 방법을 설명해주세요.
문자열 포맷팅으로 쿼리를 구성하는 경우와 ORM의 파라미터 바인딩 메커니즘을 비교해보세요.
첫째, raw() 쿼리에서 Python 문자열 포맷팅(f-string, %)으로 사용자 입력을 직접 삽입하면 SQL 인젝션에 취약하므로, 반드시 파라미터 바인딩(%s 플레이스홀더와 params 인자)을 사용해야 합니다. 둘째, extra() 메서드의 where나 tables 인자에 사용자 입력을 직접 넣으면 위험하므로, params 인자를 활용한 바인딩이 필요합니다. 셋째, RawSQL 표현식을 사용할 때도 동일하게 params 리스트로 값을 전달해야 합니다. 넷째, 테이블명이나 컬럼명을 동적으로 지정해야 하는 경우 사용자 입력을 직접 사용하지 말고 화이트리스트 검증을 수행해야 합니다. ORM의 파라미터 바인딩은 데이터베이스 드라이버 레벨에서 이스케이프 처리되므로, 절대 문자열 연결로 쿼리를 구성해서는 안 됩니다.
- • raw() 쿼리에서 문자열 포맷팅 대신 params 인자로 파라미터 바인딩
- • extra() 메서드와 RawSQL 표현식에서도 params 사용 필수
- • 테이블명/컬럼명 동적 지정 시 화이트리스트 검증
- • ORM 사용 시에도 문자열 연결로 쿼리 구성하면 인젝션 취약
복잡한 검색 기능이나 리포팅 쿼리에서 Raw SQL을 사용해야 할 때, 파라미터 바인딩을 정확히 이해하지 못하면 ORM을 사용하더라도 SQL 인젝션 취약점이 발생할 수 있습니다.
Django ORM의 filter() 메서드에서 필드 룩업을 동적으로 구성해야 할 때 안전한 방법은 무엇일까요?
Q. Django 애플리케이션에서 개인정보(주민등록번호, 신용카드 번호 등)를 데이터베이스에 저장해야 할 때, 암호화 방식 선택과 키 관리 전략을 설명해주세요. 또한 django-fernet-fields나 django-cryptography 같은 필드 레벨 암호화 라이브러리의 장단점을 설명해주세요.
대칭키 암호화와 비대칭키 암호화의 차이, 그리고 암호화 키를 어디에 보관할지 고려해보세요.
개인정보는 AES-256 같은 대칭키 암호화로 암호화하며, 검색이 필요한 경우 해시된 인덱스 컬럼을 별도로 관리합니다. django-fernet-fields는 Fernet(AES-128 기반)을 사용하여 필드 레벨에서 투명하게 암호화/복호화를 처리하지만, 암호화 키가 코드나 환경변수에 노출될 위험이 있고 데이터베이스에서 직접 검색이 불가능합니다. 암호화 키는 AWS KMS, HashiCorp Vault, Azure Key Vault 같은 전용 키 관리 서비스에 저장하고, 애플리케이션 시작 시 동적으로 로드해야 합니다. 키 로테이션을 고려하여 다중 키 버전을 지원하고, 구 키로 암호화된 데이터를 새 키로 점진적으로 마이그레이션하는 전략이 필요합니다. 민감도가 매우 높은 데이터는 애플리케이션 레벨 암호화와 데이터베이스 TDE(Transparent Data Encryption)를 함께 적용하는 다층 보안을 구성합니다.
- • AES-256 대칭키 암호화 사용 및 검색용 해시 인덱스 별도 관리
- • 암호화 키는 AWS KMS, Vault 등 전용 키 관리 서비스에 보관
- • django-fernet-fields는 편리하지만 키 노출 위험과 검색 제약 존재
- • 키 로테이션 전략과 다층 보안(애플리케이션+DB TDE) 고려
금융, 의료, 통신 서비스에서 개인정보 보호법 준수를 위해 민감 정보를 암호화 저장해야 하며, 키 관리와 검색 요구사항을 동시에 만족하는 설계가 필요합니다.
암호화된 필드에 대해 부분 일치 검색이나 범위 검색이 필요한 경우 어떻게 구현하시겠습니까?
Q. Django에서 역할 기반 접근 제어(RBAC)와 속성 기반 접근 제어(ABAC)의 차이를 설명하고, Django의 Permission 시스템과 django-guardian을 활용하여 객체 레벨 권한을 구현할 때의 설계 방법과 성능 고려사항을 설명해주세요.
모델 레벨 권한과 객체 레벨 권한의 차이, 그리고 권한 체크 시 발생하는 쿼리 수를 생각해보세요.
RBAC는 사용자의 역할(Role)에 따라 권한을 부여하는 방식으로 Django의 기본 Permission 시스템(add, change, delete, view)이 이에 해당하며, 모델 레벨에서 동작합니다. ABAC는 사용자 속성, 리소스 속성, 환경 조건 등을 조합하여 동적으로 권한을 판단하는 방식으로 더 세밀한 제어가 가능하지만 복잡도가 높습니다. django-guardian은 객체 레벨 권한을 제공하여 특정 인스턴스에 대한 권한을 개별적으로 관리할 수 있지만, 권한 체크마다 추가 쿼리가 발생하므로 select_related나 prefetch_related로 최적화해야 합니다. 대량의 객체를 조회할 때는 get_objects_for_user() 메서드로 권한이 있는 객체만 필터링하고, 캐싱(Redis)을 활용하여 반복적인 권한 체크 비용을 줄여야 합니다. 복잡한 비즈니스 로직이 필요한 경우 커스텀 Permission 클래스를 구현하여 has_permission()과 has_object_permission()을 오버라이드합니다.
- • RBAC는 역할 기반, ABAC는 속성 기반 동적 권한 제어
- • Django 기본 Permission은 모델 레벨, django-guardian은 객체 레벨 권한
- • 객체 레벨 권한 체크 시 추가 쿼리 발생하므로 prefetch 및 캐싱 필수
- • get_objects_for_user()로 권한 필터링 및 커스텀 Permission 클래스 활용
협업 도구, 문서 관리 시스템, CMS 등에서 사용자마다 다른 객체에 대한 접근 권한을 세밀하게 제어해야 할 때 객체 레벨 권한 시스템이 필수적입니다.
다중 테넌트 SaaS 서비스에서 조직별로 데이터를 격리하면서 역할 기반 권한을 구현한다면 어떤 구조로 설계하시겠습니까?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!