Notice
Recent Posts
Recent Comments
Today
Total
05-02 00:04
Archives
관리 메뉴

Jeongchul Kim

15 기타 웹 보안 취약점 본문

정보 보호

15 기타 웹 보안 취약점

김 정출 2016. 2. 18. 13:28

15 기타 웹 보안 취약점



기타 웹 보안 취약점

1. 보안 설정 취약점

기타 웹 보안 취약점

OWASP에서 발표한 웹 주요 취약점 10개 중 이번 시간에 살펴볼 5가지에는 보안 설정 취약점, 취약한 정보 저장 방식, URL 접근 제한 실패, 인증 시 비암호화 채널 사용, 부적절한 오류 처리와 같은 취약점이 있습니다.

각각에 대해 자세히 알아보도록 할까요?

OWASP가 발표한 웹 취약점 중 보안 설정 취약점은 웹 서버에 대한 제대로 된 보안 설정을 하지 않아서 발생됩니다. 보안 설정 취약의 원인으로는 디렉터리 리스팅, 백업 및 임시 파일 존재, 주석 관리 미흡 등이 있습니다.



디렉터리 리스팅이란 웹 브라우저에서 웹 서버의 특정 디렉터리를 열면 그 디렉터리에 있는 파일과 목록이 모두 나열되는 것을 말합니다. 실제 디렉토리 리스팅이 가능한 웹 사이트에 접근 시 웹 브라우저에서 화면과 같이 해당 서버의 디렉토리 구성을 확인할 수 있습니다. 웹 서버의 파일 구조가 외부에 노출되어 공격을 위한 자료로 활용되거나, 부적절한 접근이 이루어질 수 있습니다.



보안 설정 시 백업 및 임시 파일이 존재하는 것도 취약점 중의 하나입니다. 웹 서버에 백업 파일이나 임시 파일을 삭제하지 않고 방치할 경우 이로 인해 취약점이 발생할 수 있습니다. 시스템 자체에 대한 취약점이 될 수도 있지만, 백업 및 임시 파일을 공격자가 획득, 분석하여 웹 애플리케이션의 내부 로직이나 데이터베이스 접속 정보 등을 획득하면 추가적인 피해가 발생할 수 있습니다.


주석 관리 미흡으로도 보안 설정 취약점이 발생할 수 있습니다. 주석은 프로그램을 개발하는 개발자가 프로그램에 대해 써 놓은 간략한 설명문입니다. 일반적으로 프로그램의 주석은 개발자만 볼 수 있으나, 웹 애플리케이션은 웹 프록시를 통해 이용자도 볼 수 있습니다. 주석에는 개발 과정이나 웹 애플리케이션의 관리를 목적으로 주요 로직에 대한 설명, 디렉터리 구조, 텍스트 소스 정보 등의 여러 가지 정보가 기록될 수 있으니 주석에 기록되는 정보를 주의하고 주석이 일반 사용자나 외부인에게 노출되지 않도록 하는 것이

좋습니다.


2. 취약한 정보 저장 방식

취약한 정보 저장 방식으로 발생하는 취약점은 중요한 정보가 외부에 노출되었을 때 큰 문제가 발생합니다. 개인 정보 유출의 중요한 원인은 웹 취약점뿐만 아니라, 많은 웹 애플리케이션이 신용카드번호, 주민등록번호, 그리고 인증 신뢰 정보와 같은 민감한 데이터를 보호하지 않기 때문에 발생합니다. 시스템에 다른 취약점으로 인해 웹 서버에 저장된 신용카드번호, 주민등록번호 등이 노출된 경우 추가적인 피해가 발생할 수 있습니다.

따라서 웹 서버에 개인의 민감한 정보를 저장할 때 보호하려는 데이터의 중요도에 따라 암호화 로직을 사용하고, 데이터베이스 테이블 단위에서 암호화를 수행해야 해야 합니다.

3. URL 접근 제한 실패

URL 접근 제한 실패에 대한 관리를 소홀히 한 경우에도 취약점이 발생할 수 있습니다. 관리자 페이지나 인증이 필요한 페이지에 대한 인증 미처리로 인해 인증을 우회하여 접속할 수 있게 된 경우 일반 사용자나 로그인 하지 않은 사용자가 관리자 페이지에 접근하여 관리자 권한의 기능을 악용할 수 있습니다.

URL을 보호하는 유일한 방법은 그 페이지의 연결 주소를 권한 없는 사용자들에게 보여주지 않는 것입니다. 하지만 동기를 갖고 숙련되거나 혹은 단지 운이 좋은 공격자는 이러한 페이지를 찾아 접근하여 기능을 이용하거나 데이터를 볼 수도 있습니다. 따라서 민감한 기능을 수행할 수 있는 페이지에 접근할 때 적절한 수순의 접근 통제가 보장되어야 합니다.


정상적인 접근은 관리자로 로그인 한 후에 관리자 전역 웹 페이지에 접속해야 하지만 인증 우회로 로그인 페이지를 거치지 않고 바로 관리자 페이지에 접근을 허용할 때 발생할 수 있습니다. 또한 관리자들이나 특별한 사용자들에게만 보이는 페이지도 존재합니다.

따라서 이러한 인증 후회를 막기 위해서는 웹에 존재하는 중요 페이지에 세션값을 확인하는 검증 로직을 입력해야 합니다.


4. 인증 시 비암호화 채널 사용

