웹 보안 시니어 CS 기초 면접
새 면접Q. TLS 1.3 핸드셰이크 과정에서 0-RTT(Zero Round Trip Time) 모드의 동작 원리를 설명하고, 이것이 replay attack에 취약한 이유를 네트워크 프로토콜 관점에서 설명해주세요. 또한 이를 완화하기 위한 서버 측 방어 전략과 그 트레이드오프를 제시해주세요.
0-RTT는 이전 세션의 PSK를 재사용하여 첫 번째 요청에 데이터를 포함시키는데, 이 요청이 중간에 캡처되면 어떤 일이 발생할지 생각해보세요.
0-RTT 모드는 클라이언트가 이전 세션에서 얻은 PSK(Pre-Shared Key)를 사용해 핸드셰이크 없이 즉시 암호화된 데이터를 전송합니다. 하지만 서버는 해당 요청이 재전송된 것인지 판단할 수 없어 동일한 요청을 여러 번 처리할 수 있습니다. 방어 전략으로는 단일 티켓 사용 제한(single-use ticket), 클라이언트 IP 기반 필터링, 타임스탬프 검증, 또는 idempotent한 작업만 0-RTT에서 허용하는 방법이 있습니다. 트레이드오프는 보안 강화 시 0-RTT의 성능 이점이 감소하거나 상태 저장 오버헤드가 증가한다는 점입니다. 실무에서는 GET 요청만 허용하고 상태 변경 작업은 full handshake 이후에만 처리하는 것이 일반적입니다.
- • 0-RTT는 PSK를 사용해 핸드셰이크 없이 데이터 전송
- • 서버가 요청 중복 여부를 판단할 수 없어 replay attack 취약
- • 단일 티켓 사용, idempotent 작업 제한 등으로 완화
- • 보안과 성능 간 트레이드오프 존재
CDN이나 API 게이트웨이에서 TLS 성능 최적화 시 0-RTT 적용 여부를 결정할 때 필요한 지식입니다.
대규모 분산 시스템에서 단일 티켓 사용을 강제하려면 어떤 자료구조와 동기화 메커니즘이 필요할까요?
Q. 메모리 안전성을 위한 ASLR(Address Space Layout Randomization)과 DEP(Data Execution Prevention)의 동작 원리를 OS 메모리 관리 관점에서 설명하고, 각각이 방어하는 공격 유형을 제시해주세요. 또한 두 기법을 우회하는 ROP(Return-Oriented Programming) 공격의 원리와 이에 대한 추가 방어 기법을 설명해주세요.
ASLR은 메모리 주소를 예측 불가능하게 만들고, DEP는 특정 메모리 영역의 실행 권한을 제어하는데, 공격자가 이미 존재하는 코드를 재사용한다면 어떻게 될까요?
ASLR은 프로세스 시작 시 스택, 힙, 라이브러리의 base address를 무작위화하여 buffer overflow 등으로 얻은 메모리 주소를 무용지물로 만듭니다. DEP는 페이지 테이블의 NX(No-eXecute) 비트를 설정해 스택이나 힙에 주입된 shellcode 실행을 방지합니다. ROP는 이미 메모리에 존재하는 실행 가능한 코드 조각(gadget)들을 연결해 공격하므로 DEP를 우회하며, 메모리 leak을 통해 ASLR도 우회 가능합니다. 방어 기법으로는 CFI(Control Flow Integrity)로 허용된 제어 흐름만 실행하거나, 스택 카나리, shadow stack, CET(Control-flow Enforcement Technology) 등 하드웨어 지원 기술을 사용합니다.
- • ASLR은 메모리 주소 무작위화로 주소 예측 방지
- • DEP는 NX 비트로 데이터 영역 코드 실행 차단
- • ROP는 기존 코드 재사용으로 두 기법 우회
- • CFI, shadow stack 등 추가 방어 계층 필요
네이티브 확장 모듈을 사용하는 웹 서버나 바이너리 레벨 보안이 중요한 시스템에서 메모리 보호 전략을 설계할 때 필요합니다.
컨테이너 환경에서 ASLR의 효과가 감소하는 이유와 이를 보완할 수 있는 방법은 무엇인가요?
Q. 데이터베이스에서 트랜잭션 격리 수준(Isolation Level)이 보안에 미치는 영향을 설명해주세요. Read Uncommitted, Read Committed, Repeatable Read, Serializable 각 수준에서 발생 가능한 보안 취약점과, 민감한 금융 데이터를 다루는 시스템에서 적절한 격리 수준 선택 기준을 제시해주세요.
낮은 격리 수준에서는 다른 트랜잭션의 중간 상태를 읽을 수 있는데, 이것이 인가되지 않은 정보 노출로 이어질 수 있는지 고려해보세요.
Read Uncommitted는 커밋되지 않은 데이터를 읽을 수 있어 권한 체크 전 데이터나 롤백될 민감 정보가 노출될 수 있습니다. Read Committed는 dirty read를 방지하지만 같은 쿼리를 두 번 실행했을 때 다른 결과가 나올 수 있어(non-repeatable read) 보안 검증 로직에서 TOCTOU(Time-of-check to time-of-use) 취약점이 발생할 수 있습니다. Repeatable Read는 phantom read가 가능해 집계 기반 권한 체크에서 문제가 될 수 있습니다. 금융 시스템에서는 일반적으로 Serializable을 사용하되, 성능이 중요한 읽기 작업은 Repeatable Read와 명시적 락을 조합합니다. 격리 수준과 함께 row-level security, 감사 로그, 암호화를 함께 적용해야 합니다.
- • 낮은 격리 수준은 커밋 전 데이터 노출 위험
- • Read Committed는 TOCTOU 취약점 가능
- • 금융 시스템은 Serializable 또는 명시적 락 사용
- • 격리 수준만으로 부족하며 다층 보안 필요
결제 시스템이나 계좌 이체 등 금융 트랜잭션에서 동시성 제어와 보안을 모두 만족시키는 격리 수준을 선택할 때 필요합니다.
분산 데이터베이스 환경에서 Serializable 격리 수준을 구현할 때의 성능 오버헤드와 이를 최소화하는 방법은 무엇인가요?
Q. DNS 프로토콜의 보안 취약점인 DNS Spoofing과 DNS Amplification 공격의 원리를 패킷 레벨에서 설명하고, DNSSEC과 DNS over HTTPS(DoH)가 각각 어떤 공격을 방어하는지 비교해주세요. 또한 대규모 서비스에서 DoH를 도입할 때의 성능 및 운영상 트레이드오프를 제시해주세요.
DNS는 UDP 기반이며 응답 검증이 약하다는 점, 그리고 작은 쿼리로 큰 응답을 유도할 수 있다는 점을 고려해보세요.
DNS Spoofing은 UDP의 stateless 특성을 이용해 정상 응답보다 먼저 위조된 DNS 응답을 보내 캐시를 오염시킵니다. DNS Amplification은 작은 쿼리(64바이트)로 큰 응답(4KB)을 유도해 피해자 IP로 반사시키는 DDoS 공격입니다. DNSSEC은 공개키 암호화로 DNS 응답의 무결성과 출처를 검증하여 spoofing을 방어하지만, amplification은 막지 못합니다. DoH는 DNS 쿼리를 HTTPS로 암호화하여 중간자 공격과 감청을 방어하지만, DNSSEC처럼 응답 무결성을 보장하지는 않습니다. DoH 도입 시 TLS 핸드셰이크 오버헤드, connection pooling 필요성, 기존 DNS 기반 보안 장비 우회 문제, 캐싱 계층 복잡도 증가 등을 고려해야 합니다.
- • DNS Spoofing은 UDP 특성을 이용한 응답 위조
- • DNS Amplification은 반사 기반 DDoS 공격
- • DNSSEC은 무결성 검증, DoH는 암호화 제공
- • DoH는 TLS 오버헤드와 운영 복잡도 증가
CDN이나 글로벌 서비스에서 DNS 기반 공격을 방어하고 사용자 프라이버시를 보호하는 DNS 인프라를 설계할 때 필요합니다.
기업 내부 네트워크에서 DoH가 보안 정책 우회 수단으로 악용될 수 있는 시나리오와 이를 탐지하는 방법은 무엇인가요?
Q. JWT 토큰 블랙리스트를 구현하기 위한 자료구조를 설계해야 합니다. Bloom Filter, Redis Set, Trie 구조를 시간 복잡도와 공간 복잡도 측면에서 비교하고, 초당 10만 건의 토큰 검증 요청과 1억 개의 블랙리스트 항목을 처리해야 하는 환경에서 가장 적합한 자료구조와 그 이유를 설명해주세요.
토큰 블랙리스트는 존재 여부만 확인하면 되며, false positive를 어느 정도 허용할 수 있는지가 중요한 결정 요소입니다.
Bloom Filter는 O(k) 시간에 검색하며(k는 해시 함수 개수), 공간은 O(m)으로 매우 효율적이지만 false positive가 발생합니다. Redis Set은 O(1) 평균 검색 시간이지만 각 토큰을 완전히 저장해 메모리가 많이 필요합니다(1억 개 * 평균 200바이트). Trie는 O(L) 시간 복잡도(L은 토큰 길이)이며 공통 접두사를 공유해 압축 효과가 있지만 포인터 오버헤드가 큽니다. 대규모 환경에서는 Bloom Filter를 1차 필터로 사용하고, false positive 발생 시에만 Redis Set으로 2차 검증하는 하이브리드 방식이 최적입니다. Bloom Filter로 99%의 요청을 빠르게 처리하고, 메모리는 수십 MB로 제한하며, Redis는 실제 블랙리스트만 저장해 메모리 효율과 성능을 모두 확보합니다.
- • Bloom Filter는 공간 효율적이나 false positive 존재
- • Redis Set은 정확하지만 메모리 사용량이 큼
- • 하이브리드 방식으로 양쪽 장점 활용
- • 1차 필터로 대부분 요청 빠르게 처리
마이크로서비스 환경에서 로그아웃된 JWT 토큰을 빠르게 검증하면서도 메모리 사용량을 최소화해야 할 때 사용됩니다.
Bloom Filter의 false positive rate를 1% 이하로 유지하면서 1억 개 항목을 저장하려면 몇 비트의 배열과 몇 개의 해시 함수가 필요한가요?
Q. Content Security Policy(CSP) 위반 리포트를 실시간으로 분석하여 공격 패턴을 탐지하는 시스템을 설계합니다. 시간 윈도우 내에서 동일한 출처의 위반이 임계값을 초과하면 알림을 발생시켜야 하는데, 이를 위한 sliding window 기반 카운팅 알고리즘을 설계하고 시간 복잡도를 분석해주세요. 또한 수백만 개의 서로 다른 출처를 추적해야 할 때 메모리 효율적인 방법을 제시해주세요.
각 출처별로 타임스탬프를 저장하는 방식과, 시간을 버킷으로 나누어 카운트만 저장하는 방식의 정확도와 효율성을 비교해보세요.
Sliding window 구현 방법으로는 각 이벤트의 타임스탬프를 큐에 저장하는 방식(정확하지만 O(n) 공간)과, 시간을 고정 버킷으로 나누어 카운트만 저장하는 방식(O(1) 공간, 근사치)이 있습니다. 실시간 처리를 위해서는 Redis Sorted Set을 사용해 타임스탬프를 스코어로 저장하고, ZREMRANGEBYSCORE로 만료된 항목을 제거하며 ZCARD로 카운트를 확인합니다(O(log n) 삽입, O(1) 카운트). 메모리 효율화를 위해 HyperLogLog로 고유 출처 수를 추정하거나, Count-Min Sketch로 빈도를 근사 추정할 수 있습니다. 수백만 출처 추적 시에는 LRU 캐시로 활성 출처만 메모리에 유지하고, 나머지는 시계열 DB에 저장하는 계층화 전략이 효과적입니다. 공간 복잡도는 O(k*w)로 제한됩니다(k는 활성 출처 수, w는 윈도우 크기).
- • Sorted Set으로 O(log n) 삽입과 O(1) 카운트 구현
- • 타임스탬프 저장 vs 버킷 카운트의 트레이드오프
- • HyperLogLog나 Count-Min Sketch로 메모리 절약
- • LRU 캐시와 시계열 DB로 계층화
실시간 보안 모니터링 시스템에서 비정상적인 패턴을 탐지하고 즉시 대응해야 하는 SIEM 솔루션에서 사용됩니다.
Count-Min Sketch의 정확도를 높이기 위해 해시 함수 개수와 배열 크기를 어떻게 결정해야 하나요?
Q. HTTP/2의 multiplexing 기능이 보안에 미치는 영향을 설명하고, 단일 TCP 연결을 공유함으로써 발생할 수 있는 취약점을 제시해주세요. 특히 stream priority 조작을 통한 서비스 거부 공격의 원리와, HTTP/3(QUIC)이 이 문제를 어떻게 개선하는지 프로토콜 레벨에서 비교해주세요.
하나의 TCP 연결에서 여러 스트림이 경쟁할 때, 악의적인 클라이언트가 우선순위를 조작하거나 많은 스트림을 생성하면 어떤 일이 발생할까요?
HTTP/2의 multiplexing은 하나의 TCP 연결에서 여러 스트림을 동시에 처리하므로, 하나의 스트림이 블록되면 head-of-line blocking이 TCP 레벨에서 발생해 모든 스트림에 영향을 줍니다. 악의적인 클라이언트는 높은 우선순위로 많은 스트림을 생성하거나, PRIORITY 프레임을 반복 전송해 서버 CPU를 소진시킬 수 있습니다(Rapid Reset 공격). 또한 SETTINGS 프레임으로 윈도우 크기를 조작해 서버 메모리를 고갈시킬 수 있습니다. HTTP/3는 QUIC 프로토콜을 사용해 각 스트림이 독립적으로 전송되므로 한 스트림의 패킷 손실이 다른 스트림에 영향을 주지 않습니다. QUIC는 연결 수준과 스트림 수준 flow control을 분리하고, 커널 대신 사용자 공간에서 구현되어 rate limiting과 리소스 제한을 더 세밀하게 제어할 수 있습니다.
- • HTTP/2는 TCP head-of-line blocking 존재
- • PRIORITY와 SETTINGS 조작으로 자원 고갈 공격 가능
- • HTTP/3는 스트림 독립성으로 blocking 해결
- • QUIC의 사용자 공간 구현으로 세밀한 제어 가능
클라우드 로드밸런서나 API 게이트웨이에서 HTTP/2 프로토콜 레벨 공격을 방어하고 프로토콜 버전을 선택할 때 필요합니다.
대규모 API 게이트웨이에서 HTTP/2 Rapid Reset 공격을 탐지하고 차단하기 위한 실시간 모니터링 지표는 무엇인가요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!