ASP.NET Core Blazor 정적 서버 쪽 렌더링에 대한 위협 완화 지침

  • 아티클

이 문서에서는 정적 서버 쪽 렌더링을 사용하여 Web Apps를 Blazor 개발할 때 개발자가 고려해야 하는 보안 고려 사항을 설명합니다.

Blazor 는 대화형 웹앱을 작성하기 위해 서로 다른 세 가지 모델을 하나로 결합합니다. HTTP를 기반으로 하는 요청/응답 모델인 기존 서버 쪽 렌더링입니다. 를 기반으로 SignalR하는 렌더링 모델인 대화형 서버 쪽 렌더링입니다. 마지막으로 WebAssembly를 기반으로 하는 렌더링 모델인 클라이언트 쪽 렌더링입니다.

지원되는 렌더링 모드 중 하나에서 대화형 구성 요소 렌더링이 있는 경우 대화형 렌더링 모드에 대해 정의된 모든 일반 보안 고려 사항이 Web Apps에 적용 Blazor 됩니다. 다음 섹션에서는 Web Apps의 비대화형 서버 쪽 렌더링 Blazor 과 관련된 보안 고려 사항 및 렌더링 모드가 서로 상호 작용할 때 적용되는 특정 측면을 설명합니다.

서버 쪽 렌더링에 대한 일반적인 고려 사항

SSR(서버 쪽 렌더링) 모델은 HTTP의 기존 요청/응답 모델을 기반으로 합니다. 따라서 SSR과 요청/응답 HTTP 사이에는 공통적인 문제가 있습니다. 일반적인 보안 고려 사항 및 특정 위협을 성공적으로 완화해야 합니다. 프레임워크는 이러한 위협 중 일부를 관리하기 위한 기본 제공 메커니즘을 제공하지만 다른 위협은 앱 코드와 관련이 있으며 앱에서 처리해야 합니다. 이러한 위협은 다음과 같이 분류할 수 있습니다.

  • 인증 및 권한 부여: 앱은 사용자가 앱 및 앱이 노출하는 리소스에 액세스할 수 있도록 인증되고 권한이 부여되었는지 확인해야 합니다. 프레임워크는 인증 및 권한 부여를 위한 기본 제공 메커니즘을 제공하지만, 앱은 메커니즘이 제대로 구성되고 사용되는지 확인해야 합니다. 인증 및 권한 부여를 위한 기본 제공 메커니즘은 설명서의 서버 보안 노드 및 ASP.NET Core 설명서의 보안 및 Identity 노드에서 다루 Blazor 므로 여기서는 다루지 않습니다.

  • 입력 유효성 검사 및 삭제: 사용하기 전에 클라이언트에서 도착하는 모든 입력의 유효성을 검사하고 삭제해야 합니다. 그렇지 않으면 앱이 SQL 삽입, 사이트 간 스크립팅, 교차 사이트 요청 위조, 열린 리디렉션 및 기타 형태의 공격과 같은 공격에 노출될 수 있습니다. 입력은 요청의 어디에서나 올 수 있습니다.

  • 세션 관리: 사용자 세션을 적절하게 관리하는 것은 앱이 세션 고정, 세션 하이재킹 및 기타 공격과 같은 공격에 노출되지 않도록 하는 데 중요합니다. 세션에 저장된 정보는 제대로 보호되고 암호화되어야 하며, 앱의 코드는 악의적인 사용자가 세션을 추측하거나 조작하지 못하도록 해야 합니다.

  • 오류 처리 및 로깅: 앱은 오류를 올바르게 처리하고 기록해야 합니다. 그렇지 않으면 앱이 정보 공개와 같은 공격에 노출될 수 있습니다. 이는 앱이 응답에서 중요한 정보를 반환하거나 앱이 앱을 공격하는 데 사용할 수 있는 데이터와 함께 자세한 오류 메시지를 반환할 때 발생할 수 있습니다.

  • 데이터 보호: 쉽게 리버스 엔지니어링할 수 있으므로 WebAssembly에서 실행할 때 앱 논리를 포함하는 중요한 데이터를 적절하게 보호해야 합니다.

  • 서비스 거부: 앱은 서비스 거부와 같은 공격에 노출되지 않도록 해야 합니다. 예를 들어 무차별 암호 대입 공격으로부터 앱이 제대로 보호되지 않거나 동작으로 인해 앱이 너무 많은 리소스를 사용할 수 있는 경우에 발생합니다.

