문서요약 - 웹 애플리케이션 보안 문제의 이해 by Rational Software

테스팅타입별/보안(Security)

문서요약 - 웹 애플리케이션 보안 문제의 이해 by Rational Software

grapevine9700 2019. 2. 4. 06:30

제목: 웹 애플리케이션 보안 문제의 이해(Understanding Web application security challenges)

저자: Rational Software

문서유형: 화이트페이퍼(총 20페이지), 2008년

조직의 웹 애플리케이션 보안을 향상시킬 수 있는 접근방식을 기술한 자료(애플리케이션 레벨의 보안 위협에 집중)

웹 애플리케이션을 취약하게 만드는 것

대부분 회사가 자사 웹 사이트에 방화벽, SSL(Secure Sockets Layer), 네트워크 및 호스트 보안을 장착하지만, 대부분의 공격이 애플리케이션 자체에 가해지며 앞의 기술들은 이런 공격을 예방할 수 없음
OSI 참조 모델에서 모든 메시지가 7개의 네트워크 프로토콜 층을 통해 전달됨. 최상위에 위치한 애플리케이션 층은 콘텐츠를 가진 메시지(예, HTML, XML, SOAP, Web 서비스)를 전송하는 HTTP와 기타 다른 프로토콜을 포함한다.
이 페이퍼는 전통적인 방화벽이 효과적으로 퇴치하지 못하는 HTTP에 의해 운반되는 애플리케이션 공격에 집중. 해커들이 잠재적으로 해로운 데이터를 지닌 HTTP 리퀘스트를 어떻게 네트워크 레벨에서 정상처럼 보이게 만드는지 알고 있음. 즉, HTTP에 담긴 공격이 데이터베이스로의 무제한 액세스, 임의적인 시스템 커맨드 실행, 웹 사이트 콘텐츠 변경 등을 허용하게 만들 수 있다.

대표적인 웹 애플리케이션 공격들

아래 그림은 보호가 필요할 수도 있는 시스템 내 여러 지점을 보여준다.

[웹 애플리케이션 보안 관심사]

아래는 흔한 웹 애플리케이션 공격 타입과 그 예방책을 나열한다.

위장(Impersonation): 어떤 사용자를 사칭하기 위해서(또는 쿠키가 다른 서버로부터 나온 것처럼 가장하기 위해서) 다른 사용자의 자격(credentials)을 입력하거나 쿠키/패러미터를 변경함

원인

예방책

Ø 사용자 데이터로의 액세스를 허용하는데 통신-기반 인증을 사용

Ø 수집되고 재사용 될 수 있는 암호화 안된 자격(credentials)을 사용

Ø 자격을 쿠키 또는 패러미터에 저장

Ø 증명되지 않은 인증 방법이나 잘못된 신뢰 도메인으로부터의 인증을 사용

Ø 클라이언트 소프트웨어가 호스트를 인증하는 것을 허용 안 함

아래를 사용해 엄격한 인증 및 보호를 자격 정보(credential information)에 적용:

Ø 운영체제(OS) 공급의 프레임워크

Ø 세션 쿠키 같은 암호화된 토큰

Ø 디지털 서명

부당변경(Tampering): 인가 없이 리소스를 변경하거나 삭제함(예, 웹 사이트 훼손, 전송 중인 데이터 변경)

원인

예방책

Ø 확인 없이 데이터 소스를 신뢰

Ø 원치 않는 코드의 실행을 예방하기 위해 입력을 위생 처리(원치 않는 부분 제거)

Ø 확대된 권한으로 실행

Ø 민감함 데이터를 암호화 안된 채로 놔둠

Ø 파일/디렉토리/기타 리소스를 잠그기 위해 OS 보안을 사용

Ø 데이터를 확인

Ø 전송 중인 데이터를 해싱하고 서명함(예, SSL 또는 IPsec을 사용해서)

부인(Repudiation): 어떤 액션이 발생했다는 증거를 제거하거나, 숨기거나, 변경하려는 시도(예, 로그 삭제, 변경을 요구하기 위해 사용자 사칭)

원인

예방책

Ø 인증 및 인가 프로세스가 약하거나 결여됨

Ø 부적절하게 로깅

Ø 안전하지 않는 통신 채널 상에 민감한 정보를 허용

Ø 엄격한 인증, 트랙잭션 로그, 디지털 서명을 사용

Ø 감사

정보 노출(Information disclosure): 패스워드, 신용 카드 정보 같은 개인 식별이 가능한 정보를 노출, 애플리케이션 소스와 그 호스트 머신에 대한 정보를 드러냄

