9-1 장 .NET security overview

9-1장 .NET security overview 2009.5 신수정

1. User vs. code security • User security • who is the user and what can the user do ?  role-based security 2) Code security • where is the code from, who wrote the code, and what can the code do? • Authorizing the application’s access to system level resources • What the code is and is not allowed to do • Code access security

1. User vs. code security • Role-based security • Web application이 애플리케이션과 ineract하는 사용자의 identity나 롤에 근거하여 보안 결정을 내리도록 하는것

1. User vs. code security • Code access security • Code에게 언제 자원을 접근할지를 허가, 언제 다른 권한있는 operation을 실행하게 할지 허가

3. .NET Framework security Namespaces

9-2장 Building secure assemblies 2009.5 신수정

1. 개요 • Assemblies • .NET 프레임웍 어플리케이션의 building block • The unit of deployment, version control, and reuse • The unit of trust for code access security • Assembly 내의 모든 코드는 동일하게 trusted • 이 장의 목적 • Assemblies의 보안 설계와 구현을 어떻게 향상시킬 것인가?

2. 위협과 대응 -어셈블리가 수정될때(DLL또는 EXE 에셈블리 파일에서 MSIL instruction이 수정) -허가되지 않은 사용자나 코드가 어셈플리를 CALL하고 권한operation을 실행하고 제한된 자원을 접근할 때 -공격자가 어셈블리 프로세스 레벨 보안 context를 활용하여 임의 코드 실행 -어셈플리가 관리되지 않은 코드를 call하고, 어셈블리가 권한 계정하에 구동될때 -어셈블리가 민감한 데이터를 누설할때

3. 권한 코드 * 권한 코드 • 안전한 어셈블리를 설계하고 구축할 경우, 권한 코드를 정의하라 • 권한코드: 안전한 자원을 접근하고 다른 보안 민감한 operation을 수행하는 관리되는 코드 • Code access security policy에 의해 기능하도록 허가됨 • Non- 권한 코드는 단지 execute할 수 있는 허가밖에 없음 • 권한 자원: 코드가 Code access security 권한을 요청하는 자원- 파일시스템, 데이터베이스, 레지스트리, 로그 등 • 권한 operation: 관리되지 않은 code의 call, sericalization의 사용, application domain의 생성 및 제어, principal object의 생성 등

4. 설계 및 구축 고려사항 • Assembly 설계 고려사항 • 권한 코드의 정의 • Assembly가 install되는 목적 환경에 대한 trust level 정의: assembly가 하도록 허락된 일에 대한 제안 • Highly권한 코드에 대한 sandbox: 권한 코드를 sandbox하여 분리된 assembly에 위치 • Public interface의 설계: 인터페이스의 type과 멤버를 고려하여 최소화되게 설계 2) Class 설계 고려사항 • class와 member visibility의 제한: public interface만 public access modifier사용 • Seal non base classes: 베이스 클래스가 아닐 경우 sealed 키워드 적용 • 어떤 사용자가 code를 call할지를 제한 • Properties를 사용하여 field를 expose: 모든 fields를 private로

4. 설계 및 구축 고려사항 • Strong names • 어셈블리 strong name: text name, version number, culture, public key, 전자서명 • Strong name을 사용하는 것이 보안성 향상 2) Authorization • 어셈블리 내에서 class와 class member를 접근하는 것을 control하는 데 사용할 수 있는 두 가지 유형의 Authorization • Role-bases Authorization: 사용자의 identity와 role-member를 기반으로 접근 허용 • Code access security: 어셈블리의 strong name이나 location 등 evidence에 기반하여 calling code를 authorize 3) 예외 관리 • 구조화된 예외 처리 사용 • 민감한 데이터를 로그하지 않음 • 시스템 이나 민감한 어플리케이션 정보를 누설하지 않음 • 예외 filter issue고려 • 예외 관리 프레임웍 고려

