책 요약정리 – 웹 보안 우려사항 by Nguyen

출처: Testing Applications on the Web, 저자 Hung Q. Nguyen, 2001년

15장 웹 보안 우려사항(Web Security Concerns), 285~310 페이지

 

---

 

웹 보안 테스팅(Web Security Testing)

전통적인 의미의 웹 보안 테스팅은 전반적인 웹 시스템 보안 방어(security defenses)의 효율성을 테스트하는 것을 의미한다. 이 테스팅은 보안 기술, 네트워크 기술, 프로그래밍에 대한 지식과 네트워크 시스템 보안 침투에 대한 실제 경험도 필요로 하는데, 이러한 유형의 지식은 일반적으로 소프트웨어 테스터의 손을 벗어난다. 하지만 테스터가 보안 이슈의 범위를 잘 이해하고 있는 것이 여전히 중요한데, 그래야 어떤 태스크는 직접 수행하고 또 어떤 태스크는 전문가에게 맡겨야 하는지를 판단할 수 있기 때문이다.

 

웹 보안 기술 기초

웹 기반 시스템에 사용되는 가장 일반적인 보안 기술이 아래와 같다.

• 암호화(Encryption): 인터넷을 통해 전송되는 기밀 텍스트 정보(사용자 ID, 암호, 신용 카드 번호 등)가 보호되도록 한다. 암호화가 정보 도난을 방지하지는 않지만, 의도된 수신자 이외의 다른 사람이 정보를 읽을 수 없도록 만든다.
• 인증(Authentication): 민감한 정보가 실수로 잘못된 사람에게 전송되거나 침입자가 사설 네트워크의 리소스에 액세스 할 수 없도록 클라이언트와 서버의 신원을 확인한다.
• 디지털 인증서(Digital certificates): 공개/개인 키 암호화 및 복호화를 통해 개인과 조직의 신원을 확인한다.
• 방화벽(Firewalls): 인터넷을 통한 무단 액세스 및 데이터 전송으로부터 사설 네트워크와 인트라넷을 보호한다.
• 권한부여(Authorization): 특정 작업을 수행하는 사람이 그 권한을 부여받았는지 확인한다.

 

전자상거래(E-commerce) 예

아래 그림은 전형적인 전자상거래 트랜잭션을 추적한 것으로, 그 과정에서 수많은 데이터베이스, 방화벽, 개방형 인터넷 전송이 나타난다. 테스터는 이 다이어그램을 사용하여 테스트 할 소프트웨어의 모든 영역과 지점(point)을 표시하고, 또한 제어할 수 없는 영역도 표시한다(7단계~12단계는 은행 방화벽 너머에서 일어나므로 테스팅에서 접근 할 수 없음).

 

I. 사용자가 전자상거래 사이트를 둘러보고, 개인 정보와 신용 카드 데이터를 입력하여 상품을 구매한다. 트랜잭션이 제출된다.

2. 사용자가 제출한 데이터가 인터넷(공용 네트워크)을 통해 클라이언트에서 전자상거래 회사 웹서버로 전송된다.

3. 제출된 데이터가 회사 방화벽에 도달하면 방화벽은 패킷 헤더를 검사하여 사용된 프로토콜 유형(예, HTTP, HTTPS, FTP 등)을 판단한다. 방화벽 구성에 따라 보안 기준을 충족하는 패킷만 통과를 허용한다(예, HTTP와 HTTPS를 사용하는 패킷만 허용하고 FINGER와 FTP는 허용하지 않음).

4. 회사 웹서버는 패킷을 수신하고, 검사하고, 적절한 데이터 형식으로 분해한다. 유형(데이터, 함수 호출, 리디렉션 등)에 따라 웹서버가 데이터를 다른 프로세스(예, ISAPI DLL, CGI, ASP 프로그램, Java 서블릿, SQL 저장 프로시저 등)로 전달한다. 검증서버(verification server)가 웹서버에 의해 호출되며, 검증서버는 검증을 위해 사용자 데이터를 수신하고 결과를 가지고 은행 서버에 응답한다. 웹서버는 승인(authorization)을 위해 데이터를 은행 웹서버로 리디렉션한다.

5. 리디렉션된 데이터가 회사 방화벽에 도달한다. 방화벽은 패킷 헤더를 검사하여 데이터 통과를 허용해야하는지 결정한다(예, 도착 URL이 신뢰할 수 있는 URL이면 데이터 통과가 허용됨).

6. 회사가 제출한 데이터가 인터넷을 통해 은행으로 전송된다.

