React 보안과 안정성 (XSS, CSRF 예방부터 OAuth, 서드파티 관리까지) - React, 알고 쓰자 12일차

React Security & Stability (XSS/CSRF Prevention, OAuth, 3rd Party Mgmt) - React Explained Day 12

import React from "react";
 
function UserProfile({ bio }: { bio: string }) {
  // 사용자가 입력한 bio 내용을 HTML로 해석하여 그대로 삽입
  // 절대 이렇게 사용하면 안 됩니다!
  return (
    <div>
      <h3>소개</h3>
      <div dangerouslySetInnerHTML={{ __html: bio }} />
    </div>
  );
}
 
const UserProfilePage = () => {
  // 만약 공격자가 bio에 다음과 같은 악성 스크립트를 입력했다면?
  const bio =
    '안녕하세요! 저는 웹 개발자입니다. <script>alert("XSS 공격 성공! 쿠키: " + document.cookie);</script>';
  return (
    <div>
      <h1>사용자 프로필</h1>
      <UserProfile bio={bio} /> 
      {/* 이 컴포넌트가 렌더링되면, 다른 사용자의 브라우저에서 스크립트가 실행되어 경고창이 뜨고 쿠키 정보가 노출될 수 있습니다. */}
    </div>
  );
};
export default UserProfilePage;

dangerouslySetInnerHTML 렌더링 시

import React from "react";
 
function UserProfile({ bio }: { bio: string }) {
  // 사용자가 입력한 bio 내용을 HTML로 해석하여 그대로 삽입
  // 절대 이렇게 사용하면 안 됩니다!
  return (
    <div>
      <h3>소개</h3>
      <div>{bio}</div>
    </div>
  );
}
 
const UserProfilePage = () => {
  // 만약 공격자가 bio에 다음과 같은 악성 스크립트를 입력했다면?
  const bio =
    '안녕하세요! 저는 웹 개발자입니다. <script>alert("XSS 공격 성공! 쿠키: " + document.cookie);</script>';
  return (
    <div>
      <UserProfile bio={bio} />
      {/* 이 컴포넌트가 렌더링되면, 다른 사용자의 브라우저에서 스크립트가 실행되어 경고창이 뜨고 쿠키 정보가 노출될 수 있습니다. */}
    </div>
  );
};
export default UserProfilePage;

문자열로 취급

• DOMPurify
  : 가장 널리 사용되는 JavaScript 기반 HTML 정제 라이브러리 중 하나입니다. 허용할 태그와 속성을 설정하고 안전하지 않은 코드를 제거해 줍니다.

  import DOMPurify from 'dompurify';
   
  function SanitizedHtmlComponent({ dirtyHtml }: { dirtyHtml: string }) {
    // HTML 정제 수행
    const cleanHtml = DOMPurify.sanitize(dirtyHtml);
   
    // 정제된 안전한 HTML만 렌더링
    return <div dangerouslySetInnerHTML={{ __html: cleanHtml }} />;
  }

<!-- 사용자는 이 이미지를 보지만, 브라우저는 mybank.com으로 요청을 보낸다 -->
<img src="https://mybank.com/transfer?to=hacker&amount=1000000" width="1" height="1" />
 
<!-- 또는, 자동으로 제출되는 숨겨진 폼 -->
<form id="csrf-form" action="https://mybank.com/change-password" method="POST" style="display:none;">
  <input type="hidden" name="newPassword" value="hacked123" />
</form>
<script>document.getElementById('csrf-form').submit();</script>