4. 설계 및 구축 고려사항 • File I/O • 파일이름으로 untrusted input을 사용하지 말라 • environment variable을 신뢰하지 말라 • Input file name을 validate하라 • Application context내에 파일 I/O를 constrain하라 2) Event Log • 이벤트 로그 코드를 작성할 경우, 탬퍼링과 정보 유출 위협 고려: 계정 비밀번호 등은 로그하지 않음 3) Registry • 레지스트리는 민감한 응용 설정 데이터(암호회된 데이터베이스 연결 스트링 등)를 저장하는 안전한 위치를 제공 4) 데이터 접근 • 코드가 데이터베이스를 접근할 겨우, 데이터베이스 연결 스트링을 어떻게 안전하게 관리할 것인가?, SQL 인젝션 문제를 해결하기 위해 어떻게 SQL 문장을 형성하고, 어떻게 input을 validate할 것인가? 고려

4. 설계 및 구축 고려사항 • Unmanaged code • Unmanaged code를 call할 경우, managed code가 Unmanaged API에게 전달되는 각 입력 파라미터를 validate하고 , Unmanaged API로 부터 전달되는 output parameter를 다루는데 주의해야 함 • Unmanaged code의 call들을 별도의 wrapper assembly에 isolate 2) Delegates • Method에 대한 레퍼런스 유지, event support • Untrusted sources로 부터 delegates를 허용하지 말라 3) serialization • 민감한 데이터를 serialize하지 말라 • Serialized data stream을 확인하라 4) Threading • Security check의 결과를 cache하지 말라 • Impersonation tokens을 고려하라 • Static class constructor를 synchronize하라 • Dispose method를 synchronize하라

4. 설계 및 구축 고려사항 • reflection 2) Obfuscation • 지적재산권 보호 3) 암호화 • Platform-provided 암호 서비스 사용 • 키 생성: 랜덤 키 생성, large키 사용 • 키 저장: 키를 code에 저장하지 않음. Persisted 키의 접근 제한 • 키 교환 • 키 유지: 주기적으로 키 cycle, exported private key의 보호

9-3장 Code access security 2009.5 신수정

1. 개요 • code access security • 코드가 접근할 수 있는 시스템 자원의 유형과 코드가 수행할 수 있는 권한있는 operation의 유형을 제한하도록 설계된 resource constrain model • 장점 • Code가 할 수 있는 일 제한 • 어떤 코드가 당신의 코드를 call할 수 있는지 제한 • Code를 identify

2. Code access security • code • 모든 managed code는 code access security에 종속 • 어셈블리가 load되면 code access 퍼미션 부여 2) evidence: 어셈블리를 identify하기 위해사용: location관련, author관련 3) permission:코드의 보호된 자원에 대한 접근 및 권한 operation을 수행할 수 있는 권한 표현 4) Policy: 어셈블리에 주어지는 permission 결정 5) Code group: 각 정책 파일은 코드그룹의 계층화된 집합 보유- membership condition+ permission set

2. Code access security

3. 고려사항 • APTCA • Strong name을 가진 어셈블리는 partial trust 어셈블리에 의해 call되지 못함 • APTCA를 보유한 Strong name을 가진 어셈블리는 제외 • APTCA를 사용할 경우 꼭 필요한 경우만 사용 필요 2) 권한 코드 • 권한 코드는 기능을 수행하기 전에 code access security로 부 터 특수한 권한을 부여받아야 함 3) Requesting permission • 어셈블리 설계시 코드가 접근하는 모든 자원과 모든 권한 operation을 list • Deploy time시 관리자가 이 정보를 이용하여 code access security policy구성 • 최소 권한 요구를 제공하기 위해 assembly level declarative security attribues사용