7. (은행 네트워크) 은행의 방화벽은 패킷 헤더를 검사하여 사용되는 프로토콜 유형을 결정한다. 방화벽의 구성에 따라 방화벽이 패킷 진행을 허용하거나 허용하지 않을 수 있다.

8. (은행 네트워크) 은행의 웹서버가 패킷을 수신하고, 검사하고, 적절한 데이터 형식으로 분해한다. 유형(데이터, 함수 호출, 리디렉션 등)에 따라 웹서버가 데이터를 다른 프로세스(예, ISAPI DLL, CGI, ASP 프로그램, Java 서블릿, SQL 저장 프로시저 등)로 전달한다.

9. (은행 네트워크) 웹서버에 의해 호출된 승인서버(authorization server)가 트랜잭션을 승인하기 위한 사용자 데이터를 수신한다(예, 주소 및 사용자 계정 이름을 확인하여 계정이 유효한지 확인, 트랜잭션 금액이 잔고액 내에 있는지 확인).

10. (은행 네트워크) 트랜잭션이 승인되었다고 가정했을 때 사용자와 판매자의 계정 데이터베이스가 적절한 차변(debit) 및 대변(credit) 정보로 업데이트된다.

11. (은행 네트워크) 승인 정보가 은행 웹서버에서 회사 웹서버로 다시 전송된다.

12. (은행 네트워크) 은행의 방화벽은 패킷 헤더를 검사하여 통과를 허용해야 하는지 결정한다.

13. 은행이 제출한 데이터가 인터넷을 통해 회사 웹서버로 전송된다.

14. 회사 방화벽은 다시 패킷 헤더를 검사하여 사용된 프로토콜 유형과 패킷 통과 허용 여부를 결정한다.

15. 회사 웹서버는 패킷을 수신하고, 검사하고, 적절한 데이터 형식으로 분해한다. 유형에 따라 웹서버가 데이터를 다른 프로세스로 전달할 수 있다.

16. 웹서버가 회사 회계 데이터베이스 서버를 호출한다. 회계 데이터베이스가 업데이트된다.

17. 회사 고객지원 데이터베이스가 업데이트된다.

18.a. 데이터가 회사 방화벽에 도달한다. 방화벽은 패킷의 통과를 허용해야 하는지 확인하기 위해 패킷 헤더를 검사한다.

18.b. 주문 처리 정보를 위해 고객지원 담당자가 데이터베이스에 액세스한다.

19. 트랜잭션 확인 데이터가 인터넷을 통해 사용자에게 전달된다.

20. 사용자가 구매 거래에 대한 확인을 받는다.

 

이 시나리오에서 테스팅이 처음에 지점 3과 5에 초점을 맞추어야 하며, 이어서 지점 14와 18.a로 테스팅 초점을 옮긴다(지점 7~12는 은행에서 발생하는 프로세스로 테스팅 범위를 벗어나는 블랙박스 활동으로 취급한다고 가정).

 

테스팅은 먼저 방화벽이 없는 환경(no-firewall environment)에서 시작해야 하는데, 방화벽 이슈를 조사하기에 앞서 기능에 특정한 이슈를 해소하기 위해서이다. 테스터가 찾아야 할 이슈로 방화벽 소프트웨어, 구성, 패킷 누락/분할을 유발하는 보안 방어로 인해 발생하는 애플리케이션 특정 에러가 있다. 예를 들어, 애플리케이션의 이메일 알림 기능이 SMPT 프로토콜을 사용하여 STMP 서버와 통신하는데 포트 25를 쓴다고 가정했을 때, 방화벽이 포트 25를 차단한다면 이메일 알림 기능이 실패할 것이다. 또 다른 예로 애플리케이션이 DMZ를 사용하는 네트워크 환경 내에 배포된다고 가정하자. 이 시스템의 웹서버와 애플리케이션 서버가 데이터베이스 서버로부터 분리되어 설계되었는데, 만약 웹서버는 DMZ에 데이터베이스 서버는 사설 네트워크 내부에 있다면 웹서버가 데이터베이스 서버에 대한 리퀘스트를 시작(initiate requests) 할 수 없어서 시스템이 실패하게 된다.

 

테스팅 고려사항(Testing Considerations)

일반적인 테스팅 고려사항

• 웹 시스템의 모든 컴포넌트는 각기 고유한 보안 취약점을 가지고 있다. 통상적으로 보안 방어가 요구되는 네 군데가 아래와 같다.
  - 클라이언트 시스템(웹 브라우저, 기타 애플리케이션 및 컴포넌트)
  - 서버(웹, 데이터베이스, 기타 서버)
  - 네트워크
  - 온라인 트랜잭션