원인

예방책

Ø 인증된 사용자가 다른 사용자의 데이터로 액세스하는 것을 허용

Ø 안전하지 않는 통신 채널 상에 민감한 정보를 허용

Ø 좋지 못한 암호화 알고리즘과 키를 선정

Ø 개인 식별이 가능한 정보를 영구적인 토대 보다는 (일시적인) 세션 상에 저장

Ø 가능하면 민감한 정보에는 해싱과 암호화를 사용

Ø 사용자 데이터를 사용자 인증에 매치함

서비스 거부(Denial of service: DoS): 서버를 제압하기 위해 많은 메시지 또는 동시적 리퀘스트를 전송(Flooding), 리소스를 소비함으로써(또는 애플리케이션 재시작을 야기함으로써) 서버 반응이 느려지도록 대대적인 리퀘스트를 전송(Lockout)

원인

예방책

Ø 단일 서버 상에 너무 많은 애플리케이션들을 놓거나 또는 같은 서버 상에 상충되는 애플리케이션들을 놓음

Ø 종합적인 단위 테스팅을 수행하는 것을 게을리함

Ø 방화벽을 사용하여 패킷을 걸러냄

Ø 단일 소스로부터의 리퀘스트 수를 제어하기 위해 부하 분산 장치(a load balancer)를 사용

Ø 프로세싱-집중적인 리퀘스트와 에러 복구를 처리하기 위해 비동기 프로토콜 사용

권한 승격(Elevation of privilege): 관리자 권한을 얻기 위해(또는 기밀 파일로의 액세스를 위해) 정상적인 액세스 권한을 넘어서는 것

원인

예방책

Ø 웹 서버 프로세스를 “root” 또는 “administrator” 권한으로 실행

Ø 버퍼 오버플로우를 허용하고 애플리케이션을 디버그 상태로 승격하는 코딩 에러를 사용

Ø 가능하면 최소 권한 context를 사용

Ø 버퍼 오버플로우를 예방/제어 하기 위한 타입 안전 언어(type-safe languages)와 컴파일러 옵션을 사용

웹 애플리케이션 생명 주기

IBM의 RUP(Rational Unified Process) 솔루션은 웹 애플리케이션 개발을 위한 종합적이고 반복적인 프로세스 프레임워크를 제안. 이 프레임워크의 핵심 단계들이 아래와 같다.

시작(Inception): 비즈니스 케이스, 범위, 운영 비전을 확립한다. 일차 유스케이스 모델, 프로젝트 계획서, 리스크 평가 및 프로젝트 기술서를 생성한다(핵심 요구사항, 보안 요구사항, 제약사항, 기능, 프로토타입 후보 아키텍쳐 등을 포함).
정교화(Elaboration): 비전을 상세화하고, 베이스라인 아키텍쳐를 확립하기 위해 아키텍쳐적으로 중요한 시나리오를 고려하고, 유스케이스 모델을 상세화한다. 기술 리스크를 완화하기 위해 하나 또는 여러 개의 프로토타입을 생성하고 테스트 한다.
건설(Construction): 특정 컴포넌트를 위한 그리고 이 컴포넌트와 타 애플리케이션과의 상호작용을 위한 상세 설계를 개발한다(지속적으로 요구사항과 대조해 추적함). 성능, 신뢰성, 보안을 위한 코드와 테스트 컴포넌트를 생성하고, 테스트된 컴포넌트를 1차 릴리즈로 통합한다.
이행(Transition): 애플리케이션을 전개하고, 사용자를 훈련하고, 보안과 성능을 검증하기 위한 베타 테스팅을 수행하고, 애플리케이션을 요구사항과 대조해 확인한다. 애플리케이션이 변경 됨에 따라 성능, 신뢰성, 보안을 지속적으로 모니터한다.

시작(Inception) 단계 – 보안 요구사항 정의하기

시작 단계 동안 여러 애플리케이션 레벨 보안 관심사와 관련된 요구사항을 구성 할 수 있다.

