pupustory@

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

Pupustory Dev/Tip

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

그래서 오늘은 생각했다. 네이버에서 벗어날 수 있는 대안은 무엇인가?

더보려면 클릭!!

먼저 제일 많이 사용하는 email서비스. email서비스는 google이면 충분하다. 먼저 google를 살펴보면 기본에 충실하다. 이메일 서비스를 이용할때 무엇을 자주 이용하는가 ? 메일이 오면 확인하고, 답신을 보내는 기능이면 충분하다. 특히 컴퓨터를 하루종일 하고있는 사무직 직원들에겐 단순히 '구글 메일에 접속한 브라우저를 띄어두기만' 하면 충분 하다.

구글 메일은 기본적으로 ajax를 사용하므로 일정 시간뒤에 메일 정보를 다시 읽어온다. 신규 메일이 있다면, 타이틀바에 (1)가 추가되므로, 이를 통해 확인 할 수도 있다.

메일 보내기를 할때 실수로 뒤로가기 버튼이나 링크를 눌러 페이지가 이동되어도 걱정 없다. 일정 시간동안 임시 보관함에 저장되기 때문이다.

또 친구 등록을 통해 상대방이 구글 메일에 접속 했다면 실시간 채팅이 가능 하다. 채팅 역시 메일처럼 확인 할 수 있도록 되어있다. 일부 회사에서 막아둔 메신저를 피할 수 있는 방법이기도 하다.

마지막으로 필자가 가장 좋아하는 부분은 이부분이다. 필자가 상대방에게 이메일을 보냈다. 상대방은 다시 필자에게 답장을 보냈다. 다시 필자는 상대방에게 답장을 보냈다.

지 금 글을 작성하는 지금 네이버 메일의 경우 각각 개별적인 이메일로 취급된다. 하지만 구글 메일은 답장으로 온 메일은 하나의 묶으로 다음과 같이 처리된다. 답장을 보내는 것일 경우 보통 하나의 주제를 통해 보내게 되는 것이다. 이것이 길어지게 되고, 수십통의 답장(물론 이런경우는 흔치 않지만..)을 보내고 받았다면 이것으로만 해도 한 페이지가 되어버릴 것 이다. 하지만 구글메일은 이것을 묶음(탭이 더 가까울지도 ..?)으로 관리하므로 이전의 내용을 확인하기도 쉽고, 관리하기도 쉽다.

Pupustory Dev/Tip

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

 int main() { return 0; }

Pupustory Dev/Tip

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

Pupustory Dev/Tip

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

==================================