• 원리
  :
  1. 사용자가 로그인하거나 특정 폼 페이지에 접근할 때, 서버는 예측 불가능한 임의의 문자열(
     CSRF 토큰
     )을 생성하여 사용자 세션에 저장하고, 동시에 클라이언트(프론트엔드)에게도 전달합니다 (예: HTML 폼의 hidden 필드, 메타 태그, API 응답 등).
  2. 클라이언트는 서버로부터 받은 CSRF 토큰을 저장합니다 (예: JavaScript 변수).
  3. 사용자가 중요한 작업(예: 송금, 비밀번호 변경 등 상태 변경 요청)을 수행할 때, 클라이언트는 저장된 CSRF 토큰을 요청 데이터(폼 데이터 또는 HTTP 헤더 - 예: X-CSRF-Token)에 포함시켜 서버로 전송합니다.
  4. 서버는 요청을 받으면, 요청에 포함된 토큰과 사용자 세션에 저장된 토큰을 비교합니다.
  5. 두 토큰이 일치하면 요청이 유효하다고 판단하고 처리하고, 일치하지 않으면 CSRF 공격으로 간주하여 요청을 거부합니다.
• 프론트엔드의 역할
  :
  • 서버로부터 CSRF 토큰을 안전하게 수신하고 저장합니다.
  • 상태 변경을 유발하는 모든 요청(주로 POST, PUT, DELETE 등)에 CSRF 토큰을 포함시켜 보냅니다. Axios 같은 라이브러리는 이를 위한 인터셉터 설정이 편리할 수 있습니다.

CSRF 토큰 패턴 동작 흐름도

• SameSite=Strict
  쿠키가 현재 사이트와 동일한 사이트에서 시작된 요청에만 전송됩니다.
  외부 사이트에서 시작된 요청(예: evil.com에서 mybank.com으로)에는 쿠키가 전혀 전송되지 않아 강력한 CSRF 방어 효과가 있습니다.
  단, 외부 사이트에서 내 사이트로 링크를 통해 이동하는 정상적인 경우에도 쿠키가 전송되지 않을 수 있습니다.
• SameSite=Lax
  Strict보다는 약간 완화된 설정입니다. 링크 클릭(<a> 태그), GET 메서드 폼 제출 등 안전하다고 판단되는 일부 최상위 레벨 탐색 시에는 다른 사이트에서 시작된 요청이라도 쿠키를 전송합니다.
  대부분의 CSRF 공격(POST, <img> 등)은 막을 수 있으며, 사용자 경험을 크게 해치지 않아 기본값으로 권장되는 경우가 많습니다.
• SameSite=None; Secure
  모든 요청(동일 사이트, 다른 사이트)에 쿠키를 전송합니다. 반드시 Secure 속성(HTTPS에서만 쿠키 전송)과 함께 사용해야 합니다.
  서드파티 컨텍스트에서 쿠키가 필요한 경우(예: 임베디드 콘텐츠 인증)에만 제한적으로 사용해야 합니다.

• Referer 헤더 검증
  요청 헤더의 Referer 값을 확인하여 요청이 허용된 도메인에서 시작되었는지 검사하는 방법입니다.
  하지만 Referer 헤더는 사용자가 비활성화하거나 프록시 등에 의해 누락될 수 있어 완전한 방어책은 아닙니다.
• 커스텀 요청 헤더 사용
  서버에서 특정 커스텀 헤더(예: X-Requested-With)가 포함된 요청만 허용하는 방식입니다.
  브라우저의 동일 출처 정책(Same-Origin Policy) 때문에 다른 도메인에서는 JavaScript로 커스텀 헤더를 추가한 요청을 보내기 어렵다는 점을 이용합니다.
  하지만 CORS 설정이 잘못되어 있다면 우회될 수 있습니다.

Q: "CSRF 공격이란 무엇이고 어떻게 예방할 수 있나요?"

A: 공격 원리, 예방책(CSRF 토큰, SameSite 쿠키)의 원리, 그리고 프론트엔드 개발자의 역할을 함께 설명

• OAuth 2.0
  사용자가 특정 서비스(예: 우리 앱)에게 다른 서비스(예: 구글)에 있는 자신의 정보(예: 프로필, 이메일)에 접근할 수 있도록
  권한을 위임(Delegation)
  하는
  인가(Authorization)
  프레임워크입니다.
  주로 API 접근 권한을 얻는 데 사용됩니다.