입력 유효성 검사 및 삭제

CSRF 토큰, 인증 cookie, 세션 식별자 또는 인증된 암호화로 보호되는 다른 페이로드와 같은 정보가 서버에서 생성되고 보호되지 않는 한 클라이언트에서 도착하는 모든 입력은 신뢰할 수 없는 것으로 간주되어야 합니다.

입력은 일반적으로 바인딩 프로세스를 통해(예: 특성 또는 [SupplyParameterFromForm] 특성을 통해) 앱에서 [SupplyParameterFromQuery] 사용할 수 있습니다. 이 입력을 처리하기 전에 앱은 데이터가 유효한지 확인해야 합니다. 예를 들어 앱은 양식 데이터를 구성 요소 속성에 매핑할 때 바인딩 오류가 없는지 확인해야 합니다. 그렇지 않으면 앱이 잘못된 데이터를 처리할 수 있습니다.

입력을 사용하여 리디렉션을 수행하는 경우 앱은 입력이 유효하고 잘못된 것으로 간주되거나 앱 기본 경로 내의 잘못된 하위 경로를 가리키지 않는지 확인해야 합니다기본. 그렇지 않으면 공격자가 사용자를 악성 사이트로 리디렉션하는 링크를 만들 수 있는 공개 리디렉션 공격에 앱이 노출될 수 있습니다.

입력을 사용하여 데이터베이스 쿼리를 수행하는 경우 앱은 입력이 유효하고 SQL 삽입 공격에 앱을 노출하지 않는지 확인해야 합니다. 그렇지 않으면 공격자가 데이터베이스에서 정보를 추출하거나 데이터베이스를 수정하는 데 사용할 수 있는 악의적인 쿼리를 만들 수 있습니다.

사용자 입력에서 나온 데이터도 응답에 포함하기 전에 삭제해야 합니다. 예를 들어 입력에는 사용자로부터 정보를 추출하거나 사용자를 대신하여 작업을 수행하는 데 사용할 수 있는 사이트 간 스크립팅 공격을 수행하는 데 사용할 수 있는 HTML 또는 JavaScript가 포함될 수 있습니다.

프레임워크는 입력 유효성 검사 및 삭제에 도움이 되는 다음과 같은 메커니즘을 제공합니다.

  • 모든 바인딩된 양식 데이터는 기본 정확성에 대한 유효성을 검사합니다. 입력을 구문 분석할 수 없는 경우 바인딩 프로세스는 데이터를 사용하여 작업을 수행하기 전에 앱에서 검색할 수 있는 오류를 보고합니다. 기본 제공 EditForm 구성 요소는 양식 콜백을 호출하기 전에 이를 고려합니다 OnValidSubmit . Blazor 에서는 하나 이상의 바인딩 오류가 있는 경우 콜백을 실행하지 않습니다.
  • 프레임워크는 위조 방지 토큰을 사용하여 교차 사이트 요청 위조 공격으로부터 보호합니다. 자세한 내용은 ASP.NET Core Blazor 인증 및 권한 부여 및 ASP.NET Core Blazor 양식 개요를 참조하세요.

지정된 작업을 수행할 때 서버에서 모든 입력 및 권한의 유효성을 검사하여 해당 시점에 데이터가 유효하고 정확한지, 사용자가 작업을 수행할 수 있는지 확인해야 합니다. 이 방법은 대화형 서버 쪽 렌더링에 제공된 보안 지침과 일치합니다.

세션 관리

세션 관리는 프레임워크에서 처리됩니다. 프레임워크는 세션을 cookie 사용하여 사용자 세션을 식별합니다. 세션 cookie 은 ASP.NET Core Data Protection API를 사용하여 보호됩니다. 세션 cookie 은 브라우저에서 실행되는 JavaScript 코드에 액세스할 수 없으며 사용자가 쉽게 추측하거나 조작할 수 없습니다.