이번에는 인증 시 비암호화 채널 사용으로 발생하는 취약점에 대해서 알아보겠습니다. 최근 인터넷 뱅킹과 같은 서비스가 대중화되면서 웹 페이지와 사용자 사이의 트래픽에 대한 암호화가 중요한 요소가 되었습니다. 암호화 알고리즘이 약하거나 암호화하는 구조에 문제가 있다면 공격자가 웹 트래픽을 분석하여 중요한 데이터가 노출되거나, 위변조가 가능합니다.

암호화(보통 SSL)는 모든 인증된 연결에 사용해야 합니다. 암호화는 웹 페이지에 대한 접근 이외에도 백엔드 연결에도 암호화가 필요합니다.또한 암호화는 신용카드나 건강 정보들과 같은 민감한 데이터를 전송할 때에는 반드시 사용해야 합니다. 암호화를 사용하지 않거나, 암호화 모드를 해제할 수 있는 애플리케이션은 해커에 의해 악용될 수 있습니다.


자격 증명이나 신용카드 상세정보, 건강보험 그리고 사적인 정보 등의 민감하거나 중요한 데이터는 SSL을 사용하여 연결합니다.

자격 증명과 고유의 데이터 값을 위한 전송 계층 보안 또는 프로토콜 수준 암호화를 사용함에 의해 웹 서버나 데이터베이스 시스템과같은 하부 구조 사이의 통신이 적절하게 보호되어야 합니다.

5. 부적절한 오류 처리

오류는 스택 추적 정보, 실패한 SQL 명령문 또는 기타 디버그 정보 등과 같이 너무 많은 정보를 보여주는 에러가 포함된 세부적인 에러 처리 때문에 발생합니다. 다른 입력 값을 기반으로 다른 결과값을 생성하는 기능으로 예를 들어, 로그인 함수에 같은 사용자 이름을 제공하지만 다른 패스워드를 제공한 경우, 사용자 없음과 틀린 패스워드라는 동일한 메시지를 제공하여 하는 것이 좋습니다.

그렇다면 오류 처리에 대한 보호 방법에는 무엇이 있을까요?

예외 처리를 하기 위해 일반적인 접근 방법을 전체 소프트웨어 개발팀이 공유하거나, 자세한 오류 처리를 제한하거나 기능을 비활성화하는 것이 좋습니다. 또한 대략 동일 시간대에 유사하거나 동일한 에러 메시지의 다양한 결과를 응답하도록 보안 경로를 확보하는 것이 좋습니다.


6. 웹의 취약점 보완을 위한 기본적인 방법

그럼 웹의 취약점을 보완하기 위해 어떤 방법이 있을까요?

특수문자 필터링과 서버 측 통제작용, 지속적인 세션 관리 세 가지로 나누어 볼 수 있습니다.

각각에 대해 자세히 알아보도록 할까요?

특수문자 필터링은 웹 해킹의 가장 기본적인 형태 중 하나인 인수 조작하는 방법입니다. 인수 조작은 예외적인 실행을 유발시키기 위해 일반적으로 특수문자를 포함합니다. 따라서 특수문자의 입력을 차단하면 웹 해킹의 가능성도 줄어들게 됩니다.


XSS 공격, SQL 삽입 공격, 디렉터리 탐색에 사용되는 특수 문자는 다음과 같습니다.

다음과 같이 ASP코드를 수정하면 아이디와 패스워드를 넣는 부분에 문자열을 입력 받지 못하도록 합니다. 코드를 수정 후 특수문자를입력한 경우 ‘입력할 수 없는 문자입니다’라는 메시지를 사용자에게 보여 줍니다.

다음으로는 특수문자를 제거하는 함수를 이용하는 것입니다. 다음의 함수를 이용하면 특수문자를 본문에서 제거할 수 있습니다.


이번에는 서버 측 통제 작용에 대해 알아보도록 할까요? CSS 기반의 언어는 웹 프록시를 통해 웹 브라우저에 전달되기 때문에웹 프록시를 통해 전달되는 과정에서 변조될 가능성이 있습니다. 따라서 CSS 기반의 언어로 필터링 할 경우 공격자가 필터링 로직만 파악하면 쉽게 필터링이 무력화될 수 있습니다.

따라서 필터링 로직은 ASP, JSP 등과 같은 SSS로 필터링을 수행해야 하는 것이 바람직합니다.


웹 취약점을 보완하기 위한 세 번째 방법은 지속적인 세션 관리입니다. 웹 서비스에 대한 접근 통제는 지속적인 세션 관리로 이루어지는데 URL 접근 제한 실패를 막기 위해서는 기본적으로 모든 웹 페이지에 세션에 대한 인증을 수행해야 합니다.

모든 웹 페이지에 대해 일관성 있는 인증 로직을 적용하려면 기업 단위에서 또는 웹 사이트 단위에서 세션 인증 로직을 표준화해야 하고, 모든 웹 페이지를 개발할 때 해당 표준을 준수하도록 하는 것이 좋습니다.


'정보 보호' 카테고리의 다른 글

17 디지털 포렌식의 증거 수집  (0) 2016.02.18
16 디지털 포렌식의 개요  (3) 2016.02.18
14 주요 웹 보안 취약점  (2) 2016.02.18
13 웹 해킹의 이해  (1) 2016.02.15
12 네트워크 기반 공격  (1) 2016.02.13
Comments