대부분의 웹 응용 프로그램은 일반적으로 쿠키에 저장되고 서버와 웹 브라우저 사이에서 투명하게 전송되는 세션 ID를 사용하여 사용자를 고유하게 식별합니다.


이 속성의 값이 true 또는 UseUri로 설정된 경우 응용 프로그램은 브라우저 또는 장치가 쿠키를 지원하는지 여부와 관계없이 쿠키를 사용하지 않습니다. 이 속성의 값이 AutoDetect 또는 UseDeviceProfile로 설정된 경우 요청 브라우저 또는 장치의 구성에 따라 쿠키가 사용되지 않습니다.

쿠키에 세션 ID를 저장하지 않은 응용 프로그램은 때때로 HTTP 요청 매개변수 또는 URL의 일부로서 세션 ID를 전송합니다. URL에 지정된 세션 ID를 수락하면 공격자가 Session Fixation 공격을 손쉽게 수행할 수 있습니다.

세션 ID를 URL에 배치하면 응용 프로그램에 대한 세션 하이재킹(Session Hijacking) 공격이 성공할 가능성도 높아집니다. 세션 하이재킹(Session Hijacking)은 공격자가 피해자의 활성 세션 또는 세션 ID 제어권을 가져갈 때 발생합니다. 일반적으로 웹 서버, 응용 프로그램 서버 및 웹 프록시는 요청된 URL을 저장합니다. 세션 ID가 URL에 포함되면 ID가 기록됩니다. 세션 ID를 보고 저장할 수 있는 장소의 수가 증가하면 공격자에 의해 손상될 기회가 증가합니다.

추적 디버깅 정보를 출력하도록 ASP.NET 응용 프로그램을 구성할 수 있습니다. Trace output에는 페이지와 활성 세션 상태에 사용된 현재 페이지, 헤더 정보, 메서드 및 제어 관련 요청에 대한 자세한 정보가 있습니다. 공격자는 trace output에서 얻은 자세한 정보를 이용하여 응용 프로그램이 사용하는 프레임워크, 데이터베이스 또는 기타 리소스를 공격할 수 있습니다.

추적 정보는 <page> 지시문의 Trace 속성을 true로 설정하여 페이지 수준에서 활성화되거나 web.config 파일에 trace 속성을 추가하고 enabled 속성을 true로 설정하여 응용 프로그램 수준에서 활성화됩니다.

안전하지 않은 HTTP 헤더 처리는useUnsafeHeaderParsing 속성을 true로 설정하여 존재합니다. 이 설정을 사용하면 HTTP 헤더에 대한 유효성 검사 규칙이 충분하지 않기 때문에 취약한 응용 프로그램에 대한 공격이 가능해집니다.

이 속성이 true로 설정된 경우 다음 유효성 검사가 수행되지 않습니다.

- 줄 끝 코드에는 CRLF를 사용합니다. 별도의 CR 또는 LF는 허용되지 않습니다.
- 헤더 이름에는 공백이 없습니다.
- 첫 번째 상태 줄을 제외한 모든 줄은 잘못된 헤더 이름/값 쌍으로 해석됩니다.
- 상태 줄에는 코드와 설명이 포함되어야 합니다.

또한 이 설정은 금지된 문자와 관련된 특정 예외가 더 이상 발생하지 않음을 의미합니다.

예제 1: 다음 예에서, useUnsafeHeaderParsing이 true로 설정됩니다.

...
<configuration>
   <system.net>
   <settings>
      <httpWebRequest useUnsafeHeaderParsing="true" />
   </settings>
   </system.net>
</configuration>
...

가장 자격 증명을 사용하면 실행 중인 클라이언트의 권한 또는 구성에서 부여된 임의의 권한으로 ASP.NET 응용 프로그램이 실행할 수 있습니다.