서비스 내에 저장된 데이터와 같은 다른 세션 데이터와 관련하여 지정된 프로세스 인스턴스의 모든 사용자 세션에서 공유되는 싱글톤 서비스와 달리 범위가 지정된 서비스는 지정된 사용자 세션마다 고유하므로 세션 데이터는 범위가 지정된 서비스 내에 저장되어야 합니다.

SSR의 경우 서비스의 수명이 단일 요청으로 제한되므로 대부분의 경우 범위가 지정된 서비스와 일시적 서비스 간에 큰 차이가 없습니다. 두 가지 시나리오에는 차이가 있습니다.

  • 서비스가 요청 중에 둘 이상의 위치 또는 다른 시간에 삽입되는 경우.
  • 서비스가 대화형 서버 컨텍스트에서 사용될 수 있는 경우 여러 렌더링이 유지되고 서비스의 범위가 사용자 세션으로 범위가 지정된다는 기본 사항이 유지됩니다.

오류 처리 및 로깅

프레임워크는 프레임워크 수준에서 앱에 대한 기본 제공 로깅을 제공합니다. 프레임워크는 양식에 대한 위조 방지 토큰의 유효성을 검사하지 못하는 경우, 루트 구성 요소가 렌더링되기 시작할 때 및 작업이 디스패치되는 경우와 같은 중요한 이벤트를 기록합니다. 앱은 기록하는 데 중요할 수 있는 다른 이벤트를 로깅해야 합니다.

프레임워크는 프레임워크 수준에서 앱에 대한 기본 제공 오류 처리를 제공합니다. 프레임워크는 구성 요소를 렌더링하는 동안 발생하는 오류를 처리하고 오류 경계 메커니즘을 사용하여 친숙한 오류 메시지를 표시하거나 오류 페이지를 렌더링하도록 구성된 예외 처리 미들웨어까지 오류가 버블링되도록 허용합니다.

응답이 클라이언트로 전송되기 시작한 후 스트리밍 렌더링 중에 발생하는 오류는 최종 응답에 일반 오류 메시지로 표시됩니다. 오류의 원인에 대한 세부 정보는 개발 중에만 포함됩니다.

데이터 보호

프레임워크는 지정된 사용자 세션에 대한 중요한 정보를 보호하기 위한 메커니즘을 제공하고 기본 제공 구성 요소가 이러한 메커니즘을 사용하여 인증을 사용할 cookie 때 사용자 ID 보호와 같은 중요한 정보를 보호하도록 합니다. 프레임워크에서 처리하는 시나리오 외에 개발자 코드는 다른 앱 관련 정보를 보호할 책임이 있습니다. 이 작업을 수행하는 가장 일반적인 방법은 ASP.NET Core Data Protection API 또는 다른 형태의 암호화를 사용하는 것입니다. 일반적으로 앱은 다음을 담당합니다.

  • 사용자가 다른 사용자의 개인 정보를 검사하거나 수정할 수 없도록 합니다.
  • 사용자가 내부 식별자와 같은 다른 사용자의 사용자 데이터를 수정할 수 없도록 합니다.

데이터 보호와 관련하여 코드가 실행되는 위치를 명확하게 이해해야 합니다. 정적 서버 쪽 렌더링(정적 SSR) 및 대화형 SSR(대화형 서버 쪽 렌더링)의 경우 코드는 서버에 저장되고 클라이언트에 도달하지 않습니다. 대화형 WebAssembly 렌더링 모드의 경우 앱 코드 는 항상 클라이언트에 도달합니다. 즉, 앱 코드에 저장된 중요한 정보를 앱에 액세스할 수 있는 모든 사용자가 사용할 수 있습니다. 난독 처리 및 코드를 "보호"하는 다른 유사한 기술은 효과적이지 않습니다. 코드가 클라이언트에 도달하면 중요한 정보를 추출하도록 리버스 엔지니어링할 수 있습니다.

서비스 거부

