[Hot Issue] 웹 애플리케이션 10가지 위험 요소와 예방법

OWASP Top 10 2010

OWASP Top 10 2007

A1 – 인젝션 (Injection)

A2 – 인젝션 취약점

A2 – 크로스 사이트 스크립팅 (XSS)

A1 – 크로스 사이트 스크립팅 (XSS)

A3 – 취약한 인증과 세션 관리

A7 – 취약한 인증 및 세션 관리

A4 – 안전하지 않은 직접 객체 참조

A4 – 불안전한 직접 객체 참조

A5 – 크로스 사이트 요청 변조 (CSRF)

A5 – 크로스 사이트 요청 변조 (CSRF)

A6 – 보안상 잘못된 구성 (신규)

안전하지 않은 구성 관리>

A7 – 안전하지 않은 암호 저장

A8 – 불안정한 암호화 저장

A8 – URL 접근 제한 실패

A10 – URL 접속통제 실패

A9 – 불충분한 전송 계층 보호

A9 – 불안전한 통신

A10 – 검증되지 않은 리다이렉트와 포워드(신규)

에 없었음>

에서 삭제>

A3 – 악성파일 실행

에서 삭제>

A6 – 정보 유출과 부적절한 오류 처리

OWASP

Top 10 2010

위험

예방법

A1 – 인젝션 (Injection)

n SQL, OS, LDAP 인젝션과 같은 인젝션 결함은 신뢰할 수 없는 데이터가 명령어나 질의어의 일부분으로써 인터프리터(interpreter)에 보내 질 때 발생한다.

n 공격자의 악의적인 데이터는 예기치 않은 명령 실행이나 권한 없는 데이터에 접근하도록 인터프리터 (interpreter)를 속일 수 있다.

n 인젝션을 방지하려면 신뢰할 수 없는 데이터를 명령어와 질의로부터 항상 분리해야 한다.

A2 – 크로스 사이트 스크립팅 (XSS)

n XSS 결함은 적절한 확인이나 제한 없이 애플리케이션이 신뢰할 수 없는 데이터를 갖고, 그것을 웹 브라우저에 보낼 때 발생한다.

n XSS는 공격자가 피해자의 브라우저 내에서 스크립트의 실행을 허용함으로써, 사용자의 세션을 탈취하거나, 웹사이트를 변조하거나, 악의적인 사이트로 사용자를 리다이렉트 할 수 있다.

n XSS를 방지하려면 활성 브라우저 콘텐츠와 신뢰할 수 없는 데이터를 항상 분리해야 한다

A3 – 취약한 인증과 세션 관리

n 인증과 세션 관리와 연관된 애플리케이션 기능은 종종 올바로 구현되지 않는다. 그 결과, 공격자로 하여금 다른 사용자의 신분으로 가장할 수 있도록 패스워드, 키, 세션 토큰 체계를 위태롭게 하거나, 구현된 다른 결함들을 악용할 수 있도록 허용한다.

n 개발자들은 아래와 같은 권장사항을 준수하여야 한다.

. 강력한 인증 및 세션 관리 통제의 단일체계를 유지해야 한다.

. 세션 ID를 도용하는데 사용될 수 있는 XSS 취약점을 막기 위해 노력해야 한다.

A4 – 안전하지 않은 직접 객체 참조

n 직접 객체 참조는 파일, 디렉터리, 데이터베이스 키와 같이 내부적으로 구현된 객체에 대해 개발자가 참조를 노출할 때 발생한다.

n 접근 통제에 의한 확인이나 다른 보호가 없다면, 공격자는 이 참조를 권한 없는 데이터에 접근하기 위해 조작할 수 있다.

n 사용자 혹은 세션 당 간접 객체 참조를 이용한다.

n 신뢰할 수 없는 소스로부터 직접 객체 참조가 사용되면, 각각의 사용에 대해 요청한 객체가 사용자에게 접근이 허용되었는지 확인하기 위해서 반드시 접근 통제 확인을 포함해야만 한다.

A5 – 크로스 사이트 요청 변조 (CSRF)

n CSRF 공격은 로그온 된 피해자의 브라우저가 취약한 웹 애플리케이션에 피해자의 세션 쿠키와 어떤 다른 자동으로 포함된 인증 정보를 갖고 변조된 HTTP 요청을 보내도록 강제한다.

n 이것은 공격자가 피해자의 브라우저로 하여금 취약한 애플리케이션이 피해자로부터의 정당한 요청이라고 착각하게 만드는 요청들을 생성하도록 강제하는 것을 허용한다.

