Transcript 2. Code access security

9-1장
.NET security overview
2009.5
신수정
1. User vs. code security
1)
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
2
1. User vs. code security
1)
Role-based security
-
Web application이 애플리케이션과 ineract하는 사용자의 identity나 롤에 근거하여 보안 결정을 내리
도록 하는것
3
1. User vs. code security
1)
Code access security
-
Code에게 언제 자원을 접근할지를 허가, 언제 다른 권한있는 operation을 실행하게 할지 허가
4
3. .NET Framework security Namespaces
5
9-2장
Building secure assemblies
2009.5
신수정
1. 개요
1)
Assemblies
-
.NET 프레임웍 어플리케이션의 building block
-
The unit of deployment, version control, and reuse
-
The unit of trust for code access security
-
Assembly 내의 모든 코드는 동일하게 trusted
2)
이 장의 목적
-
Assemblies의 보안 설계와 구현을 어떻게 향상시킬 것인가?
7
2. 위협과 대응
-어셈블리가 수정될때
(DLL또는 EXE 에셈블
리 파일에서 MSIL
instruction이 수정)
-허가되지 않은 사용자
나 코드가 어셈플리를
CALL하고 권한
operation을 실행하고
제한된 자원을 접근할
때
-공격자가 어셈블리 프로세스 레벨 보안
context를 활용하여 임의 코드 실행
-어셈플리가 관리되지 않은 코드를 call하
고, 어셈블리가 권한 계정하에 구동될때
-어셈블리가 민감한 데
이터를 누설할때
8
3. 권한 코드
* 권한 코드
-
안전한 어셈블리를 설계하고 구축할 경우, 권한 코드를 정의하라
-
권한코드: 안전한 자원을 접근하고 다른 보안 민감한 operation을 수행하는 관리되는 코드
-
Code access security policy에 의해 기능하도록 허가됨
-
Non- 권한 코드는 단지 execute할 수 있는 허가밖에 없음
-
권한 자원: 코드가 Code access security 권한을 요청하는 자원- 파일시스템, 데이터베이
스, 레지스트리, 로그 등
-
권한 operation: 관리되지 않은 code의 call, sericalization의 사용, application domain
의 생성 및 제어, principal object의 생성 등
9
4. 설계 및 구축 고려사항
1)
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로
10
4. 설계 및 구축 고려사항
1)
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고려
-
예외 관리 프레임웍 고려
11
4. 설계 및 구축 고려사항
1)
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할 것인가? 고려
12
4. 설계 및 구축 고려사항
1)
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하라
13
4. 설계 및 구축 고려사항
1)
reflection
2) Obfuscation
-
지적재산권 보호
3) 암호화
-
Platform-provided 암호 서비스 사용
-
키 생성: 랜덤 키 생성, large키 사용
-
키 저장: 키를 code에 저장하지 않음. Persisted 키의 접근 제한
-
키 교환
-
키 유지: 주기적으로 키 cycle, exported private key의 보호
14
9-3장
Code access security
2009.5
신수정
1. 개요
1)
code access security
-
코드가 접근할 수 있는 시스템 자원의 유형과 코드가 수행할 수 있는 권한있는 operation의
유형을 제한하도록 설계된 resource constrain model
2)
장점
-
Code가 할 수 있는 일 제한
-
어떤 코드가 당신의 코드를 call할 수 있는지 제한
-
Code를 identify
16
2. Code access security
1)
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
17
2. Code access security
18
3. 고려사항
1)
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사용
19
3. 고려사항
1)
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
20
3. 고려사항
1)
-
Event Log
이벤트 로그를 접근하기 위해 EventLogPermission가 적용되어야 함
2) Registry
레지스트리 접근하기 위해 RegistryPermission가 적용되어야 함
3) 데이터 접근
SQL 서버에 접근하기 위해 SqlClientPermission가 적용되어야 함
4) 디렉토리 서비스
디렉토리 서비스에 대한 접근 유형제한을 위해서 DirectoryServicesPermission가 적용되어야 함
5) 환경변수
환경변수 접근 유형제한을 위해서 EnvironmentPermission가 적용되어야 함
6) 웹서비스
웹서비스 접근 유형제한을 위해서 WebPermission가 적용되어야 함
7) Socket, DNS
Socket 접근 유형제한을 위해서 SocketPermission가 적용되어야 함
DNS 접근 유형제한을 위해서 DnstPermission가 적용되어야 함
21
3. 고려사항
1)
Unmanaged code
-
SecurityPermisssion type
-
SecurityPermisssionFlag.UnmanagedCode
2)
Delegates
-
Delegates에 대해서는 퍼미션 제한 고려
-
Delegates를 call하기 전에 퍼미션을 assert하지 않음
3) Serialization
-SecurityPermisssion type with its Flag attribute set to SerializationFormatter
22
9-4장
Code access security with
ASP.NET
2009.5
신수정
1. 개요
1)
code access security
-
코드가 접근할 수 있는 시스템 자원의 유형과 코드가 수행할 수 있는 권한있는 operation의
유형을 제한하도록 설계된 resource constrain model
2)
기존의 principal-based security
-
허가가 사용자 identity에 의존
-
관리자는 무제한 권한
-
관리자의 신원이 spoof되었을 경우 문제 발생
.NET 프레임웍 버전 1.1: 관리자가 ASP.NET application과 웹 서비스에 대해 policy정의 가능,
code access security 퍼미션 부여 가능
24
2. Resource access
ASP.NET 어플리케이션 및 관리 코드로 부터 모든 자원에 대한 접근은 다음의 두가지 보안 레이
어에 subject
-
Code access security
-
OS/Platform security
25
3. Full trust and partial trust
- 디폴트로는 Web application은 Full trust로 구동
- partial trust application
26
4. Developing partial trust Web application
27
5. partial trust Web application 을 위한 접근
1)
customize policy: 손 쉬움. 개발 노력 필요하지 않음. 웹서버에서 정책을 수정하는것이 허락되지 않ㅇ을 수
있음
2)
권한 코드의 sandbox: 자원접근코드를 wrapper 어셈블리에 위치하고, 이 이셈블리에 full trust를 부여함.
그리고, 권한 코드의 퍼미션 요구들에 대해 sandbox함
28
6. Medium Trust
1)
웹 application을 호스트 하는 경우 medium level 권고
-
attack surface의 감소: application에게 모든 접근권한을 주지 않음
-
Application isolation
2)
Medium trust restriction
-
이벤트로그의 직접적 접근 불가
-
파일 시스템 접근 제한, application virtual 디렉토리내의 파일에만 접근가능
-
OLE DB데이터 자원에 직접 접근 불가
-
웹서비스의 접근 제한
-
윈도우 레지스트리 직접 접근 불가
29
9-5장
Building Secure
ASP.NET pages and controls
2009.5
신수정
1. 위협과 대응
31
2. 설계 고려사항
1)
서버 사이드 입력 검증 사용
2)
웹사이트를 파티션: public 접근 영역과 제한 영역을 분리된 서브 디렉토리에 위치
3)
자원접근을 위해 사용되는 identity고려
4)
Credential과 authentication ticket의 보호
5)
안전하게 fail
6)
Authorization granularity고려
7)
웹 콘트롤과 사용자 콘트롤을 분리된 어셈블리에 위치
8)
자원 접근 코드를 분리된 어셈블리에 위치
32
3. 구축
1)
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
33
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
34
3. 구축
3) Authentication
-
Secure Forms authentication
-
Web site의 파티션
-
제한된 페이지는 SSL로 보호
-
URL Authorization 사용
-
Authentication cookie의 보호
-
Navigation을 위해 절대 URLs사용
-
안전한 credential 관리 사용: 패스워드에 대해 일방향 해쉬, 강한 패스워드, SQL injection 방지
35
3. 구축
4) Authorization
-
페이지와 디렉토리 접근 통제를 위해 URL authorization사용
-
윈도우 authentication과 파일 authorization사용
-
Class와 method에 대한 principal demand사용
-
Fine-grained authorization을 위해 explicit role check사용
5) Impersonation
-
사용시 programmatic Impersonation 사용
36
3. 구축
6) Sensitive data
-
민감한 데이터를 페이지에서 페이지로 전달하지 말라
-
구성 파일에 plaintext 패스워드 회피
-
키 관리를 피하기 위해 DPAPI사용
-
민감한 데이터를 cache하지 않음
37
3. 구축
7) Session management
-
관련된 두개의 토큰: Session token 과 authentication token
-
민감한 페이지에 대해 authentication 요구
-
Client-side state management option에 의존하지 말라
-
Session token 과 authentication token을 혼합하지 말라
-
SSL을 효과적으로 사용하라
-
세션 데이터를 보호하라
38
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생성
39
9-6장
Building Secure
Serviced components
2009.5
신수정
1. 개요
41
2. 위협과 대응
42
3. 설계 고려사항
1)
Role-based authorization
2)
Sensitive data protection
3)
Audit 요구
4)
Application activation type
5)
Transactions
6)
Code access security
43
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 회피
44
4. 고려사항
4) 민감한 데이터
-
IPSEC 등
5) 로깅 및 감사
-
사용자 트랜잭젼 audit
-
Component level access check를 enable
-
Component level access check를 enforce
6) 안전한 서비스 component의 구축
7) Code access security 고려
45
4. 고려사항
8) 구현 고려
46
9-7장
Building Secure
Web services
2009.5
신수정
1. 개요
48
2. 설계 고려사항
1)
Authentication 요구
2)
프라이버시 및 무결성 요구
3)
자원 접근 identities
4)
Code access security
49
3. 고려사항
1)
Input validation
2)
Authentication
-
platform level
-
Message level
-
Application level
3) Authorization
4) Sensitive data
5) Parameter manipulation
6) 예외관리
7) 로깅 및 감사
8) Proxy 고려
9) Code access security 고려
50
3. 고려사항
10) 구현 고려
-
Intranet
-
Extranet
-
Internet
51
9-8장
Building Secure
Data access
2009.5
신수정
1. 개요
53
2. 설계 고려사항
1)
윈도우 Authentication 사용
2)
최소 권한 계정 사용
3)
Stored procedure 사용
4)
저장장치 민감한 데이터 보호
5)
분리된 데이터 접근 어셈블리 사용
54
3. 고려사항
1)
Input validation
2)
SQL Injection
3)
Authentication: 윈도우 인증 사용, SQL인증을 위한 credential보호, 최소 권한 계정 사용 연결
4)
Authorization: 허가되지 않은 caller제한, 허가되지 않은 code제한, DB의 application 제한
5)
형상 관리: 윈도우 인증 사용, connection string 안전케함, 제한된 ACL을 가진 UDL파일 보호
55
3. 고려사항
6) 민감한 데이터
7) 예외처리
8) 안전한 데이터 접근 component 구축
9) Code access security 고려
10) Deployment 고려
-
방화벽 제한
-
Connection string 구성
-
로그온 감사
-
네트워크 상 데이터 프라이버시 및 무결성
56