서버 수준에서 프레임워크는 요청의 최대 크기 및 헤더 크기와 같은 요청/응답 매개 변수에 대한 제한을 제공합니다. 앱 코드 Blazor와 관련하여 양식 매핑 시스템은 MVC의 모델 바인딩 시스템에서 정의한 것과 유사한 제한을 정의합니다.

  • 최대 오류 수를 제한합니다.
  • 바인더의 최대 재귀 깊이를 제한합니다.
  • 컬렉션에 바인딩된 최대 요소 수를 제한합니다.

또한 최대 폼 키 크기, 값 크기 및 최대 항목 수와 같은 폼에 대해 정의된 제한이 있습니다.

일반적으로 앱은 요청이 서버에서 비대칭 작업량을 트리거할 가능성이 있는 경우 평가해야 합니다. 예를 들어 사용자가 N으로 매개 변수가 있는 요청을 보내고 서버가 N배의 비용이 드는 응답으로 작업을 수행하는 경우를 들 수 있습니다. 여기서 N은 사용자가 제어하고 무기한 증가할 수 있는 매개 변수입니다. 일반적으로 앱은 처리할 최대 N에 제한을 적용하거나 상수 요소에 의한 요청보다 작업이 더 적거나 같거나 비용이 더 많이 드는지 확인해야 합니다.

이러한 측면은 특정 1→N 비교보다 클라이언트가 수행하는 작업과 서버가 수행하는 작업 간의 증가 차이와 관련이 있습니다. 예를 들어 클라이언트는 N 단위의 작업을 수행하는 데 시간이 걸리는 작업 항목(목록에 요소 삽입)을 제출할 수 있지만 서버는 N^2^이(가) 처리해야 합니다(매우 순진한 작업을 수행할 수 있기 때문). N과 N^2^의 차이점이 중요합니다.

따라서 서버에서 수행해야 하는 작업 수에 제한이 있으며 이는 앱과 관련이 있습니다. 이 측면은 리소스가 서버에 있기 때문에 서버 쪽 워크로드에 적용되지만 대부분의 경우 클라이언트의 WebAssembly 워크로드에 반드시 적용되는 것은 아닙니다.

다른 중요한 측면은 CPU 시간에만 예약되지 않는다는 것입니다. 디스크의 메모리, 네트워크 및 공간과 같은 모든 리소스에도 적용됩니다.

WebAssembly 워크로드의 경우 클라이언트가 일반적으로 클라이언트에서 사용할 수 있는 리소스에 의해 제한되기 때문에 클라이언트가 수행하는 작업량에 대한 우려는 거의 없습니다. 그러나 클라이언트가 영향을 받을 수 있는 몇 가지 시나리오가 있습니다. 예를 들어 앱이 다른 사용자의 데이터를 표시하고 한 사용자가 데이터를 표시하는 클라이언트가 사용자가 추가한 데이터 양에 비례하지 않는 작업을 수행하도록 강제하는 데이터를 시스템에 추가할 수 있는 경우입니다.

  • 사용자가 앱 및 앱이 노출하는 리소스에 액세스할 수 있는 인증 및 권한이 있는지 확인합니다.
  • 클라이언트를 사용하기 전에 클라이언트에서 들어오는 모든 입력의 유효성을 검사하고 삭제합니다.
  • 사용자 세션을 적절하게 관리하여 상태가 사용자 간에 실수로 공유되지 않도록 합니다.
  • 중요한 정보가 노출되는 것을 방지하기 위해 오류를 올바르게 처리하고 기록합니다.
  • 앱에서 중요한 이벤트를 기록하여 잠재적인 문제를 식별하고 사용자가 수행한 작업을 감사합니다.
  • ASP.NET Core Data Protection API 또는 사용 가능한 구성 요소 중 하나(Microsoft.AspNetCore.Components.Server.ProtectedBrowserStorage, PersistentComponentState)를 사용하여 중요한 정보를 보호합니다.
  • 앱이 지정된 요청에서 사용할 수 있는 리소스를 이해하고 서비스 거부 공격을 방지하기 위한 제한이 있는지 확인합니다.