• 소프트웨어 테스팅 팀이 아니라 조직의 보안 팀이 모든 보안 관련 이슈에 대한 정책을 결정한다(예, 사용자 액세스, 시간 제한, 콘텐츠 가용성, 데이터베이스 뷰, 시스템 보호, 보안 도구 등). 회사의 보안 방어가 충분히 안전한지 여부는 테스트 그룹이 결정할 사안이 아니다. 테스팅 그룹의 역할은 주로 애플리케이션 레벨에서 보안 구현 상의 에러를 찾기 위해 시스템을 테스트하는 것이다.
• 대개 IT 팀이 네트워크 보안에 대한 대부분의 책임을 진다. 일반적으로 소프트웨어 테스팅 팀 외의 사람이 방화벽 테스트, 패킷 카운팅, 트래픽 모니터링, 바이러스 보호, 서버 침입 테스트(server break-in testing)를 수행한다.
• 소프트웨어 테스팅 팀이 아니라 IT 팀이 IP 주소 차단 정책(IP address screening policies) 설치를 책임진다.
• 애플리케이션 에러 탐지 및 처리에 있어서의 결함을 찾는 것 뿐만아니라 기술 지원 지식 베이스를 위한 구성 관련 이슈를 수집하는 것을 테스팅 목표로 한다.

 

사용자 계정 암호, 로그인 절차 관련 테스팅 고려사항

• 웹 시스템에 자동 로그 오프 기능(예, 세션 시간 초과 시)이 있는가? 있다면 제대로 동작하는가?
• 웹 시스템이 빈번한 암호 변경을 구현하고 시행하는가? 이것이 제대로 동작하는가?
• 보안이 데이터베이스 서버 레벨이 아닌 애플리케이션 서버 레벨에서 제어되는 경우, 사용자 액세스가 적절하게 집행되는지 확인하기 위해 애플리케이션의 보안 로직이 테스트되었는가?
• 애플리케이션 레벨에서 시행되는 로그인 로직을 테스트 했는가? 데이터베이스 레벨에서 시행되는 로그인 로직을 테스트 했는가? 두 레벨 모두에서 시행되는 로그인 로직을 테스트 했는가?
• 웹 시스템에 통합되는 제3자 애플리케이션/컴포넌트에 대해 보안 관련 테스트를 수행했는가?
• 몇 번의 연속 로그인 실패가 허용되는가(예, 3회, 10회, 또는 무제한)? 이 기능을 사용자가 구성 파일이나 레지스트리 키에서 구성할 수 있는가? 그렇다면 누가 구성을 변경할 권한을 가지는가? 이 변경이 쉽게 해킹될 수 있는가?
• 실패 로그인 수가 초과되면 애플리케이션이 어떻게 반응하는가(예, 보안 이슈가 검토되거나 또는 보안 경고 타이머가 만료될 때까지 해당 IP 주소의 로그인을 불허함)?
• 사용자 이름과 암호에 어떤 로직이 적용되는가? 대소 문자를 구분하는가? 최소 문자 수 규칙이 있는가? 문자와 숫자를 조합해야 하는 혼합 규칙이 있는가? 이러한 로직의 구현이 제대로 동작하는가?
• 사용자 이름과 암호가 (사용자의 레지스트리 데이터베이스에 또는 .INI 파일 같은 구성 파일에) 암호화된 형식으로 저장되는가?
• 사용자 이름과 암호의 잘라내기(cut)와 붙여넣기(paste)를 시도해 보았는가?
• 북마크, 히스토리 엔트리, 캡처된 URL 등을 사용하여 로그인 절차 우회를 시도해 보았는가? 예를 들어, 시스템에 성공적으로 로그인 한 후 URL 캡처를 하고, 브라우저의 새 인스턴스를 시작하여 캡처된 URL을 붙여 넣으면 시스템에 들어갈 수 있는지 확인한다.
• HTTP 뿐만아니라 HTTPS를 사용하여 로그인을 테스트 했는가(시스템이 HTTPS를 지원한다고 가정)?
• 사용자 이름과 암호가 애플리케이션 레벨에서 암호화되었는가? 만약 그렇다면 이 기능이 테스트 되었는가?

 

권한부여 절차(authorization procedure) 측면에서 테스팅 고려사항