• OIDC
  OAuth 2.0 위에 구축된
  인증(Authentication)
  계층입니다.
  사용자가 누구인지 신원을 확인하고 기본적인 프로필 정보를 얻는 데 사용됩니다.

1. 인가 요청 시작
   • 사용자가 '구글 로그인' 버튼 등을 클릭합니다.
   • 프론트엔드는
     code_verifier
     라는 임의의 비밀 문자열을 생성하고, 이를 해시(SHA256 등)하여
     code_challenge
     값을 만듭니다.
   • 구글 인가 서버의 URL로 사용자를 리디렉션 시킵니다. 이때 URL 파라미터에 다음 정보들을 포함합니다.
     • client_id: 사전에 등록된 우리 앱의 식별자.
     • redirect_uri: 인가 코드를 받을 우리 앱의 주소.
     • response_type=code: 인가 코드를 요청함을 의미.
     • scope: 요청할 사용자 정보 범위 (예: openid profile email).
     • code_challenge: 위에서 생성한 해시값.
     • code_challenge_method=S256: 해시 알고리즘 지정.
     • state: CSRF 공격 방지를 위한 임의의 문자열 (선택적이지만 권장).
2. 인가 코드 수신
   • 사용자가 구글에서 로그인 및 권한 동의를 완료하면, 구글 인가 서버는 프론트엔드가 지정한 redirect_uri로 사용자를 다시 리디렉션 시킵니다.
   • 이때 리디렉션 URL의 쿼리 파라미터에
     인가 코드(authorization_code)
     와 함께 아까 보냈던 state 값이 포함되어 돌아옵니다.
   • 프론트엔드는 URL에서 인가 코드와 state 값을 추출합니다. (state 값이 일치하는지 확인하여 CSRF 방어)
3. 토큰 요청 (백엔드 위임 권장)
   • 보안상 중요
     프론트엔드(브라우저)에서 직접 클라이언트 시크릿을 사용하여 토큰을 요청하는 것은 매우 위험합니다.
     따라서 인가 코드를 백엔드 서버(또는 BFF - Backend for Frontend)로 전달하고, 백엔드 서버가 인가 코드를 사용하여 인가 서버로부터
     Access Token
     과
     Refresh Token
     을 받아오는 것이 일반적이고 안전한 방식입니다.
   • 프론트엔드는 추출한 인가 코드를 백엔드 API로 보냅니다. 이때 1단계에서 생성했던
     code_verifier
     값도 함께 보내야 합니다. (백엔드는 이 값과 인가 코드를 인가 서버로 보내 토큰을 요청합니다.)
4. 토큰 수신 및 저장
   • 백엔드 서버는 성공적으로 토큰을 발급받으면, Access Token과 (필요하다면) Refresh Token을 프론트엔드에게 전달해 줍니다.
   • 프론트엔드는 이 토큰들을 안전하게 저장해야 합니다.
     • Access Token
       : 보통 만료 시간이 짧으며, API 요청 시 사용됩니다. 메모리(JavaScript 변수)에 저장하는 것이 비교적 안전합니다. LocalStorage나 SessionStorage는 XSS 공격에 취약할 수 있습니다.
     • Refresh Token
       : 만료 시간이 길며, Access Token이 만료되었을 때 새 Access Token을 발급받는 데 사용됩니다. 보안상 매우 민감하므로, 가능하다면 서버 측 세션과 연결된 HttpOnly, Secure, SameSite=Strict (또는 Lax) 속성의 쿠키에 저장하여 프론트엔드 JavaScript가 직접 접근할 수 없도록 하는 것이 가장 안전합니다. 이것이 어렵다면 메모리에 저장하고 다른 보안 수단을 강구해야 합니다.
