이번 글의 세 문항은 공개 기출문제의 원문을 재현하지 않은 창작 문제다. 정답과 해설은 게시 시점에 확인한 RFC Editor, OWASP, NIST 공식 자료를 근거로 작성했다.

문제 1 — TLS 1.3의 순방향 비밀성

문제

TLS 1.3에서 (EC)DHE 기반 키 교환을 사용할 때 기대할 수 있는 보안 특성으로 가장 적절한 것은?

선택지

  1. 장기 인증 키가 나중에 노출되어도 과거 세션 키를 쉽게 복원할 수 있다.
  2. 매 세션의 임시 키 교환으로 장기 키 노출 이후에도 과거 세션 보호를 강화할 수 있다.
  3. 서버 인증서가 없어도 모든 통신 상대의 신원이 자동으로 검증된다.
  4. 키 교환만으로 애플리케이션의 접근권한 검사가 완료된다.

정답

2번

해설

TLS 1.3의 비대칭 키 교환은 key_share를 사용해 순방향 비밀성(forward secrecy)을 제공할 수 있다. 장기 서명 키가 핸드셰이크 이후 노출되더라도 과거 세션 키를 바로 계산할 수 없도록 하는 성질이다. 다만 이는 애플리케이션 인가나 모든 상대방 인증을 대신하지 않는다. [1]

오답 포인트

암호화된 채널의 기밀성과 애플리케이션 권한 검사는 별개의 통제다. 또한 PSK-only 모드는 순방향 비밀성을 자동으로 보장하지 않으므로 키 교환 모드를 구분해야 한다. [2]

출처 또는 검증 근거

[1] RFC Editor, RFC 8446, The Transport Layer Security (TLS) Protocol Version 1.3, https://www.rfc-editor.org/rfc/rfc8446.html [2] RFC Editor, RFC 9257, Guidance for External PSKs in TLS 1.3, https://www.rfc-editor.org/rfc/rfc9257.html

문제 2 — XSS와 문맥별 출력 인코딩

문제

사용자 입력을 HTML 본문에 표시해야 할 때 교차 사이트 스크립팅(XSS) 위험을 줄이는 방법으로 가장 적절한 것은?

선택지

  1. 모든 위치에 동일한 문자열 치환 규칙을 적용한다.
  2. 입력을 서버에서 한 번만 인코딩한 뒤 HTML·JavaScript·URL 어디에나 재사용한다.
  3. 출력이 삽입되는 문맥에 맞는 인코더를 사용해 신뢰할 수 없는 값을 데이터로 표시한다.
  4. 클라이언트에서만 길이 검사를 하고 HTML 템플릿에는 원문을 삽입한다.

정답

3번

해설

OWASP는 HTML, HTML 속성, JavaScript, URL 등 브라우저의 해석 문맥에 따라 서로 다른 출력 인코딩이 필요하다고 설명한다. HTML 본문에는 HTML 엔터티 인코딩을 적용해 입력이 코드가 아니라 데이터로 해석되도록 해야 한다. [3]

오답 포인트

“한 번 인코딩” 또는 “특수문자 일부 제거”는 목적 문맥을 보장하지 않는다. HTML 속성용 인코딩을 JavaScript 문맥에 그대로 적용하는 것도 안전한 대체가 아니다. [3]

출처 또는 검증 근거

[3] OWASP, Cross Site Scripting Prevention Cheat Sheet, https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html

문제 3 — 암호키의 폐기

문제

암호키 관리에 대한 설명으로 NIST 키 관리 지침에 부합하는 것은?

선택지

  1. 사용이 끝난 비밀키도 편의를 위해 영구 보관하고 계속 활성 상태로 둔다.
  2. 키의 생성·보관·사용·폐기를 수명주기로 관리하고, 더 이상 필요하지 않은 키는 적절히 폐기한다.
  3. 키 이름과 용도만 관리하면 실제 키 보호는 필요하지 않다.
  4. 암호 알고리즘이 강하면 키 접근권한과 폐기 절차는 불필요하다.

정답

2번

해설

NIST SP 800-57은 암호키 관리가 키의 안전한 생성, 저장, 배포, 사용, 폐기를 다루며 키 수명주기의 모든 단계에서 중요하다고 설명한다. 더 이상 필요하지 않은 키는 노출 위험을 줄이기 위해 지침에 따라 폐기해야 한다. [4]

오답 포인트

강한 알고리즘만으로 키 관리 실패를 보완할 수 없다. 키의 보호 요구사항, 사용기간(cryptoperiod), 백업·복구·폐기를 별도 운영통제로 관리해야 한다. [4]

출처 또는 검증 근거

[4] NIST, SP 800-57 Part 1 Revision 4: Recommendation for Key Management, https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-57pt1r4.pdf