• 권한을 부여받은 모든 사용자가 시스템에 액세스 할 수 있는가?
• 권한이 없는 사용자가 시스템으로부터 차단되는가? 만약 권한 없는 로그인이 시도된다면 얼마나 쉽게 할 수 있는가?
• 첫 로그인 후 신규 암호 생성에서 사용자가 새로운 고유 암호를 선택하면 기존 디폴트 암호는 비활성화되는가?
• 선택한 암호가 지정된 요구사항(예, 길이, 문자/숫자 조합)을 충족하는가? 이 요구사항이 충족되지 않으면 어떻게 되는가?
• 사용자가 주기적으로 비밀번호를 변경해야 하는 경우 새 비밀번호를 선택하면 이전 비밀번호가 비활성화되는가?
• 로그인에 시간 제한이 있는 경우 인가된 기간과 인가되지 않은 기간 사이의 전환이 올바르게 처리되는가?
• 더 이상 쓸모 없는 사용자 계정 기능이 완전하고 정확하게 제거되고 비활성화되는가?
• 만료 기간이 있는 사용자 계정이 예정대로 만료되는가?

 

데이터베이스 서버 보안 측면에서 테스팅 고려사항

• 사용자에게 과도한 데이터베이스 권한이 부여되는가? 대부분의 데이터베이스 시스템에서 사용자는 자신의 책임과 관련된 특정 데이터에 대한 액세스 권한이 부여되며, 추가적으로 특정 사용자가 다른 사용자에게 특별 액세스 권한을 부여 할 수도 있다. 사용자가 적절한 데이터에 액세스 할 수 있고 그 외 모든 다른 데이터에는 액세스가 거부되는지 확인한다.
• 권한이 없는 사용자에게 특별 액세스 권한(special access privileges)을 부여 할 수 있는가?
• 특별한 액세스 권한을 특정 항목(items)으로만 제한 할 수 있는가?
• 특별 액세스 권한을 종료 할 수 있는가?
• 각 그룹의 사용자들이 필요에 맞는, 하지만 초과하지는 않는, 적절한 액세스 권한을 가지는가? 모든 사용자가 그룹 할당(group assignments)을 받는가? 사용자는 일반적으로 동일한 액세스 니즈를 공유하는 ‘개인 그룹’으로 분할된다.
• 뷰는 전체 테이블의 일부를 보여주는 제한된 테이블이며, 사용자는 뷰 내에서 보여지는 필드에만 액세스하고 편집할 수 있다. 사용자에게 보이려고 의도한 적절한 정보에 사용자가 개별 뷰를 통해 액세스 할 수 있고, 그 외 다른 모든 데이터는 차단되는지 테스트 한다. 또한 권한이 없는 사용자가 GUI 관리 도구나 SQL 문을 통해 뷰를 수정하지 못하도록 보호하는지 테스트 한다.
• 적절한 저장 프로시저를 실행하는데 필요한 권한이 사용자에게 부여되는가?
• 사용자가 작업을 수행하는데 필요한 것보다 더 많이 저장 프로시저에 액세스 할 수 있는가? 이들이 자신의 업무를 수행하는데 필요한 저장 프로시저에만 액세스 할 수 있어야 한다.
• 데이터베이스 관리자(database administrator)가 아닌 다른 사용자가 저장 프로시저를 생성, 수정 또는 삭제할 수 있는가? 이상적으로는 오로지 데이터베이스 관리자만 이러한 유형의 권한을 가져야 한다.

 

샘플 보안 테스트 계획표

아래는 보안 니즈(이행 전략 및 테스팅 요구사항)를 분석하는 데 사용한 보안 테스트 계획표의 예이다. 이 표는 테스팅을 포함한 보안 이슈의 여러 주요 측면 간의 상관관계를 보여준다.

 

먼저 보안 우려가 있는 활동 및 이슈를 식별하고, 이 정보를 첫 번째 컬럼 ‘활동(Activities)’에 입력한다. 다음으로 각 활동에 대해 누구를 보호하고자 하는지, 어떤 타입의 보호인지, 초점을 맞출 주요 영역(또는 타겟 영역)이 어디인지를 식별하고, 이 정보를 ‘보호(Protection)’와 ‘주 타겟(Primary Target)’ 컬럼에 각각 입력한다. 다음으로 각 활동에 적용되는 보안 조치 타입과 테스팅 구현을 식별하여 ‘보안 정책/이행(Security Policies/Implementation)’과 ‘테스팅 이슈(Testing Issues)’ 컬럼에 각각 입력한다. 이렇게 표가 완성되면 프로젝트 동안 쭉 보안 이행(security implementation)을 추적하고 의사소통하는데 사용할 수 있는 ”상위 레벨의 보안 계획 스냅샷”을 얻게 된다.