5. API 요청 시 토큰 사용
   • 보호된 API를 호출할 때마다 프론트엔드는 저장된 Access Token을 HTTP 요청 헤더의 Authorization 필드에 담아 보냅니다 (예: Authorization: Bearer YOUR_ACCESS_TOKEN).
6. 토큰 갱신
   • API 요청 시 Access Token이 만료되었다는 응답(예: 401 Unauthorized)을 받으면, 프론트엔드는 (HttpOnly 쿠키에 저장된 경우 브라우저가 자동으로 보내거나, 메모리에 저장된 경우 직접) Refresh Token을 사용하여 백엔드에게 새 Access Token 발급을 요청합니다. 백엔드가 새 토큰을 발급해주면 이를 다시 저장하고 실패했던 API 요청을 재시도합니다.
7. 로그아웃
   • 프론트엔드는 저장된 토큰(메모리, 쿠키 등)을 삭제합니다.
   • 필요하다면, 인가 서버의 로그아웃 엔드포인트로 사용자를 리디렉션하여 외부 서비스에서도 로그아웃 처리를 완료합니다.

OAuth 2.0 인가 코드 플로우

// Zustand 스토어 예시
import create from 'zustand';
interface AuthState {
  accessToken: string | null;
  setAccessToken: (token: string | null) => void;
}
const useAuthStore = create<AuthState>((set) => ({
  accessToken: null,
  setAccessToken: (token) => set({ accessToken: token }),
}));
 
// 로그인 성공 후 토큰 저장
// const { setAccessToken } = useAuthStore.getState();
// setAccessToken(receivedAccessToken);
 
// API 요청 시 토큰 사용
// const accessToken = useAuthStore((state) => state.accessToken);
// axios.get('/api/protected', { headers: { Authorization: `Bearer ${accessToken}` } });

• 프론트엔드의 역할
  : 프론트엔드는 이 쿠키를 직접 읽거나 관리할 필요가 없습니다. Access Token 만료 시, 백엔드의 특정 토큰 갱신 엔드포인트(예: /api/refresh_token)를 호출하기만 하면 됩니다. 브라우저는 해당 엔드포인트로 요청을 보낼 때 자동으로 HttpOnly 쿠키(Refresh Token 포함)를 함께 전송합니다. 백엔드는 이 쿠키를 읽어 새 Access Token을 발급하고 응답으로 보내줍니다.
• 서버 측 쿠키 설정 예시 (Node.js/Express)

  // 백엔드에서 로그인 성공 또는 토큰 발급 시
  res.cookie('refreshToken', receivedRefreshToken, {
    httpOnly: true, // JavaScript 접근 불가
    secure: true, // HTTPS에서만 전송
    sameSite: 'lax', // 또는 'strict'
    maxAge: 7 * 24 * 60 * 60 * 1000 // 예: 7일 유효기간
  });
  res.json({ accessToken: receivedAccessToken }); // Access Token은 JSON 응답으로 전달

Q: "OAuth 2.0 인가 코드 플로우에서 프론트엔드의 역할은 무엇인가요?" 또는 "Access Token은 어디에 저장하는 것이 안전할까요?"

A: 플로우 각 단계별 역할과 토큰 저장소별 보안 고려사항(LocalStorage의 XSS 취약점, HttpOnly 쿠키의 CSRF 방어 이점 등)을 명확히 설명

• 성능 저하
  : 외부 서버 응답 지연이나 스크립트 자체의 크기, 실행 시간 때문에 우리 애플리케이션의 로딩 속도나 반응성이 저하될 수 있습니다.
• 보안 취약점 (공급망 공격)
  : 해당 서드파티 서비스가 해킹당하거나 악의적인 코드가 삽입되면, 우리 애플리케이션을 통해 사용자를 공격하는 통로가 될 수 있습니다.
• 서비스 장애
  : 서드파티 서비스 자체가 중단되거나 오류가 발생하면, 우리 애플리케이션의 기능이 마비되거나 오류가 발생할 수 있습니다.