3. 고려사항 • Authorizing code • Code access security 는 당신으로 하여금 당신의 어셈블리를 call하는 code를 authorize할 수 있도록 함 • 예) 인증서 등의 identity evidence를 근거로 하여 calling code 제한 가능 2) Link demands • Run time은 중간 caller로 부터의 퍼미션만을 요구하고, full stack walk를 수행하지 않음 • Link demand는 보안 취약성들 발생 가능성이 큼 3) Assert and RevertAssert 4) Constraining code -사용자나 서비스 계정을 구성할 때 최소권한 원칙 사용 5) File I/O - FileIOPermission

3. 고려사항 • Event Log • 이벤트 로그를 접근하기 위해 EventLogPermission가 적용되어야 함 2) Registry • 레지스트리 접근하기 위해 RegistryPermission가 적용되어야 함 3) 데이터 접근 • SQL 서버에 접근하기 위해 SqlClientPermission가 적용되어야 함 4) 디렉토리 서비스 • 디렉토리 서비스에 대한 접근 유형제한을 위해서 DirectoryServicesPermission가 적용되어야 함 5) 환경변수 • 환경변수 접근 유형제한을 위해서 EnvironmentPermission가 적용되어야 함 6) 웹서비스 • 웹서비스 접근 유형제한을 위해서 WebPermission가 적용되어야 함 7) Socket, DNS • Socket 접근 유형제한을 위해서 SocketPermission가 적용되어야 함 • DNS 접근 유형제한을 위해서 DnstPermission가 적용되어야 함

3. 고려사항 • Unmanaged code • SecurityPermisssion type • SecurityPermisssionFlag.UnmanagedCode 2) Delegates • Delegates에 대해서는 퍼미션 제한 고려 • Delegates를 call하기 전에 퍼미션을 assert하지 않음 3) Serialization -SecurityPermisssion type with its Flag attribute set to SerializationFormatter

9-4장 Code access security with ASP.NET 2009.5 신수정

1. 개요 • code access security • 코드가 접근할 수 있는 시스템 자원의 유형과 코드가 수행할 수 있는 권한있는 operation의 유형을 제한하도록 설계된 resource constrain model • 기존의 principal-based security • 허가가 사용자 identity에 의존 • 관리자는 무제한 권한 • 관리자의 신원이 spoof되었을 경우 문제 발생 .NET 프레임웍 버전 1.1: 관리자가 ASP.NET application과 웹 서비스에 대해 policy정의 가능, code access security 퍼미션 부여 가능

2. Resource access ASP.NET 어플리케이션 및 관리 코드로 부터 모든 자원에 대한 접근은 다음의 두가지 보안 레이어에 subject • Code access security • OS/Platform security

3. Full trust and partial trust - 디폴트로는 Web application은 Full trust로 구동 - partial trust application

4. Developing partial trust Web application

5. partial trust Web application 을 위한 접근 • customize policy: 손 쉬움. 개발 노력 필요하지 않음. 웹서버에서 정책을 수정하는것이 허락되지 않ㅇ을 수 있음 • 권한 코드의 sandbox: 자원접근코드를 wrapper 어셈블리에 위치하고, 이 이셈블리에 full trust를 부여함. 그리고, 권한 코드의 퍼미션 요구들에 대해 sandbox함

6. Medium Trust • 웹 application을 호스트 하는 경우 medium level 권고 • attack surface의 감소: application에게 모든 접근권한을 주지 않음 • Application isolation 2) Medium trust restriction • 이벤트로그의 직접적 접근 불가 • 파일 시스템 접근 제한, application virtual 디렉토리내의 파일에만 접근가능 • OLE DB데이터 자원에 직접 접근 불가 • 웹서비스의 접근 제한 • 윈도우 레지스트리 직접 접근 불가

9-5장 Building Secure ASP.NET pages and controls 2009.5 신수정

1. 위협과 대응

2. 설계 고려사항 서버 사이드 입력 검증 사용 웹사이트를 파티션: public 접근 영역과 제한 영역을 분리된 서브 디렉토리에 위치 자원접근을 위해 사용되는 identity고려 Credential과 authentication ticket의 보호 안전하게 fail Authorization granularity고려 웹 콘트롤과 사용자 콘트롤을 분리된 어셈블리에 위치 자원 접근 코드를 분리된 어셈블리에 위치