ASP.NET에서 보기 상태는 전체 포스트백에서 웹 폼으로 상태를 유지하는 메커니즘입니다. 보기 상태에 저장된 데이터는 재전송 공격을 방지하기 위한 메커니즘이 없기 때문에 신뢰할 수 없습니다. 보기 상태를 신뢰하는 것은 보기 상태 MAC(메시지 인증 확인)가 비활성화되었을 때 특히 위험합니다. MAC을 비활성화하면 공격자는 보기 상태에서 저장된 데이터를 임의로 변경할 수 있으며 보기 상태를 신뢰하는 코드에 대한 공격의 문을 열 수 있습니다. 공격자는 이러한 종류의 오류를 사용하여 MAC을 방어하거나 항목 가격을 수정할 수도 있습니다.
예제 1: 다음 코드는 보기 상태 MAC(메시지 인증 확인)를 비활성화합니다.

Page.EnableViewStateMac = false;

ASP.NET 응용 프로그램은 ASP.NET 응용 프로그램의 web.config 파일에 있는 <credentials> 요소에 사용자 이름과 암호 쌍을 저장할 수 있습니다. ASP.NET 응용 프로그램은 일반 텍스트, MD5 및 SHA1 암호 형식을 지원합니다.

일반 텍스트로 저장된 암호 또는 약한 암호화 알고리즘을 사용하는 암호는 응용 프로그램의 구성 파일에 액세스할 수 있는 모든 사람이 액세스할 수 있습니다. 여기에는 응용 프로그램이 호스팅되는 시스템 또는 응용 프로그램이 있는 소스 코드 리포지토리가 포함될 수 있습니다.

예제 1: 다음 web.config 항목은 암호를 일반 텍스트로 잘못 저장합니다.

<configuration>
  <system.web>
    <authentication>
      <forms protection="All">
	   <credentials passwordFormat="Clear">
   		<user name="user1" password="my_password"/>
		<user name="user2" password="my_password1"/>
        </credentials>
    	 </forms>
    </authentication>
  </system.web>
</configuration>

ASP.NET은 configuration/system.web/authentication/forms/credentials 요소의 passwordFormat 속성으로 지정되는 3가지 형식으로 저장된 자격 증명 암호를 지원합니다. 이 속성의 가능한 값은 다음과 같습니다.

Clear - 암호가 일반 텍스트로 저장되었음을 나타냄(최소 보안)
MD5 - 암호의 MD5 해시가 저장되었음을 나타냄
SHA1- 암호의 SHA1 해시가 저장되었음을 나타냅니다(최고 보안).

MD5 해시는 일반 텍스트보다 안전하지만 연구원들은 MD5 해시 알고리즘에 대한 무차별 대입 공격을 발견했습니다. 이런 경우더라도 SHA1 해시는 그러한 공격에 대해 적절한 보호를 제공합니다.

쓰기, 업데이트 또는 삭제를 통해 데이터를 수정하는 ASP.NET MVC 컨트롤러 작업은 다음 HTTP 동사 중 하나만 수락하도록 제한하는 것이 좋을 수 있습니다. Post, Put, Patch 또는 Delete. 이렇게 하면 실수로 링크를 클릭해도 작업이 실행되지 않으므로 교차 사이트 요청 위조가 어려워집니다.

다음 컨트롤러 작업은 기본적으로 모든 verb를 허용하므로 cross-site request forgery에 취약할 수 있습니다.

public ActionResult UpdateWidget(Model model)
{
  // ... controller logic
}

ASP.NET MVC는 폼 측에 antiforgery 토큰을 추가하고 컨트롤러에서 이 antiforgery 토큰을 확인하여 cross-site request forgery로부터 응용 프로그램을 보다 효율적으로 보호하는 편리한 방법을 제공합니다. 이 토큰은 사용 시 보통 숨겨진 폼 필드로 포함되고 폼 전송 시 확인되기 때문에 요청이 응용 프로그램에서 보낸 것이며 위조되지 않은 것일 가능성이 높아집니다.

다음 컨트롤러 코드에는 기본 제공되는 cross-site request forgery 방어 기법이 포함되어 있지 않습니다.

public ActionResult ActionName(Model model, string returnurl)
{
  // ... controller logic
}