n CSRF를 예방하는 방법은 각각의 HTTP 요청 URL이나 Body 내에 예측할 수 없는 토큰을 포함하는 것이다. 생성된 토큰은 최소한 사용자 세션 별로 반드시 고유 값을 사용하되, 각각의 요청마다 고유할 수도 있다.

A6 – 보안상 잘못된 구성 (신규)

n 훌륭한 보안은 애플리케이션, 프레임워크, 애플리케이션 서버, 웹 서버, 데이터베이스 서버와 플랫폼에 대해 보안 구성이 제대로 정의되고 적용되도록 용구 한다.

n 대부분이 보안을 기본적으로 탑재하지 않기 때문에 이 모든 설정은 정의되고, 구현되고, 유지되어야 한다. 이것은 애플리케이션에서 사용되는 모든 코드 라이브러리를 포함하여 모든 소프트웨어가 최신의 상태를 유지하는 것을 포함한다.

n 적절히 보호되는 또 다른 환경 구축을 쉽고 빠르게 만들 수 있는 반복 가능한 보안 강화 프로세스는 개발, 품질 보증, 생산 환경 모두에서 동일하게 구성되어야 한다.

n 모든 새로운 소프트웨어 업데이트와 패치를 각각의 배치환경에서 시기 적절하게 배포와 최신 수준을 유지하기 위한 프로세스가 있어야 한다.

A7 – 안전하지 않은 암호 저장

n 많은 웹 애플리케이션들이 적절한 암호나 해쉬를 갖고 신용카드 번호, 주민등록번호, 그리고 인증 신뢰 정보와 같은 민감한 데이터를 적절히 보호하지 않는다.

n 공격자는 자격 도난, 신용카드 사기, 또는 다른 범죄를 저지르기 위해 적절하지 못하게 보호된 데이터를 훔치거나 조작할 수 있다.

n 민감한 데이터를 보호하려고 하는 위협(예, 내부자 또는 외부 사용자의 공격)을 고려해야 한다.

n 위협으로부터 방어하기 위한 방법으로, 모든 민감한 데이터가 암호화 하였음을 확실히 해야 한다.

A8 – URL 접근 제한 실패

n 많은 웹 애플리케이션들이 보호된 링크나 버튼을 표현하기 전에 URL 접근 권한을 확인하다. 그러나, 애플리케이션은 이 페이지들이 접근될 때마다 유사한 접근 통제 확인이 필요하다

n 공격자는 감춰진 페이지에 접근하기 위해 URL을 변조할 수 있다.

n 허가되지 않은 URL 접근을 방지하기 위해 각각의 페이지에 적절한 인증 및 접근 제어를 요구하는 접근 방식의 선택이 요구된다. 애플리케이션 코드 외부의 하나 또는 여러 컴포넌트에서 이러한 보호를 제공한다.

A9 – 불충분한 전송 계층 보호

n 애플리케이션은 종종 민감한 네트워크 트래픽의 인증, 암호화, 그리고 비밀성과 무결성을 보호하는데 실패한다.

n 실패할 때에는 대체로 약한 알고리즘을 사용하거나, 만료 또는 유효하지 않은 인증서를 사용하거나 또는 그것을 올바로 사용하지 않을 때이다.

n 모든 민감한 페이지는 SSL을 요구하라. 이 페이지에 대한 non-SSL 요청은 SSL페이지로 리다이렉트 되어야 한다.

n 모든 민감한 쿠키는 ‘secure’ 플래그를 설정하라.

n 단지 강력한 알고리즘(FIPS 140-2 호환)만을 지원하는 SSL 공급업체를 구성하라.

A10 – 검증되지 않은 리다이렉트와 포워드(신규)

n 웹 애플리케이션은 종종 사용자들을 다른 페이지로 리다이렉트 하거나 포워드 한다. 그러나, 목적 페이지를 결정하기 위해 신뢰되지 않는 데이터를 사용한다.

n 적절한 확인이 없다면, 공격자는 피해자를 피싱 사이트나 악의적인 사이트로 리다이렉트 할 수 있고, 포워드를 권한 없는 페이지의 접근을 위해 사용할 수 있다.

n 단순히 리다이렉트와 포워드의 사용을 피해야 한다.

n 만약 사용한다면, 목적지를 계산하는 사용자 파라미터를 포함하지 마라.

n 목적 파라미터를 피할 수 없다면, 제공된 값이 유효한지, 그 사용자에게 허용된 것인지를 확실히 하라.