[MindSprout 4편] 타이밍 어택을 막는 Next.js 보안 세션 및 RBAC 구축기

작성자:

1. 서론: 대외망 개방의 첫 걸음, 견고한 Next.js 보안 세션 구축

[지난 3편]에서는 Next.js 서버 컴포넌트(RSC)와 Tailwind CSS를 활용해 데이터를 시각화하고 칸반 보드로 관리하는 고성능 대시보드를 구축했습니다. 로컬 환경에서 대시보드가 정상적으로 돌아가는 모습을 보며 만족했지만, 이 AI 비서는 집 밖이나 이동 중(모바일 기기, 카페 등 외부 네트워크)에서도 안전하게 접속하여 모니터링할 수 있어야 진정한 가치를 발휘합니다.

그러나 시스템을 로컬 망 밖으로 노출(대외망 개방)하는 순간, 수많은 자동화 스캔 봇과 해킹 위협에 직면하게 됩니다. 특히 MindSprout는 민감한 개인 정보와 관리 기록이 저장되는 만큼, 어설픈 로그인 체계는 허용될 수 없었습니다.

처음에는 Firebase Auth나 Supabase의 소셜 로그인 연동을 검토했으나, 내부 관계자들만 접속하는 프라이빗 도구의 특성상 무거운 OAuth 인증 대신 “접속 키(Access Key) 기반의 가볍지만 타협 없는 수준의 Next.js 보안 세션 체계”를 백엔드에 직접 구축하기로 결정했습니다.

이번 4편에서는 Node.js의 crypto 모듈을 사용해 나노초 단위의 실행 시간 차이를 이용한 타이밍 어택(Timing Attack)을 방어하고, HTTP-Only 쿠키 기반의 역할 기반 권한 제어(RBAC)를 구현한 Next.js 보안 세션 설계 과정과 CSRF 방어 트러블슈팅 경험을 공유합니다.

2. 타이밍 어택(Timing Attack)의 위협과 timingSafeEqual의 마법

안전한 Next.js 보안 세션을 구축하기 위해 로그인 폼을 개발할 때, 개발자들은 흔히 다음과 같이 직관적인 코드를 작성하곤 합니다.

TypeScript

// 일반적인 암호 비교 방식 (보안 취약)
if (submittedKey === process.env.MINDSPROUT_OWNER_ACCESS_KEY) {
  // 로그인 성공
}

이 코드는 로컬 개발 단계에서는 문제없이 잘 작동하는 것처럼 보입니다. 하지만 컴퓨터 보안의 세계에서는 이 단순한 비교 연산자(===) 하나가 시스템을 해킹하는 단초를 제공하게 됩니다.

2.1. 비교 연산의 나노초 차이를 노리는 해커

컴퓨터가 두 문자열을 비교할 때, 첫 번째 글자부터 순서대로 검증을 수행합니다. 만약 첫 번째 글자부터 틀렸다면, 컴퓨터는 그 즉시 비교 연산을 종료(Early Exit)하고 false를 반환합니다.

반면 첫 세 글자가 일치한다면 세 번째 글자까지 검사한 뒤에 종료하므로 서버의 응답 시간이 아주 미세하게 길어집니다. 해커는 이 나노초 단위의 서버 응답 속도 차이를 측정하여 비밀번호를 한 글자씩 유추해 나갑니다. 이를 타이밍 어택(Timing Attack)이라고 부릅니다.

2.2. 일정한 응답 시간을 보장하는 방어 로직

이러한 해킹을 완벽히 방지하려면 문자열의 일치 여부와 관계없이 항상 동일한 실행 시간을 가지는 연산을 수행해야 합니다. Node.js는 내장 crypto 라이브러리를 통해 이를 보장하는 timingSafeEqual 함수를 제공합니다.

TypeScript

import { timingSafeEqual } from 'crypto';

/**
 * 타이밍 어택을 방어하며 안전하게 자격 증명을 비교합니다.
 */
function credentialsMatch(actual: string, expected: string): boolean {
  if (!actual || !expected) return false;
  
  const actualBuffer = Buffer.from(actual);
  const expectedBuffer = Buffer.from(expected);
  
  // 두 버퍼의 길이가 다른 경우 비교 연산 실행 시간으로 길이 유추가 가능하므로,
  // 일단 동일한 길이의 가짜 버퍼와 비교하게 만드는 안전장치를 곁들입니다.
  if (actualBuffer.length !== expectedBuffer.length) {
    return false;
  }
  
  return timingSafeEqual(actualBuffer, expectedBuffer);
}

이 함수는 버퍼의 시작부터 끝까지 무조건 모든 바이트를 대조한 뒤 결론을 내립니다. 따라서 서버의 응답 지연 편차를 완전히 제거하여 타이밍 기반 분석 공격을 원천 봉쇄할 수 있습니다.

3. 다중 사용자 관리를 위한 역할 기반 권한 제어(RBAC) 구현

MindSprout는 시스템의 전권을 가진 admin(시스템 전역 관리자)과 부분적인 권한을 가진 principal(파트너 원장) 역할을 분리하여 인가를 관리해야 했습니다. 이를 Next.js 보안 세션과 Route Handler를 통해 유기적으로 구현했습니다.

TypeScript

type SessionRole = 'admin' | 'principal';