ASP.NET MVC는 HTML 폼에 antiforgery 토큰을 추가하고 컨트롤러에서 해당 antiforgery 토큰을 확인하여 cross-site request forgery로부터 응용 프로그램을 보다 효율적으로 보호하는 편리한 방법을 제공합니다. 이 토큰은 사용 시 보통 숨겨진 폼 필드로 포함되고 폼 전송 시 확인되기 때문에 요청이 응용 프로그램에서 보낸 것이며 위조되지 않은 것일 가능성이 높아집니다.

일반적으로 프로그래머는 이 antiforgery 토큰을 포함해야 합니다. 그러면 응용 프로그램에 대한 악성 스크립팅이 더 어려워지기 때문입니다.

예제 1: 다음 Razor 코드는 기본 제공 교차 사이트 요청 위조 방어 기능을 추가하지 않고 결과 HTML에 양식을 만듭니다.

@using (Html.BeginForm(new { ReturnUrl = ViewBag.ReturnUrl })) {
  // ... form elements
}

Example 2::The following Razor code creates a form in the resulting HTML without the built-in defense against cross-site request forgery. Note that parameter antiforgery is set to either false or null:

@using (Html.BeginForm("actionName", "controllerName", routeValues, FormMethod.Post, antiforgery: false, htmlAtts)) {
  // ... form elements
}

[Required] 속성으로 표시되는 필수 속성과 [Required] 속성으로 표시되지 않는 옵션 속성이 모두 포함된 모델 클래스를 사용하는 경우, 공격자가 필요한 것보다 많은 데이터가 포함된 요청을 전달하면 문제가 발생할 수 있습니다.

ASP.NET MVC 프레임워크는 요청 매개 변수를 모델 속성에 바인딩하려고 합니다.

모델에 바인딩할 매개 변수를 명시적으로 전달하지 않고 필수 속성과 비필수 속성을 혼합하여 포함하고 있으면 내부용 모델 속성을 공격자가 제어하게 될 수 있습니다.

다음 코드는 [Required]가 지정된 속성과 [Required]가 지정되지 않은 속성이 포함된 가능 모델 클래스를 정의합니다.

public class MyModel
{
    [Required]
    public String UserName { get; set; }

    [Required]
    public String Password { get; set; }

    public Boolean IsAdmin { get; set; }
}

옵션 매개 변수를 사용하여 응용 프로그램 동작을 변경할 수 있는 경우 공격자가 요청에서 옵션 매개 변수를 전달하면 해당 동작을 실제로 변경할 수 있습니다.

null이 허용되지 않는 필수 속성([Required] 속성으로 표시됨)이 포함된 모델 클래스를 사용하는 경우, 공격자가 필요한 것보다 적은 데이터가 포함된 요청을 전달하면 문제가 발생할 수 있습니다.

ASP.NET MVC 프레임워크는 요청 매개 변수를 모델 속성에 바인딩하려고 합니다.

모델에 null이 허용되지 않는 필수 매개 변수가 포함되어 있는데 공격자가 요청 시 필수 매개 변수를 전달하지 않는 경우, 즉 공격자가 under-posting 공격을 사용하면 속성에 기본값(보통 0)이 지정되므로 [Required] 확인 속성이 충족됩니다. 따라서 응용 프로그램이 예기치 않게 동작할 수 있습니다.

다음 코드는 null이 허용되지 않는 필수 열거가 포함된 가능 모델 클래스를 정의합니다.

public enum ArgumentOptions
{
    OptionA = 1,
    OptionB = 2
}

public class Model
{
    [Required]
    public String Argument { get; set; }

    [Required]
    public ArgumentOptions Rounding { get; set; }
}

필수 속성을 포함하며 유형이 상위 모델 클래스의 옵션 멤버인 모델 클래스는 공격자가 필요한 것보다 적은 데이터가 포함된 요청을 전달하면 under-posting 공격에 취약해질 수 있습니다.

ASP.NET MVC 프레임워크는 하위 모델을 포함한 요청 매개 변수를 모델 속성에 바인딩하려고 합니다.

하위 모델이 옵션인 경우, 즉 상위 모델에 [Required] 속성이 없는 속성이 있는 경우에 공격자가 해당 하위 모델을 전달하지 않으면 상위 모델에는 null 값이 지정되고 하위 모델의 필수 필드가 모델 확인을 통해 어설션되지 않습니다. 이는 under-posting 공격의 한 형태입니다.