본문 출처 >> [  http://s4int.tistory.com/13  ]

==================================

취약한 환경 설정과 부주의, 취약한 소프트웨어로 인하여 WWW 연결을 통해 보안상 심각한 문제가 유발될 수 있다. WWW 서비스는 공개적으로 서비스를 제공하는 형태로 설계되었으며, 일반적으로 주요한 내부 자원을 외부에 제공하는 기능을 하도록 설계되었다. 따라서 이전의 외부로부터의 접근 통제가 가능하였던 보안솔루션에 의해 공격자를 막는 것은 사실상 불가능 하다.

OWASP(Open Web Application Security Project) 10 대 취약점을 요약하면 다음과 같다.

1. 검증되지 않은 파라미터의 허용(Unvalidated Parameters)

웹 요청 정보가 웹 애플리케이션에 의해 처리되기 이전에 그 요청이 적절한 값인지 여부를 검증하지 않음으로 인해 허가되지 않은 자원에 접근할 수 있는 취약성이다.

url, 쿼리 문, HTTP 헤더, 폼 필드, 쿠키, 그리고 숨겨진 필드 등의 웹 요청(HTTP request)들을 강제로 브라우징 한다거나 명령어 삽입, SQL 문 삽입, 쿠키 위/변조 등을 통해서 보안메커니즘을 우회할 수 있게 된다.

[대처 방안]

다음과 같이 스펙 상에 허용된 값만을 받아들이는 “허용(Positive) 방식”을 사용하여 인자를 검증하여야 한다.

n        데이터 유형 (문자열, 정수형, 실수형 등)

n        허용된 문자셋 (character set)

n        최대 / 최소 길이

n        Null 값의 허용 여부

n        반드시 필요한 인자와 그렇지 않은 인자

n        중복 허용 여부

n        숫자의 범위

n        타당한 것으로 지정된 값 (열거형 - enumeration 사용)

n        타당한 것으로 지정된 패턴 (정규식 사용)

2. 부적절한 접근 통제(Broken Access Control)

인증되지 않은 사용자가 시스템에 접근하여 중요한 파일 읽거나 권한 없는 기능들을 수행할 수 있는 취약성이다. 예를 들자면 허가되지 않은 사용자가 웹 요청을 통해서 유닉스 시스템의 /etc/passwd 파일을 읽거나 윈도우 시스템의 웹 루트 디렉터리를 읽을 수 있는 등의 경로 유출(Path Traversal)을 허용하는 것이다. 이러한 취약성은 웹 컨텐츠와 기능에 적절한 접근 통제를 하지 못하는 것이 원인이다.

[대처 방안]

다음과 같은 접근 통제를 점검한다.

n        취약한 ID – 대부분의 웹 사이트는 일정한 형태의 아이디, 키, 인덱스를 사용하여 각 사용자와 역할, 컨텐츠, 접근 대상, 기능들을 구분한다. 공격자가 이런 값들을 유추할 수 있고, 입력받은 값들이 현재 사용자에게 허용된 적절한 값인지를 검증하지 않는다면, 공격자는 무엇에 접근할 수 있는지를 파악하기 위해 접근 통제 메커니즘을 이리저리 조사해볼 것이다. 웹 애플리케이션의 보호를 위해 특정한 아이디 값이 가진 비밀에 의존해서는 안된다.

n        접근 통제 점검을 우회하기 위한 강제 접근(forced browsing) – 많은 사이트들은 사용자가 내부 ‘깊숙이’ 숨어있는 특정한 URL에 접속하는 것을 허용하기 이전에, 특정한 검사를 통과하도록 요구한다. 이런 검사는 단순히 보안 검사를 수행하는 페이지를 우회하는 것만으로 통과 가능해서는 안된다.

n        경로 이동(path traversal) – 이런 종류의 공격은 정보를 요청하는 일부분에서 상대 경로(예를 들면 “../../target_dir/target_file”)를 사용하는 것과 관련이 있다. 이런 공격은 정상적인 방법으로는 직접적으로 접근 불가능하거나, 직접적으로 접근하는 경우 서버 측에서 거부하는 파일들에 접근하려고 시도할 때 사용한다. 이런 공격은 URL 이나 궁극적으로는 파일에 액세스하는데 사용되는 값(즉 시스템 콜이나 쉘 명령어)을 서버 측에 요청할 때 사용할 수 있다.

n        파일 허가권 – 많은 웹 서버와 웹 애플리케이션 서버는 OS의 파일 시스템에 의해 제공되는 접근 통제 항목에 의존하고 있다. 비록 거의 모든 데이터가 백엔드 서버에 저장되어 있다 하더라도, 웹 서버나 웹 애플리케이션 서버에 로컬로 저장되어 외부에서 접근할 수 없는 파일들은 항상 있게 마련이다. 이런 파일들에는 특정한 환경 설정 파일, 디폴트 예제 파일, 상당수의 웹 서버나 웹 애플리케이션 서버에 설치되는 예제 스크립트들이 있다. 웹 사용자들에 의해 접근 가능한 파일들만이 OS의 허가권 메커니즘을 사용해 명시적으로 읽기 가능하도록 설정되어야 하며, 대부분의 디렉터리에 대해선 읽기 권한을 제거해야 한다. 필요한 경우 극소수의 파일들에 대해서만 실행 권한을 주어야 한다.

n        클라이언트 측 캐쉬 – 많은 사용자들이 도서관, 학교, 공항, 혹은 다른 공공 장소에 설치된 공용 컴퓨터에서 웹 애플리케이션에 접속한다. 브라우저는 종종 웹 페이지를 캐쉬하는데, 이 캐쉬된 정보는 공격자가 이외의 다른 방법으로는 접근할 수 없는 사이트에 접속하기 위해 필요로 하는 정보이다. 개발자는 HTTP 헤더, 메타 태그 등 다양한 메커니즘을 사용하여 민감한 정보가 담겨있는 페이지가 사용자의 브라우저에 캐쉬되지 않도록 보장해야 한다.

3. 부적절한 계정과 세션 관리(Broken Account and Session anagement)

계정에 대한 증명(Account Credential)과 세션 토큰이 적절히 보호되지 못함으로 인해 패스워드나 키, 세션 쿠키, 그리고 다른 토큰 등을 악용하여 인증 메커니즘을 무력화 시키거나 다른 사용자의 아이디를 추측할 수 있는 취약성이다. 예를 들자면 사용자의 패스워드 변경, 패스워드 분실, 사용자 정보 수정 등을 포함하는 증명서와 동적 세션 관리가 적절히 개발되지 않아서 다른 사용자에 의해 추측되거나 가로채기를 당하는 것이다.

[대처 방안]

다음과 같은 항목들에 대해 보안 정책을 강화한다.

n        강력한 패스워드 – 패스워드는 최소 길이와 복잡도에 제한을 두어야 한다. 일반적으로 복잡한 패스워드라 함은 최소한 알파벳, 숫자, 특수 문자(최소 한 개 이상)를 조합하는 것을 요구한다. 사용자는 주기적으로 패스워드를 변경하여야만 하며, 이전에 사용하던 패스워드를 재사용하지 못하도록 해야 한다.

n        패스워드 사용 – 사용자는 일정 시간 이내에 일정 횟수 이상의 로그인 시도를 할 수 없으며, 로그인 시도가 지속적으로 실패하는 경우 이를 로그에 기록하여야 한다. 로그인 실패 시 사용자가 입력한 패스워드는 서버 측에 기록하지 말아야 한다. 이런 정보는 서버의 로그 파일에 접근할 수 있는 누군가가 다른 사용자의 패스워드를 파악하는데 사용될 수 있기 때문이다. 해당 시스템은 로그인 시도 실패 시 틀린 부분이 사용자명인지 패스워드인지를 명시하지 말아야 한다. 사용자는 이전 로그인의 성공 날짜와 시간, 그 이후로 몇 번이나 접속 시도가 실패했는지에 대한 정보를 받아볼 수 있어야 한다.

n        패스워드 변경 통제 – 사용자의 패스워드 변경이 허용된다면, 패스워드 변경 메커니즘은 어떤 상황에서도 단 하나만을 사용하여야 한다. 사용자가 패스워드를 변경할 때는 다른 계정 정보를 변경할 때와 마찬가지로 항상 이전 패스워드와 신규 패스워드를 물어보아야 한다. 해당 시스템 상에서 분실된 패스워드를 사용자에게 전자 메일로 발송한다면, 사용자가 전자 메일 주소를 바꾸려고 할 때도 항상 이런 인증 절차를 거치도록 해야 한다. 그렇지 않은 경우 공격자가 일시적으로 다른 사용자의 세션을 이용해 접속하여(예를 들면, 다른 사용자가 로그인해 있는 상태로 자리를 잠시 비운 사이 컴퓨터 앞으로 걸어가서) 해당 전자 메일 주소를 변경하고, ‘분실한’ 패스워드를 메일로 보내달라고 요청하는 상황이 벌어질 수 있다.

n        패스워드 저장 – 모든 패스워드는 유출 사고로부터 보호하기 위해, 어디에 저장되는지에 상관없이 해쉬된 형태나 암호화된 형태로 저장되어야만 한다. 보통 해쉬 방식을 선호하는데 이 정보는 복호화할 수 없기 때문이다. 평문 패스워드를 사용하면서 이 패스워드를 전달하여 다른 시스템에 로그인 하는 경우에는 반드시 암호화를 사용하여야만 한다. 패스워드는 소스 코드 내부에 하드 코딩하는 일이 없어야 한다. 복호화에 사용되는 키는 해당 키를 습득하여 패스워드 파일을 복호화 하는데 사용할 수 없도록 강력하게 보호되어야만 한다.

n        전송 중의 자격 증명 보호 – 가장 효과적인 방법은 SSL과 같은 기술을 사용하여 로그인 트랜잭션 전체를 암호화하는 방법이다. 서버로 전송하기 이전에 클라이언트 단에서 패스워드를 해쉬하는 형태로 변경하는 단순한 방법으로는, 다른 공격자가 실제 패스워드를 모르는 상태에서 해쉬된 정보를 가로채어 서버로 그대로 전송하는 일이 발생하는 경우 별다른 보안을 제공하지 못한다.

n        세션 ID 보안 – 사용자의 전체 세션은 이상적으로는 SSL을 이용하여 보호되어야만 한다. 이런 경우에는, 세션 ID 유출을 불러오는 가장 심각한 위험인 세션 ID(예를 들면 세션 쿠키)를 네트워크 상에서 도청하는 방법이 별 소용이 없다. 그러나 속도 문제 혹은 다른 이유로 인해 SSL을 사용할 수 없는 경우라면, 다른 방법을 사용하여 세션 ID를 보호하여야만 한다. 첫째로 세션 ID를 URL에 포함하지 않아야 한다. 이렇게 하는 경우 해당 정보가 브라우저에 캐쉬될 수 있으며, referrer 헤더를 통해 전달될 수 있고, 실수로 ‘친구’에게 포워딩할 수도 있다. 세션 ID는 충분히 길고 복잡한 난수여서 손쉽게 추측할 수 없어야 한다. 세션 ID는 세션이 유지되는 중에도 자주 바뀌어 세션 ID가 타당하다고 받아들여지는 시간을 줄여야 한다. 세션 ID는 SSL로 전환되는 시기, 인증을 거칠 때 혹은 다른 중요한 변화가 있는 시기에 다른 값으로 변경되어야 한다. 사용자가 세션 ID를 임의로 선택하여 사용하는 일은 허용되지 않아야 한다.

n        계정 리스트 – 시스템은 사이트의 계정 리스트에 사용자가 접근하는 것을 허용하지 않도록 설계되어야만 한다. 사용자 리스트를 반드시 제공해야 한다면, 직접적으로 계정명을 제공하기 보다는 별명(예명)과 같은 다른 형태를 제공하기를 권한다. 이렇게 하는 경우, 해당 별명을 이용해 로그인 시도를 할 수 없으며, 사용자 계정을 공격하기 위한 다른 해킹을 시도할 수 없다.

n        브라우저 캐쉬 – 인증 및 세션 관련 정보는 GET 요청의 일부에 포함되어 전송되어선 안된다. 이런 경우에는 대신 POST 요청을 사용하여야 한다. 인증 페이지는 다양한 형태의 캐쉬 금지 태그를 이용함으로써 사용자가 브라우저의 ‘뒤로’ 버튼을 이용하여 인증 페이지로 돌아가지 못하도록 하고, 이전에 사용한 사용자 자격 증명을 재사용하지 못하도록 하여야 한다. 요즘의 여러 브라우저들은 autocomplete=false 플래그를 지원하여, 사용자 자격 증명을 자동완성 캐쉬에 저장하지 못하도록 하고 있다.

n        신뢰 관계 – 사이트의 아키텍쳐 상에서 가능한한 각 컴포넌트들 사이의 암묵적인 신뢰 관계를 피해야 한다. 각각의 컴포넌트는 그래서는 안되는 절대적인 이유가 있는 경우(속도나 가용성 문제와 같은)를 제외하고는, 서로 관련을 맺고 있는 다른 컴포넌트에 대해 인증을 수행토록 해야한다. 만일 신뢰 관계가 필요한 경우라면 강력한 절차상의 메커니즘 혹은 아키텍쳐 메커니즘을 사용하여 사이트의 아키텍쳐가 지속적으로 변화하더라도 이러한 신뢰 관계가 악용될 수 없도록 해야 한다.

4. 크로스 사이트 스크립팅 허점(Cross-Site Scripting(XSS) Flaws)

Cross-site Scripting 취약점은 공격자가 웹 애플리케이션을 사용해서 다른 최종 사용자에게 자바스크립트와 같은 악성 데이터를 보낼 때 발생한다. 그 데이터는 클라이언트에서 실행되는 Java스크립트, VB스크립트, ActiveX, Flash등을 실행하는 코드들이 존재하게 된다. 최종 사용자들은 이렇게 악성 코드들이 포함된 웹 사이트의 링크를 클릭하거나 이메일에 포함된 내용을 읽거나 BBS에 게시된 게시물을 클릭하는 것만으로도 사용자의 환경 설정사항을 변경하거나, 쿠키(cookie)를 가로채고 잘못된 광고들 게시하는 등의 일들을 할 수 있다.

[대처 방안]

XSS 공격으로부터 웹 애플리케이션을 방어하는 최선의 방법은 애플리케이션 차원에서 HTTP 헤더, 쿠키, 쿼리 스트링, 폼 필드, 히든 필드 등의 모든 인자들에 대해 허용된 유형의 데이터만을 받아들이도록 입력값 검증을 실시하는 방법이다. 다음과 같이 왼쪽의 필드의 입력 데이터를 오른쪽의 필드로 변환해서 필터링한다.

5. 버퍼 오버플로우(Buffer Overflows)

웹 애플리케이션 컴포넌트가 사용자의 입력값을 적절히 점검하지 않는 언어로 작성되어 다운될 수 있으며, 특수한 경우에는 공격자가 해당 프로세스의 권한을 획득할 수 있다. 이 컴포넌트로는 CGI, 라이브러리, 하드웨어 드라이버, 웹 애플리케이션 서버 컴포넌트 등이 포함된다.

[대처 방안]

운영하고 있는 웹 서버 버전을 가장 최신버전으로 업그레이드 하거나 알려진 취약점을 제거할 수 있는 패치를 적용한다. 정기적으로 취약점 스케너를 통해서 취약점 여부를 점검하여 발견된 취약점에 대해서는 구성 설정을 변경하거나 패치를 적용하여 취약점을 제거한다.

6. 시스템 명령어 삽입 허용(Command Injection Flaws)

웹 애플리케이션에서 HTML 형식이나 쿠키, URL 파라미터 형식으로 시스템 명령어를 삽입허용함으로써 웹 상에서도 시스템 명령을 실행할 수 있는 취약점이다. SQL 쿼리문을 삽입허용하게 되면 DB인증 메커니즘을 무력화시켜서 중요한 데이터베이스 정보를 외부로 유출할 수 있다. 또한 데이터베이스의 DML(Data Manipulation Language), DDL(Data Definition Language) 언어가 모두 사용 가능하므로 데이터베이스의 유출뿐만이 아니라 무결성을 파괴할 수도 있다.

 [대처 방안]

n        반드시 필요하다면 모든 시스템 명령을 사용하는 모든 사용자의 입력값을 점검한다.

n        점검되지 않은 사용자 입력을 시스템 명령으로 전달하지 않는다.

n        점검되지 않은 사용자 입력을 파이프(|)로 전달하지 않는다.

n        점검되지 않은 사용자 입력을 perl의 open() 명령으로 전달하지 않는다.

n        점검되지 않은 사용자 입력을 C 언어와 PHP의 popen() 명령으로 전달하지 않는다.

n        점검되지 않은 사용자 입력을 ``(backticks)과 함께 사용하지 않는다.

n        운영체제의 시스템 명령이 사용자 입력에 존재하는지 점검한다.

n        모든 웹 애플리케이션엔 쉘 스크립트를 허용하지 않는다.

7. 부적절한 에러처리(Error Handling Problems)

적절하지 못한 오류 처리는 웹 사이트에서 다양한 보안 문제를 야기한다. 가장 보편적인 문제는 데이터베이스 덤프, 에러 코드등과 같은 상세한 내부 메시지들이 사용자에게 노출된다는 것이다. 이러한 정보들은 바로 악용 가능하지는 않지만 향후 발생할 수 있는 공격에 정보를 제공하게 된다. 이러한 문제를 야기하는 원인은 다음과 같다.

n        스크립팅 엔진의 설정 오류

n        Servlet/JSP Runner의 설정 오류

n        웹 서버의 설정 오류

n        데이터베이스의 설정 오류

이러한 문제를 통해 유출될 수 있는 정보들은 다음과 같다.

n        애플리케이션의 흐름

n        추가적인 웹 서버 정보

n        데이터베이스 형식 및 버전

n        운영체제 형식 및 버전

n        Scripting/Programming 언어의 형식 및 버전

n        물리적인 경로

n        변수 이름과 값

n        변수 형식

n        변수의 사용 목적

n        스크립트 소스 코드의 세그먼트

n        SQL 쿼리의 세그먼트

n        데이터베이스와 테이블의 구조

[대처 방안]

웹 애플리케이션이 잘못된 요청을 받았을 때 자체 제작한 오류 페이지로 이동하도록 설정한다.

8. 취약한 정보 저장방식

대부분의 웹 애플리케이션은 패스워드, 신용카드 번호, 계정 기록과 같은 중요한 정보나 데이터베이스를 저장하고 있기 때문에 암호화 기술을 이용하여 보호하고 있다. 이러한 암호화 기술이 웹 애플리케이션에 적용될 때 다음과 같은 구현상의 오류로 인하여 보안 허점들을 내포하게 된다.

n        중요 데이터를 암호화하지 않는 경우

n        암호화에 사용되는 키나, 인증서, 비밀번호를 안전하지 않은 장소에 저장하는 경우

n        기밀 정보를 메모리 상에 부적절하게 저장하는 경우

n        부적절한 난수 발생 방법

n        부적절한 암호화 알고리즘 사용

n        자체 제작 암호화 알고리즘 사용

n        암호화에 사용되는 키 교환에 대한 지원 절차나 다른 유지 관리 절차를 구현하지 않는 경우

[대처 방안]

암호화 취약점에 대한 가장 손쉬운 대처 방안은 암호화 사용을 최소한으로 자제하고 반드시 필요한 정보만을 저장하는 것이다. 예를 들면 신용 카드 번호를 암호화하여 저장하기 보다는 필요할 때마다 사용자가 해당 번호를 집어넣게 한다. 암호화된 비밀번호를 저장하기 보다는 SHA-1과 같은 단방향 함수를 사용한다.

9. 서비스 방해 공격(Denial of Service)

웹 애플리케이션 측면에서는 공격과 정상적인 트래픽 사이의 차이를 구분하기 어렵다. 이런 구분을 어렵게 하는 다양한 요소들이 있지만, 다른 원인들 중에 가장 중요한 원인은 IP 주소만으로는 신원 확인이 어렵다는 점이다. HTTP 요청이 어디에서 들어왔는지를 파악할 신뢰할만한 방법이 없기 때문에 악의적인 트래픽을 필터링하기가 매우 어렵다.

[대처 방안]

기본적으로 서비스 방해 공격을 막아내는 것은 어려우며, 이런 공격을 완벽하게 방어할 수 있는 방법은 존재하지 않는다.

일반적인 규칙은 모든 사용자에게는 제한된 자원만을 할당하고 인증을 거친 사용자는 할당량을 통해 특정 사용자가 시스템에 미치는 부하를 제한할 수 있다.

인증받지 않은 사용자에 대해서는 불필요한 데이터베이스 접근이나 다른 값비싼 자원에 대한 접근을 피해야 한다.

10. 웹과 애플리케이션 서버의 구성 설정상의 오류(Web and Application Server Misconfiguration)

웹 서버와 애플리케이션의 구성 설정은 보안 측면에서 중요한 의미를 가진다. 그러한 구성설정들이 다음과 같은 여러 가지 요인들로 인해 보안 문제를 야기할 수 있다. 이러한 보안문제들은 자동화된 스케닝 도구에 의해 공격자들에 의해 공격 당할 가능성이 매우 높다.

n        서버 소프트웨어 상에 존재하는 취약점을 패치하지 않은 경우

n        디렉터리 리스팅이나 디렉터리 이동(traversal) 공격을 허용하는 서버 소프트웨어 상의 취약점이나 취약한 환경 설정

n        불필요한 디폴트 파일, 백업 및 예제 파일(예제 스크립트, 예제 애플리케이션, 환경 설정 파일, 웹 페이지 등)

n        부적절한 파일 및 디렉터리 권한 설정

n        컨텐츠 관리나 원격 관리와 같은 불필요한 서비스 제공

n        디폴트 패스워드를 사용하는 디폴트 계정

n        디버깅 관련 기능이 허용되어 있거나 관리 기능이 접근 가능한 경우

n        상세한 정보를 제공하는 에러 메시지(보다 상세한 사항은 에러 처리 부분을 참조)

n        잘못 설정된 SSL 인증서와 암호화 설정

n        자체 인증서를 사용하여 인증 문제를 해결하거나 가로채기 공격(man-in-the-middle)에 대한 보안을 제공

n        디폴트 인증서 사용

n        외부 시스템을 이용한 부적절한 인증

[대처 방안]

n        최근에 발표된 보안 취약점 정보 파악

n        최신 보안 패치 적용

n        보안 강화 가이드라인의 업데이트

n        정기적인 내, 외부 취약점 스캐닝

n        보안 강화 가이드라인 준수 여부를 점검하기 위한 서버 보안 현황 내부 감사

n        전체 보안 현황을 문서화하여 경영진에게 정기적으로 보고

 [참고 자료]

OWASP Top Ten Most Critical Web Application Security Vulnerabilities (http://www.owasp.org)

Pupustory Dev/Tip