애플리케이션 관심사	제약사항/요구사항을 위해 고려할 것들
애플리케이션 환경	Ø 조직의 보안 정책을 식별하고, 이해하고, 수용한다. Ø 서비스, 프로토콜, 방화벽 같은 인프라구조 제약을 인지한다. Ø 호스팅 환경 제약을 식별한다(예, 가상 사설 네트워크[VPN], sandboxing). Ø 애플리케이션 전개 구성(deployment configuration)을 정의한다. Ø 네트워크 도메인 구조, 클러스터링, 원격 애플리케이션 서버를 정의한다. Ø 데이터베이스 서버를 식별한다. Ø 어떤 안전한 통신 기능을 환경이 지원하는지 식별한다. Ø Web farm 고려사항을 다룬다(세션 상태 관리, 머신에 특정한 암호화 키, SSL, 인증서 배포 이슈, 로밍 프로파일). 애플리케이션이 SSL을 사용하면 사용될 인증 기관(certificate authority)과 타입을 식별한다. Ø 요구되는 확장성(scalability) 및 성능 기준을 다룬다. Ø 코드 신뢰 수준(the code trust level)을 조사한다.
입력/데이터 확인 및 인증	Ø 모든 클라이언트 입력이 잠재적으로 위험하다고 가정한다. Ø 신분 계정(identity accounts)을 위한 모든 신뢰 경계(trust boundaries)를 식별하고 이 경계를 가로지르는 리소스를 식별한다. Ø 계정 관리 정책(account management policies)과 최소 권한 계정 정책(a least-privileged accounts policy)을 정의한다. Ø 강력한 패스워드와 강제 조치(enforcement measures)를 위한 요구사항을 명세한다. Ø SSL, VPN, IPsec 등을 사용해 사용자 자격(user credentials)을 암호화하고, 인증 정보(예, 토큰, 쿠키, 티켓)가 암호화 안된 연결 상으로 전송되지 않음을 보장한다. Ø 인증 실패의 경우에 최소의 에러 정보가 클라이언트에게 반환됨을 보장한다.
세션 관리	Ø 세션 수명을 제한한다. Ø 인가 안된 액세스로부터 세션 상태를 보호한다. Ø 세션 식별자(session identifiers)가 쿼리스트링에 담겨 전달되지 않음을 보장한다.

정교화(Elaboration) 단계 – 보안대책을 위한 모델링

정의된 보안 요구사항과 관련해 정교화 단계 동안의 활동들이 아래와 같다.

보안 고려사항	고려할 것들
입력/데이터 확인 (Input/data validation)	Ø 모든 클라이언트 입력을 의심하고 애플리케이션에 의해 제어되는 서버 상에서 그것을 확인한다(클라이언트 측에서 이미 확인했다 할지라도). Ø 잠재적 SQL 삽입과 크로스 사이트 스크립팅 이슈를 고려한다. Ø 입구(entry points)와 신뢰 경계(trust boundaries)를 식별한다.
인증 (Authentication)	Ø 공공 지역과 제한 지역, ID 계정, 신뢰 경계를 넘나드는 리소스로의 액세스를 분리한다. Ø 애플리케이션을 서비스하거나 관리하는 계정을 식별한다. Ø 사용자 자격(user credentials)이 암호화되고 안전하게 저장됨을 보장한다. Ø 데이터베이스와 인증하기 위한 ID를 명시한다.
인가 (Authorization)	Ø 각자가 액세스할 수 있는 모든 ID와 리소스를 명시한다. Ø 권한(특권)에 따른 리소스와 오퍼레이션을 식별한다. Ø 여러 다른 역할에 따른 권한(특권)을 분리한다. Ø 코드-액세스 보안 요구사항을 식별한다.
구성 관리 (Configuration management)	Ø 강력한 인증 및 인가 기능으로 관리 인터페이스와 원격 관리 채널을 보호한다. Ø 역할-기반 관리자 권한을 제공한다. Ø 최소 권한(least-privileged) 프로세스와 서비스 계정을 사용한다.
민감한 데이터와 세션 보호	Ø 비밀 데이터를 저장하는걸 피한다. 반드시 보유해야 하는 것들에 대해서는 암호화 알고리즘과 키 크기를 식별한다. Ø 네트워크 상으로 전송되는 민감한 데이터를 위한 보호 메커니즘을 식별한다. Ø 인증 쿠키를 보호하고 그 콘텐츠를 암호화하기 위해 SSL을 사용한다. Ø 안전한 암호화 키를 돕는 방법론을 식별하고, 오로지 알려진 암호 기법 라이브러리와 서비스만 사용한다. Ø 적절한 암호 알고리즘과 키 크기를 식별한다.
예외 관리	Ø 구조화된 예외 처리(exception handling)로의 표준 접근방식을 정의한다. Ø 클라이언트에게 반환될 일반 에러 메시지를 명시한다.
감사 및 로깅 (Auditing and logging)	Ø 감사 및 로깅을 위한 주요 패러미터를 식별한다. Ø 로그 파일을 위한 저장소, 보안 및 분석 특징을 명시한다. Ø (OS 레벨 또는 애플리케이션 레벨에서) 어떻게 호출자 신원(caller identity)을 다중 티어를 가로질러 흘려 보낼지 명시한다.