다음의 모델 클래스 정의를 살펴보십시오.

public class ChildModel
{
    public ChildModel()
    {
    }

    [Required]
    public String RequiredProperty { get; set; }
}

public class ParentModel
{
    public ParentModel()
    {
    }

    public ChildModel Child { get; set; }
}

공격자가 ParentModel.Child 속성의 값을 전달하지 않으면 ChildModel.RequiredProperty 속성에 [Required]가 지정되며, 이 값은 어설션되지 않습니다. 따라서 예기치 않은 부적절한 결과가 발생할 수 있습니다.

NSURLConnectionDelegate.connection(_:willSendRequestFor:) 대리자 메서드를 사용하면 대리자가 연결 인증에 대해 정보에 기반한 결정을 즉시 내릴 수 있습니다. 대리자가 이 메서드를 구현하는 경우, NSURLConnectionDelegate.connection(_:canAuthenticateAgainstProtectionSpace:) 또는 NSURLConnectionDelegate.connection(_:didReceive:) 메서드를 구현할 필요가 없습니다. 사실, 이런 메서드는 호출되지 않으므로 해당 메서드에 대한 모든 보안 검사는 무시됩니다.

서버 신뢰 자격 증명을 생성하기 전에, 신뢰 체인을 평가하는 것은 NSURLConnection 개체, NSURLSession 개체 또는 NSURLDownload 개체 대리자의 책임입니다.

예제 1: 다음 코드는 비평가 서버 신뢰를 사용하여 NSURLCredential을 초기화합니다.

-(void)URLSession:(NSURLSession *)session didReceiveChallenge:(NSURLAuthenticationChallenge *)challenge completionHandler:(void (^)(NSURLSessionAuthChallengeDisposition disposition, NSURLCredential * credential)) completionHandler {
        ...
        [challenge.sender useCredential:[NSURLCredential credentialForTrust: challenge.protectionSpace.serverTrust] forAuthenticationChallenge:challenge];
        ...
}

서버 신뢰 자격 증명을 생성하기 전에, 서버 신뢰를 평가하는 것은 NSURLConnection 개체, NSURLSession 개체 또는 NSURLDownload 개체 대리자의 책임입니다. 서버 신뢰를 평가하기 위해 SecTrustEvaluate(_:_:) 메서드는 서버의 NSURLProtectionSpace 개체의 serverTrust 메서드로부터 얻은 신뢰를 사용하여 호출되어야 합니다.

SecTrustEvaluate(_:_:) 메서드는 두 개의 다른 값을 반환합니다.

- 반환된 OSStatus 값은 결과 코드를 나타냅니다.
- 두 번째 인수가 가리키는 개체는 평가의 결과 유형을 나타냅니다.

신뢰가 유효하지 않은 경우, cancel(_:)로 인증 챌린지를 취소해야 합니다.

예제 1: 다음 예제에서는 서버 신뢰가 평가되지만 수신된 자격 증명은 이 평가의 결과를 확인하지 않고 사용됩니다.

SecTrustRef trust = [[challenge protectionSpace] serverTrust];
SecTrustResultType result = kSecTrustResultInvalid;
OSStatus status = SecTrustEvaluate(trust, &result);
completionHandler(NSURLSessionAuthChallengeUseCredential, [challenge proposedCredential]);

NSURLProtectionSpace 개체는 서버 또는 서버의 영역(일반적으로 영역(realm)으로 불림)을 나타내며, 인증이 필요합니다.
보호 공간에 대해 인증이 필요한 URL 연결을 설정하는 경우 NSURLConnectionDelegate.connection(_:canAuthenticateAgainstProtectionSpace:) 메서드는 인증을 수행해야 하는 NSURLConnectionDelegate.connection(_:didReceive:) 메서드를 호출하기 바로 전에 호출됩니다. 이렇게 하면 보호 공간에 대한 인증을 시도하기 전에 NSURLConnectionDelegate가 보호 공간을 검사할 수 있습니다. true를 반환함으로써 대리자는 인증 형식을 처리할 수 있음을 나타냅니다(인증 형식 처리는 connection(_:didReceive:)에 대한 후속 호출을 통해 처리됨). 해당 대리자가 이 메서드를 구현하지 않고 보호 공간이 클라이언트 인증서 인증 또는 서버 신뢰 인증을 사용하는 경우 시스템은 사용자의 키 집합을 사용하여 인증하려고 시도하는데, 이것은 원하는 동작이 아닐 수 있습니다.