3. 구축 • Input validation • Constrain then sanitize: type, length, format, range • Regular expression • String field • Data field • Numeric field • Range check • Sanitizing input • HTML controls의 검증 • 데이터 접근을 위해 사용되는 입력의 검증 • File I/O를 위해 사용되는 입력의 검증 • 일반적 expression

3. 구축 2) Cross-site scrypting • 입력 검증 • 출력 encode • Set the correct character encoding • Use the ASP.NET version 1.1 validateRequest option • Install URLScan • Use the HttpOnly cookie option • Use the <frame> security attribute • Use the innerText property

3. 구축 3) Authentication • Secure Forms authentication • Web site의 파티션 • 제한된 페이지는 SSL로 보호 • URL Authorization 사용 • Authentication cookie의 보호 • Navigation을 위해 절대 URLs사용 • 안전한 credential 관리 사용: 패스워드에 대해 일방향 해쉬, 강한 패스워드, SQL injection 방지

3. 구축 4) Authorization • 페이지와 디렉토리 접근 통제를 위해 URL authorization사용 • 윈도우 authentication과 파일 authorization사용 • Class와 method에 대한 principal demand사용 • Fine-grained authorization을 위해 explicit role check사용 5) Impersonation • 사용시 programmatic Impersonation 사용

3. 구축 6) Sensitive data • 민감한 데이터를 페이지에서 페이지로 전달하지 말라 • 구성 파일에 plaintext 패스워드 회피 • 키 관리를 피하기 위해 DPAPI사용 • 민감한 데이터를 cache하지 않음

3. 구축 7) Session management • 관련된 두개의 토큰: Session token 과 authentication token • 민감한 페이지에 대해 authentication 요구 • Client-side state management option에 의존하지 말라 • Session token 과 authentication token을 혼합하지 말라 • SSL을 효과적으로 사용하라 • 세션 데이터를 보호하라

3. 구축 8) 파라미터 조작 • View state를 MACs으로 보호하라 • One-click공격을 대응하기 위해 Page.ViewStateUserKey를 사용하라 • 민감한 데이터를 서버에 유지하라 • 입력 파라미터를 validate하라 9) 예외 관리 • Client로 부터 일반적인 에러 페이지를 return하라 • Page-level 또는 application level error handler를 implement하라 10) 로깅 및 감사 • Install time에서 application event source생성

9-6장 Building Secure Serviced components 2009.5 신수정

1. 개요

2. 위협과 대응

3. 설계 고려사항 Role-based authorization Sensitive data protection Audit 요구 Application activation type Transactions Code access security

4. 고려사항 1) 인증 • 주요 이슈: 모든 call들은 authenticate되어야 한다.- anonymous users가 component 기능에 접근하는 것을 방지 2) authorization • Role-based security를 enable • Component level access check를 enable • Component level access check를 enforce 3) 형상관리 • 최소권한 run-as 계정 사용 • Object constructor string에 비밀저장 회피 • Unconstrained delegation 회피

4. 고려사항 4) 민감한 데이터 • IPSEC 등 5) 로깅 및 감사 • 사용자 트랜잭젼 audit • Component level access check를 enable • Component level access check를 enforce 6) 안전한 서비스 component의 구축 7) Code access security 고려

4. 고려사항 8) 구현 고려

9-7장 Building Secure Web services 2009.5 신수정

1. 개요

2. 설계 고려사항 Authentication 요구 프라이버시 및 무결성 요구 자원 접근 identities Code access security

3. 고려사항 • Input validation • Authentication • platform level • Message level • Application level 3) Authorization 4) Sensitive data 5) Parameter manipulation 6) 예외관리 7) 로깅 및 감사 8) Proxy 고려 9) Code access security 고려

9-1 장 .NET security overview