|
■ OWASP Top10 2010
OWASP(Open Web Application Security Project)1 에서는 매년 웹 어플리케이션 환경에서 가장 중요한 위협 10 가지2를 선정하여 발표하고 있다. 이를 통해 웹 어플리케이션 보안의 취약점을 인식하고, 예방함으로써 관련 공격으로 인한 피해를 줄이고자 하는 목적을 가지고 있다. 이번 ASEC리포트 Vol.6에서는 최근에 발표된 OWASP Top 10을 통해 우리에게 다가온 웹 어플리케이션 위험과 예방 방법에 대해서 알아보자.
1. 인젝션
가. 위험
- SQL, OS, LDAP 인젝션과 같은 인젝션 결함은 신뢰할 수 없는 데이터가 명령어나 질의어의 일부분으로써 인터프리터에 보내 질 때 발생한다.
- 공격자의 악의적인 데이터는 예기치 않은 명령 실행이나 권한 없는 데이터에 접근하도록 인터프리터를 속일 수 있다.
나. 예방법
- 인젝션을 방지하려면 신뢰할 수 없는 데이터를 명령어와 질의로부터 항상 분리해야 한다.
2. 크로스사이트 스크립팅(XSS)
가. 위험
- XSS 결함은 적절한 확인이나 제한 없이 어플리케이션이 신뢰할 수 없는 데이터를 갖고, 그것을 웹 브라우저에 보낼 때 발생한다.
- XSS는 공격자가 피해자의 브라우저 내에서 스크립트의 실행을 허용함으로써, 사용자의 세션을 탈취하거나, 웹사이트를 변조하거나, 악의적인 사이트로 사용자를 리다이렉트 할 수 있다.
나. 예방법
- XSS를 방지하려면 활성 브라우저 콘텐츠와 신뢰할 수 없는 데이터를 항상 분리해야 한다.
3. 취약한 인증과 세션 관리
가. 위험
- 인증과 세션 관리와 연관된 어플리케이션 기능은 종종 올바로 구현되지 않는다. 그 결과, 공격자로 하여금 다른 사용자의 신분으로 가장할 수 있도록 패스워드, 키, 세션 토큰 체계를 위태롭게 하거나, 구현된 다른 결함들을 악용할 수 있도록 허용한다.
나. 예방법
- 개발자들은 아래와 같은 권장사항을 준수하여야 한다.
. 강력한 인증 및 세션 관리 통제의 단일체계를 유지해야 한다.
. 세션 ID를 도용하는데 사용될 수 있는 XSS 취약점을 막기 위해 노력해야 한다.
4. 안전하지 않은 직접 객체 참조
가. 위험
- 직접 객체 참조는 파일, 디렉토리, 데이터베이스 키와 같이 내부적으로 구현된 객체에 대해 개발자가 참조를 노출할 때 발생한다.
- 접근 통제에 의한 확인이나 다른 보호가 없다면, 공격자는 이 참조를 권한 없는 데이터에 접근하기 위해 조작할 수 있다.
나. 예방법
- 사용자 혹은 세션 당 간접 객체 참조를 이용한다.
- 신뢰할 수 없는 소스로부터 직접 객체 참조가 사용되면, 각각의 사용에 대해 요청한 객체가 사용자에게 접근이 허용되었는지 확인하기 위해서 반드시 접근 통제 확인을 포함해야만 한다.
5. 크로스 사이트 요청 변조(CSRF)
가. 위험
- CSRF 공격은 로그온된 피해자의 브라우저가 취약한 웹 어플리케이션에 피해자의 세션 쿠키와 어떤 다른 자동으로 포함된 인증 정보를 갖고 변조된 HTTP 요청을 보내도록 강제한다.
- 이것은 공격자가 피해자의 브라우저로 하여금 취약한 어플리케이션이 피해자로부터의 정당한 요청이라고 착각하게 만드는 요청들을 생성하도록 강제하는 것을 허용한다.
나. 예방법
- CSRF를 예방하는 방법은 각각의 HTTP 요청 URL이나 Body 내에 예측할 수 없는 토큰을 포함하는 것이다. 생성된 토큰은 최소한 사용자 세션 별로 반드시 고유값을 사용하되 각각의 요청마다 고유할 수도 있다.
6. 보안상 잘못된 구성
가. 위험
- 훌륭한 보안은 어플리케이션, 프레임워크, 어플리케이션 서버, 웹 서버, 데이터베이스 서버와 플랫폼에 대해 보안 구성이 제대로 정의되고 적용되도록 용구 한다.
- 대부분이 보안을 기본적으로 탑재하지 않기 때문에 이 모든 설정은 정의되고, 구현되고, 유지되어야 한다. 이것은 어플리케이션에서 사용되는 모든 코드 라이브러리를 포함하여 모든 소프트웨어가 최신의 상태를 유지하는 것을 포함한다.
나. 예방법
- 적절히 보호되는 또 다른 환경 구축을 쉽고 빠르게 만들 수 있는 반복 가능한 보안 강화 프로세스는 개발, 품질 보증, 생산 환경 모두에서 동일하게 구성되어야 한다.
- 모든 새로운 소프트웨어 업데이트와 패치를 각각의 배치환경에서 시기 적절하게 배포와 최신 수준을 유지하기 위한 프로세스가 있어야 한다.
7. 안전하지 않은 암호 저장
가. 위험
- 많은 웹 어플리케이션들이 적절한 암호나 해쉬를 갖고 신용카드 번호, 주민등록번호, 그리고 인증 신뢰 정보와 같은 민감한 데이터를 적절히 보호하지 않는다.
- 공격자는 자격 도난, 신용카드 사기, 또는 다른 범죄를 저지르기 위해 적절하지 못하게 보호된 데이터를 훔치거나 조작할 수 있다.
나. 예방법
- 민감한 데이터를 보호하려고 하는 위협(예, 내부자 또는 외부 사용자의 공격) 을 고려해야 한다.
- 위협으로부터 방어하기 위한 방법으로, 모든 민감한 데이터가 암호화 하였음을 확실히 해야 한다.
8. URL 접근 제한 실패
가. 위험
- 많은 웹 어플리케이션들이 보호된 링크나 버튼을 표현하기 전에 URL 접근 권한을 확인하다. 그러나, 어플리케이션은 이 페이지들이 접근될 때마다 유사한 접근 통제 확인이 필요하다
- 공격자는 감춰진 페이지에 접근하기 위해 URL을 변조할 수 있다.
나. 예방법
- 허가되지 않은 URL 접근을 방지하기 위해 각각의 페이지에 적절한 인증 및 접근 제어를 요구하는 접근 방식의 선택이 요구된다. 어플리케이션 코드 외부의 하나 또는 여러 컴포넌트에서 이러한 보호를 제공한다.
9. 불충분한 전송 계층 보호
가. 위험
- 어플리케이션은 종종 민감한 네트워크 트래픽의 인증, 암호화, 그리고 비밀성과 무결성을 보호하는데 실패한다.
- 실패할 때에는 대체로 약한 알고리즘을 사용하거나, 만료 또는 유효하지 않은 인증서를 사용하거나 또는 그것을 올바로 사용하지 않을 때이다.
나. 예방법
- 모든 민감한 페이지는 SSL을 요구하라. 이 페이지에 대한 non-SSL 요청은 SSL페이지로 리다이렉트 되어야 한다.
- 모든 민감한 쿠키는 ‘secure’ 플래그를 설정하라.
- 단지 강력한 알고리즘(FIPS 140-2 호환)만을 지원하는 SSL 공급업체를 구성하라.
10. 검증 되지 않은 리다이렉트와 포워드
가. 위험
- 웹 어플리케이션은 종종 사용자들을 다른 페이지로 리다이렉트 하거나 포워드 한다. 그러나, 목적 페이지를 결정하기 위해 신뢰되지 않는 데이터를 사용한다.
- 적절한 확인이 없다면, 공격자는 피해자를 피싱 사이트나 악의적인 사이트로 리다이렉트 할 수 있고, 포워드를 권한 없는 페이지의 접근을 위해 사용할 수 있다.
나. 예방법
- 단순히 리다이렉트와 포워드의 사용을 피해야 한다.
- 만약 사용한다면, 목적지를 계산하는 사용자 파라미터를 포함하지 마라.
- 목적 파라미터를 피할 수 없다면, 제공된 값이 유효한지, 그 사용자에게 허용된 것인지를 확실히 하라.
지금까지 OWASP에서 발표한 웹 어플리케이션 보안 위험 및 예방법에 대해서 간략하게 알아 보았다. 향후 각 위험 별로 자세한 내용을 통해 좀 더 상세한 내용을 전할 예정이다.
1. 기업/기관이 신뢰할 수 있는 어플리케이션을 개발, 구입, 유지할 수 있도록 어플리케이션 보안 툴, 표준, 연구결과 등을 공개적으로 제안하는 커뮤니티(http://www.owasp.org)
2. Security Plus 한글 번역 참고(http://cafe.naver.com/securityplus)
|
