단일 페이지 애플리케이션(SPA) 보안은 웹사이트와 동일하게 작동하지 않습니다

SPA(단일 페이지 애플리케이션)는 디지털 데이터 전달 및 고객 참여를 위한 개발하기 쉬운 인터페이스로서 빠르게 강력한 입지를 확보하고 있습니다.

단일 페이지 애플리케이션(SPA)은 개발 용이성과 매력적인 사용자 경험을 제공하는 기능으로 인해 점점 인기가 높아지고 있습니다. 그러나 SPA에는 고유한 보안 문제도 있습니다. 이 글에서는 SPA 보안의 어려움을 살펴보고 토큰 핸들러 패턴으로 알려진 유망한 솔루션에 대해 논의하겠습니다.

기존 웹사이트에는 HTML과 데이터를 제공하는 단일 백엔드가 있습니다. 사용자 인증은 일반적으로 네트워크 방화벽으로 보호되는 이 백엔드 서버에서 발생합니다. 그러나 SPA는 API를 통해 여러 마이크로서비스에 연결되므로 더욱 분산된 아키텍처가 생성됩니다. 이 설정은 SPA에 가벼운 이점을 제공하지만 상당한 보안 위험도 초래합니다.

주요 과제 중 하나는 사용자 인증이 네트워크 방화벽 뒤의 보호된 서버에서 발생하는 대신 브라우저에서 자주 발생해야 한다는 것입니다. 이로 인해 SPA는 XSS(교차 사이트 스크립팅) 자격 증명 도용과 같은 광범위한 사이버 공격 유형에 취약해집니다. 이 공격 방법에서 악의적인 행위자는 액세스 토큰과 사용자 자격 증명을 훔칠 수 있는 코드를 브라우저에 삽입하여 궁극적으로 중요한 데이터와 시스템에 대한 무단 액세스 권한을 부여할 수 있습니다.

또 다른 문제는 일반적으로 API를 통해 애플리케이션에 연결되는 타사 데이터에 대한 많은 종속성으로 인해 발생합니다. 대량의 타사 연결로 인해 두 가지 문제가 발생할 수 있습니다.

첫째, 개발자는 다른 실무자 및 조직이 만든 API에 내장된 보안을 제어할 수 없습니다. 이로 인해 개발자가 모르는 사이에 애플리케이션에 취약점이 도입될 수 있습니다.

둘째, 이 복잡하고 다양한 환경에서 프로그래밍하는 것은 관련된 많은 양의 상세하고 사용자 정의된 코드와 입력 설정으로 인해 지루할 수 있습니다. 중요한 단계를 놓치고 무의식적으로 보안 허점을 만들기 쉽습니다. 또한 환경이 성장하고 시간이 지남에 따라 변화하는 비즈니스 요구에 적응함에 따라 숨겨진 보안 위험이 도입될 수 있습니다.

문제를 더 자세히 설명하기 위해 웹사이트와 SPA 보안 설정을 비교해 보겠습니다.

웹사이트 보안에서 개발자는 쿠키 기반 세션을 사용하여 사용자에게 웹 애플리케이션에 대한 액세스 권한을 부여할 수 있습니다. 프런트엔드 웹사이트 클라이언트는 모든 사용자 액세스 요청과 함께 단일 백엔드 데이터 서버로 전송되는 쿠키를 브라우저에 저장합니다. 인증 결정은 스토리지에 보관된 세션 데이터를 기반으로 이루어질 수 있으므로 사용자 액세스는 네트워크 방화벽 뒤에서 안전하게 유지됩니다.

단일 페이지 애플리케이션에는 전용 백엔드가 없기 때문에 SPA에는 이 설정이 불가능합니다. CDN(콘텐츠 전송 네트워크)은 정적 파일을 통해 SPA에 코드를 제공하는 경우가 많습니다. 이러한 파일은 애플리케이션에 대한 API 호출을 통해 반환됩니다. SPA 구성에서는 백엔드 데이터 저장소가 없기 때문에 사용자 세션을 쿠키에 보관할 수 없습니다. 대신 액세스 토큰을 사용하여 인증된 사용자를 대신하여 API를 호출할 수 있습니다.

SPA 보안 취약점

SPA 보안 문제는 브라우저 기반 인증이 광범위한 사이버 공격 유형에 취약하다는 사실에 달려 있습니다. 위협 유형 중 하나는 XSS(교차 사이트 스크립팅) 자격 증명 도용입니다. 이 공격 방법에서는 악의적인 행위자가 액세스 토큰과 사용자 자격 증명을 훔칠 수 있는 코드를 브라우저에 삽입하여 귀중한 데이터와 시스템에 대한 무단 액세스 권한을 얻습니다.

XSS는 일반적인 취약점이지만 개발자가 방어해야 하는 유일한 취약점은 아닙니다. 문제를 더욱 어렵게 만드는 것은 하나의 취약점을 해결하면 새로운 취약점이 열리는 경우가 많기 때문에 SPA 보안을 목표를 바꾸는 끝없는 게임으로 만드는 것입니다. 예를 들어 OAuth 흐름을 사용하여 세션 쿠키 대신 OAuth 토큰으로 사용자 또는 API 액세스를 인증하는 것은 XSS 공격을 완화하는 좋은 방법처럼 보입니다.

그러나 이러한 토큰이 로컬 저장소에 저장되어 있으면 위협 행위자는 로컬 및 세션 저장소에 쉽게 접근하여 토큰을 유출할 수 있습니다. 토큰을 새로 고칠 수 있으면 사용자 세션이 종료된 후에도 공격자가 액세스 권한을 얻을 수 있으므로 문제는 더욱 악화됩니다.

보안 수정과 함께 발생할 수 있는 의도하지 않은 문제의 또 다른 예는 콘텐츠 보안 정책(CSP) 헤더에 강력한 보안 정책을 구축하는 것입니다. 이를 통해 또 다른 보안 제어 계층이 추가될 수 있지만 일부 소스에서는 콘텐츠 보안 정책을 열고 비활성화할 수 있습니다.

결론은 데이터 및 시스템에 대한 무단 및 악의적인 액세스를 방어하는 데 있어서 브라우저는 적대적인 환경이라는 것입니다. 모든 보안 조치에는 하나의 공격 경로를 닫아도 다른 공격 경로가 열리지 않도록 주의 깊은 테스트와 지속적인 경계가 필요합니다.

쿠키와 토큰 모두 사용

악의적인 행위자로부터 사용자 인증을 보호하기 위해 최근 개발된 SPA를 보호하는 방법 중 하나는 웹사이트 쿠키 보안과 액세스 토큰을 병합하는 토큰 핸들러 패턴입니다. 브라우저에서 인증을 제거하고 동일 사이트 쿠키 및 토큰을 사용하여 BFF(백엔드-프런트엔드) 구성을 활용하는 토큰 처리기 아키텍처를 구현함으로써 조직은 보안을 희생하지 않고도 SPA의 가벼운 측면의 이점을 누릴 수 있습니다.

이 설정에서는 백엔드 구성 요소로 호스팅되는 OAuth 에이전트가 SPA와 인증 서버 사이에 위치합니다. OAuth 에이전트는 SPA에 대한 OAuth 흐름을 처리하고 SPA가 토큰을 발급하는 대신 SPA가 백엔드 API 및 마이크로서비스에 액세스하는 데 사용할 수 있는 보안 HTTP 전용 쿠키가 발급됩니다.

고성능 API 게이트웨이에서 호스팅되는 OAuth 프록시

위 내용은 단일 페이지 애플리케이션(SPA) 보안은 웹사이트와 동일하게 작동하지 않습니다의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!