• 정기적인 의존성 검토 및 업데이트
  npm audit, Snyk, Dependabot 같은 도구를 사용하여 알려진 보안 취약점이 있는 라이브러리를 확인하고 주기적으로 업데이트합니다. 불필요한 의존성은 제거합니다.
• 서드파티 스크립트 로딩 제어
  :
  HTML <script> 태그에 async 또는 defer 속성을 사용하여 페이지 렌더링을 막지 않도록 합니다.
  정말 필요한 시점에만 스크립트를 동적으로 로드하는 방안을 고려합니다.
• Subresource Integrity (SRI)
  CDN 등 외부 서버에서 스크립트나 스타일시트를 로드할 때, 해당 리소스의 해시 값을 미리 <script> 나 <link> 태그의 integrity 속성에 명시하는 방법입니다.
  브라우저는 리소스를 다운로드한 후 해시 값을 비교하여, 만약 파일 내용이 변경되었다면 로드를 차단합니다.

  <script src="https://example.com/library.js"
          integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8w/"
          crossorigin="anonymous"></script>

• 콘텐츠 보안 정책 (CSP)
  신뢰할 수 있는 출처의 스크립트만 로드하도록 CSP 헤더를 엄격하게 설정하여 예상치 못한 서드파티 스크립트 실행을 차단합니다.
• 성능 및 오류 모니터링
  Lighthouse, WebPageTest 같은 도구로 정기적인 성능 측정을 하고, Sentry, Datadog 같은 오류 모니터링 서비스를 사용하여 서드파티 스크립트로 인한 성능 문제나 오류를 감지하고 대응합니다.

• XSS
  공격은 사용자 입력을 안전하게 처리(자동 이스케이핑, 입력 정제)하고 CSP를 설정하여 예방해야 합니다. dangerouslySetInnerHTML 사용은 극도로 주의해야 합니다.
• CSRF
  공격은 예측 불가능한 토큰(CSRF 토큰)을 사용하거나 SameSite 쿠키 속성을 활용하여 서버와 클라이언트가 함께 방어해야 합니다.
• OAuth 2.0/OIDC
  는 안전한 인증/인가를 위한 표준 프로토콜이며, 프론트엔드는 사용자를 인가 서버로 안내하고 토큰을 안전하게 관리하는 역할을 수행합니다. 특히 SPA에서는 PKCE를 포함한 인가 코드 플로우가 권장됩니다.
• 코드 스플리팅
  은 성능 외에 오류 격리에도 일부 도움이 될 수 있으며,
  서드파티 스크립트
  는 편리하지만 성능, 보안, 안정성 측면의 위험을 내포하므로 신중한 관리와 감시가 필요합니다. SRI, CSP 등이 도움이 됩니다.

다음 시간에는 React 개발 생산성과 코드 품질을 높여주는

개발자 도구와 테스트

방법에 대해 알아보겠습니다. React DevTools부터 테스트 라이브러리(Jest, React Testing Library), Storybook까지 다양한 도구들을 살펴보겠습니다.

• OWASP Top 10 (웹 애플리케이션 보안 위협): https://owasp.org/www-project-top-ten/↗ (XSS, CSRF 등 포함)
• MDN Web Docs - 콘텐츠 보안 정책 (CSP): https://developer.mozilla.org/ko/docs/Web/HTTP/CSP↗
• MDN Web Docs - SameSite 쿠키: https://developer.mozilla.org/ko/docs/Web/HTTP/Headers/Set-Cookie/SameSite↗
• OAuth 2.0 공식 웹사이트: https://oauth.net/2/↗
• OpenID Connect (OIDC) 공식 웹사이트: https://openid.net/connect/↗
• MDN Web Docs - Subresource Integrity (SRI): https://developer.mozilla.org/ko/docs/Web/Security/Subresource_Integrity↗