function resolveSessionRole(submittedKey: string): SessionRole | null {
  const adminKey = process.env.MINDSPROUT_OWNER_ACCESS_KEY || '';
  if (credentialsMatch(submittedKey, adminKey)) {
    return 'admin';
  }

  // principal 키 목록 중 하나와 일치하는지 스캔
  const principalKeys = (process.env.MINDSPROUT_PRINCIPAL_ACCESS_KEY || '')
    .split(',')
    .map((key) => key.trim())
    .filter(Boolean);

  const matchedPrincipal = principalKeys.some((principalKey) =>
    credentialsMatch(submittedKey, principalKey)
  );

  return matchedPrincipal ? 'principal' : null;
}

제출된 접속 키의 매칭 결과에 따라 쿠키를 생성하고, 브라우저가 자바스크립트로 접근할 수 없도록 httpOnly: true, secure: true, sameSite: 'lax' 옵션을 부여하여 세션을 유지시켰습니다.

이렇게 발급된 보안 쿠키는 백엔드 미들웨어에서 매 요청마다 읽혀 인가를 판단하므로 클라이언트 측에서 임의로 변조하는 것이 불가능합니다.

4. 트러블슈팅: 오리진(Origin) 위조 공격과 CSRF 완벽 방어

세션을 무사히 연결하고 외부 접속 테스트를 마쳤을 때 즈음, 보안 감사 로그에서 의문스러운 경고 메시지들을 발견했습니다. 해커가 아닌 일반 웹 브라우저의 정상적인 요청임에도 인증 오류가 빈번히 떨어지는 현상이었습니다.

원인은 Next.js 보안 세션을 지키기 위해 적용했던 CSRF(교차 사이트 요청 위조) 방어 가드 로직 때문이었습니다.

4.1. [❌ 문제 상황: 동일 오리진 판별 오류]

외부에서 사이트에 처음 접속하여 세션을 획득할 때, 악의적인 외부 사이트가 사용자의 브라우저 권한을 남용해 요청을 위조하는 것을 막기 위해 Origin과 Referer 헤더 검증 로직을 도입했습니다.

하지만 리버스 프록시(Nginx 등) 및 터널링 스크립트(dev-tunnel.mjs)를 거쳐 포트 포워딩이 이루어질 때 문제가 발생했습니다. 헤더의 host 필드에는 로컬 주소(localhost:3000)가 들어오고 origin에는 외부 도메인 주소가 실려 들어와, 정상적인 관리자 로그인마저 해킹 시도로 오판하여 401 오류를 내뿜은 것입니다.

4.2. [✅ 해결 코드: 프로토콜 및 포워드 헤더를 고려한 Request Guard 개선]

이 문제를 해결하기 위해, 리버스 프록시가 주입해 주는 x-forwarded-host와 x-forwarded-proto 헤더까지 종합적으로 대조하도록 로직을 수정했습니다. 실제 클라이언트의 신뢰할 수 있는 도메인 주소를 구성한 뒤 비교하도록 Request Guard를 고도화했습니다.

TypeScript

// src/features/auth/request-guard.ts
import { NextRequest } from 'next/server';

/**
 * CSRF 공격을 방지하기 위해 요청이 동일한 오리진(Same-Origin)에서 발생했는지 검증합니다.
 */
export function assertSameOriginMutation(req: NextRequest) {
  // 프로토콜(http/https)과 실질 도메인을 포워드 헤더 고려하여 검증
  const proto = req.headers.get('x-forwarded-proto') || 'http';
  const host = req.headers.get('x-forwarded-host') || req.headers.get('host') || '';
  
  const serverOrigin = `${proto}://${host}`;
  const requestOrigin = req.headers.get('origin') || req.headers.get('referer') || '';

  if (requestOrigin) {
    const serverUrl = new URL(serverOrigin);
    const requestUrl = new URL(requestOrigin);

    // 프로토콜과 호스트(포트 포함)가 정확히 동일한지 대조
    if (serverUrl.origin !== requestUrl.origin) {
      throw new Error(`[보안 거부] CSRF 방어 가드 작동: 오리진 불일치 (${requestUrl.origin} !== ${serverUrl.origin})`);
    }
  }
}

수정 후 외부 보안 터널링 및 실 서버 운영 환경에서도 동일 도메인 판별 루프가 아무런 크래시 없이 안전하게 정합성을 보장했습니다.

5. 결론 및 5편 예고

이번 4편에서는 외부 개방에 따른 대시보드 보호 기법으로, CPU 연산 속도 차이를 가로채는 타이밍 어택 방어법과 Next.js 보안 세션 설계, 그리고 프록시 환경의 CSRF 방지 가드 구축기를 다루었습니다. 이러한 보안 세부 기법들은 눈에 보이지 않지만, 서비스가 외부에 안전하게 생존하는 든든한 방패막이가 되어 줍니다.

보안이 완료됨으로써, 우리는 이제 모바일 기기에서도 안전하게 데스크를 관리할 수 있는 토대를 마련했습니다.

다음 5편에서는 텔레그램 수집 파이프라인의 숨은 복병, “사용자가 전송한 OGG 음성 메시지를 다운로드하여 실시간 STT(Speech-to-Text) 및 AI 프롬프트 분석으로 에러 없이 전달하는 멀티미디어 파이프라인 구축기”로 찾아뵙겠습니다. 오디오 포맷의 변환 한계와 API 레이턴시 극복기를 기대해 주세요.

AI 보안 구현과 관련된 여러분만의 최적화 경험이나 timingSafeEqual의 또 다른 응용 사례가 있다면 편하게 댓글로 의견을 공유해 주세요!

댓글 남기기