건설(Construction) 단계 – 보안대책을 위한 코딩

정의된 보안 요구사항과 관련해 건설 단계 동안의 활동들이 아래와 같다.

보안 고려사항	고려할 것들
코딩 관행 (Coding practices)	Ø 그 영향을 이해하기 위한 테스팅 없이 디폴트 보안 세팅을 감소하거나 변경하지 않는다. Ø 비밀을 보호하는데 무명(obscurity)에 의존하지 않는다(비밀 정보를 코드에 집어넣는 것을 피한다). Ø 불필요한 정보는 드러내지 않는다. Ø 보안 에러들을 자주 테스트하고 그것들을 초기에 수정한다. Ø 안전 모드로의 직접적 실패. 스택 추적(stack traces)을 디스플레이하거나 민감한 데이터를 보호 안된 채 두지 않는다.
입력/데이터 확인 (Input/data validation)	Ø 모든 입력 패러미터를 확인한다(폼 필드, 쿼리스트링, 쿠키, HTTP 헤더 등). Ø 오로지 알려진 좋은 입력만 수락하고, 알려진 나쁜 입력은 거부한다. Ø 타입, 길이, 형식, 범위 측면에서 데이터를 확인한다. Ø 입력을 포함하는 출력이 적절하게 HTML-부호화(또는 URL-부호화) 되었음을 보장한다.
인증 (Authentication)	Ø 패스워드를 핵심만 간추려 저장한다. Ø 인증 실패에 대해 최소의 에러 정보를 반환한다. Ø 보안 목적으로 HTTP 헤더 정보를 사용하지 않는다.
인가 (Authorization)	Ø 액세스-특정 저장된 절차(access-specific stored procedures)로의 데이터베이스 로그인을 제한한다. 테이블로 직접 액세스를 허용하지 않는다. Ø 시스템 레벨 리소스로의 액세스를 제한한다.
구성 관리	Ø 구성 저장소(configuration stores)을 안전하게 지킨다. Ø 평문 구성 파일(plain text configuration files)에 기밀 데이터를 담지 않는다.
민감한 데이터 와 세션 보호	Ø 민감한 데이터를 코드에 저장하지 않는다. Ø 데이터베이스 연결, 패스워드, 키를 평문(암호화를 하지 않은 데이터)으로 저장하지 않는다. Ø 민감한 데이터를 평문으로 기록하지(log) 않는다. Ø 민감한 데이터를 쿠키에 저장하거나 또는 그것을 쿼리스트링/폼 필드로써 전송하지 않는다.
예외 관리	Ø 예외 발생 직후 최소의 정보를 드러낸다.
감사 및 로깅	Ø 민감한 데이터를 기록하지(log) 않는다.

이벤트-주도 테스팅(Event-driven testing)

이벤트-주도의 테스팅을 수행하기 위해 구축하는 애플리케이션으로 직접 보안 테스트를 통합시킬 수 있음. 이 경우 사용자가 리퀘스트를 하고 애플리케이션이 응답을 하면 테스트는 이 응답을 예상(또는 기존에 저장된) 응답과 비교하여 시스템이 제대로 동작하는지 여부를 결정한다. 예를 들어, 아래 그림에서 애플리케이션이 데이터베이스를 그 백엔드 컴포넌트로 사용함. 테스터는 리퀘스트 흐름에 스파이 프록시(a spy proxy)와 검증기(a verifier)를 삽입하고, 검증기에게 정상 리퀘스트가 어떻게 생겼는지를 알려줘서 검증기가 그것을 스파이 프록시의 실제 리퀘스트와 비교할 수 있게 한다.

[백엔드 데이터베이스를 가진 웹 애플리케이션 보안 테스팅]

모든 서비스, 이메일, XML, 또는 레가시 서비스도 백엔드 역할을 할 수 있다. 리퀘스트를 검토하기 위한 코드를 어떻게 구현할지는 애플리케이션 아키텍쳐에 달려있다. 예를 들면, 스파이 컴포넌트가 모의 데이터 액세스 오브젝트(a mock data access object) 일 수도, 프록시(a proxy) 일 수도, 또는 프론트엔드 서비스로부터 계승된 클래스(a class) 일 수도 있다. 또한 테스팅 프레임워크가 필요로 하는 보고 데이터(reporting data)를 공급하기 위해서 데이터 스트림으로 삽입되는 특별히 테스트를 위한 코드를 생성할 수도 있다.

저작자표시 비영리 변경금지