응용 프로그램은 NSURLConnection 또는 NSURLSession 콜백을 구현하여 인증 요청을 처리합니다. 예상 호스트에서 인증 요청이 나오도록 확인하는 것을 잊어버리면 자격 증명은 응용 프로그램이 로드하는 모든 URL에 전송됩니다. 또한, 자격 증명이 안전하게 전송될 수 있음을 확인하지 못하면 자격 증명이 도난됩니다.

예제 1: 다음 응용 프로그램은 사용자 자격 증명을 인증을 요청하는 모든 호스트에 전송합니다.

- (void)URLSession:(NSURLSession *)session didReceiveChallenge:(NS URLAuthenticationChallenge *)challenge completionHandler:(void (^)(NS URLSessionAuthChallengeDisposition, NSURLCredential *))completionHandler { 
    NSString *user = [self getUser]; 
    NSString *pass = [self getPassword]; 

    NSURLCredential *cred = [NSURLCredential credentialWithUser:user 
    password:pass persistence:NSURLCredentialPersistenceForSession]; 
    completionHandler(NSURLSessionAuthChallengeUseCredential, credential);
} 

미사용 데이터에는 고객 관리형 키가 사용되지 않습니다.

기본적으로 AWS는 암호화가 활성화된 경우 AWS 관리형 키를 사용하여 미사용 데이터를 암호화합니다. 고객 관리형 키를 사용하는 조직은 선택한 암호화 키를 사용하여 데이터를 암호화할 수 있습니다. 따라서 암호화 프로세스를 더욱 효율적으로 제어하고 로깅할 수 있습니다.

이러한 이유로 인해 고객 관리형 키는 다음을 비롯한 여러 요구 사항을 충족하는 솔루션에 포함되는 경우가 많습니다.
- 민감한 데이터 액세스 관련 감사 로그
- 데이터 보존
- 키 교체, 비활성화 또는 삭제

aws/service-name 형식의 키는 AWS 관리형 키용으로 예약되어 있습니다.

느슨한 액세스 구성은 시스템을 노출시키고 조직의 공격 표면을 확장합니다. 공개 상호 작용이 가능한 서비스는 일반적으로 악의적인 엔터티의 거의 지속적인 검색 및 조사에 노출됩니다.

이는 노출된 서비스에 대한 제로데이 익스플로이트가 검색되어 게시되는 경우(예: Heartbleed) 특히 문제가 됩니다. 공격자는 패치되지 않고 노출된 시스템을 적극적으로 추적하고 검색하여 악용할 수 있습니다.

느슨한 액세스 구성은 시스템을 불필요하게 노출시키고 조직의 공격 표면을 확장합니다. 공개 상호 작용이 가능한 서비스는 일반적으로 악의적인 엔터티의 거의 지속적인 검색 및 조사에 노출됩니다.

이는 노출된 서비스에 대한 제로데이 익스플로이트가 검색되어 게시되는 경우(예: Heartbleed) 특히 문제가 됩니다. 공격자는 패치되지 않고 노출된 시스템을 적극적으로 추적하고 검색하여 악용할 수 있습니다.

예제 1: 다음 Ansible 작업은 SSH 서버에서 일반적으로 수신 연결 요청에 응답하는 데 사용되는 TCP 포트 22를 전 세계에 공개(0.0.0.0/0)하는 AWS 보안 그룹을 정의합니다.

- name: Task to open SSH port
  amazon.aws.ec2_group:
    name: demo_security_group
    description: Open the ssh port to the world
    state: present
    vpc_id: 123456
    region: us-west-1
    rules:
    - proto: tcp
        ports: 22
        cidr_ip: 0.0.0.0/0