[개발/보안] 웹 보안 취약점, 어떻게 없앨까? [펌]

[개발/보안] 웹 보안 취약점, 어떻게 없앨까? [펌]

 

많은 회사들이 중요 데이터의 유출 사고가 발생한 후에야 웹 보안을 강화하는데 혈안이 됩니다. 웹 개발 시에는 시큐어코딩을 위한 보안 문제의 영역이 매우 모호하기 때문입니다.

웹 보안 위협에 효과적인 접근 방식은 사전에 예방해야 하며 방어적이어야 합니다. 그런 보안 마인드를 고무시켜 경계심을 심어주고자 이 글을 작성했습니다.

특히, 이 가이드는 알고 있어야 할 10가지의 보편적이고 중요한 웹 보안 위험에 중점을 두며 권장 예방법도 포함합니다. 기준은 전세계의 소프트웨어 보안을 향상시키는 것이 목표인 국제 비영리 조직인 OWASP (Open Web Application Security Project) 에서 정의한 상위 10개 웹 취약점 입니다.

시작하기 전 사이버 보안의 기본 개념 - 인증 및 승인

다른 프로그래머 및 IT 전문가와 이야기할 때 종종 인증과 승인이 헷갈릴 때가 있습니다.

auth 라는 똑같은 약어는 이 혼란을 가중시킵니다. 이러한 혼동은 자주 일어나기 때문에 이 글에 ‘보편적 웹 취약점 0번’ 으로 포함되어야 합니다. 그래서 시작하기 전에 이 두 용어의 구별을 분명히 해보겠습니다.

​

- 인증 (authentication) : 보안 자격 증명 (암호, 보안 질문에 대한 대답, 지문 스캔 등)을 올바르게 제공했기 때문에 그 사람이 특정 사용자인지 (또는 그렇게 보이는지) 확인합니다.

​

- 승인 (authorization) : 특정 사용자가 특정 리소스에 대한 접근 권한을 갖거나 특정 조치를 수행할 수있는 권한을 부여 받았는지 확인합니다.

​

다시 말하면, ‘인증’이란 개체가 누구인지 아는 것이고, ‘승인’이란 권한이 주어진 개체가 무엇을 할 수 있는지 아는 것입니다.

이를 염두에 두고 인터넷 보안 문제 상위 10가지를 살펴 보겠습니다.

 

​

웹 보안 취약점 # 1 : 인젝션 결함

인젝션 결함은 신뢰할 수 없는 입력값을 필터링 하지 못하는, 가장 흔한 원인에 의해 발생합니다.

필터링 되지 못한 데이터를 SQL 서버 (SQL 인젝션), 브라우저 (XSS - 뒤에서 설명)를 비롯한 다른 곳에 전송할 때 발생할 수 있습니다. 여기서 문제는 공격자가 입력값에 명령을 주입하여 데이터가 손실되고 클라이언트의 브라우저를 탈취할 수 있게 된다는 것입니다.

애플리케이션이 신뢰할 수 없는 출처에서 받은 모든 항목은 가급적 화이트리스트 기준으로 필터링하고 블랙리스트를 사용하지 말아야 합니다. 블랙리스트는 대부분 쉽게 바이패스 해버리는데 반해, 화이트리스트는 그 기준을 통과하기 매우 어렵기 때문입니다.

백신 소프트웨어는 실패한 블랙리스트의 대표 사례입니다. 패턴 대조로는 제대로 필터링 할 수 없습니다.

​

예방 : 인젠션으로부터 보호는 입력값을 적절히 필터링하고 입력값을 신뢰할 수 있는지 생각하면 되는 ‘간단한’ 문제이긴 하지만, 조금이라도 신뢰할 수 없다면 모든 입력값을 제대로 필터링해야 하는 ‘복잡한’ 문제이기도 합니다.

예를 들어, 1,000개의 입력값이 있는 시스템에서 999개를 성공적으로 필터링하는 것만으로는 충분하지 않습니다.

남은 하나가 시스템을 손상시키는 약점이 될 수도 있기 때문입니다.

그리고 데이터베이스가 믿을만 하기 때문에 SQL 쿼리 결과를 다른 쿼리에 넣는 것이 좋은 생각일 수 있지만, 데이터베이스 주위가 신뢰성 없다면 공격자의 간접적으로 들어올 수 있습니다.

참고로, 이를 ‘2차 SQL 인젝션’ 이라고 합니다.

필터링은 암호화처럼 제대로 이뤄지기 어렵기 때문에 철저히 조사하여 그 성능을 입증하는 프레임워크의 필터링 기능을 꼭 사용하길 권합니다.

 

​

웹 보안 취약점 # 2 : 만료된 인증서

해당 웹사이트의 인증서를 발급한지 오래돼서 발생할 수 있는 문제는 여러가지 있지만 다른 원인에서 비롯된 것일 수도 있습니다.

누군가 2014년에 발급받은 자신의 인증서를 웹사이트에 여전히 사용하면, 다음과 같은 여러 위험이 있습니다.

​

1) 만료된 인증서를 사용하는 URL에 세션 ID (웹사이트의 서버가 사용자의 방문 시간 동안 그 사용자에 할당한 고유 번호입니다. 세션 ID는 쿠키, 폼필드, 또는 URL 로 저장되는데 일부 웹 서버는 숫자를 단순히 증가시켜 세션 ID를 생성하기도 합니다.)가

포함 된 경우도 있으며 참조 헤더에 있는 이 세션 ID가 다른 사람에게 유출될 수 있습니다.

2) 암호는 저장 또는 전송 중 암호화되지 않을 수 있습니다.

3) 세션 ID를 예측하기 쉽기 때문에 이 세션 ID의 권한을 뼷기 쉽습니다.

4) 세션 고정 (공격자가 유효한 사용자 세션을 가로채는 것을 허용하는 공격) 이 일어날 수도 있습니다.

5) 세션이 탈취될 수도 있고, 타임아웃 (일정시간 동안 동작이 없어 자동 로그아웃)이 제대로 구현되지 않거나

HTTP (SSL 보안 없음)를 사용 중일 수 있습니다. 그 외 기타 등등.

​

예방 : 이 웹 보안 취약점을 피하는 가장 직접적인 방법은 프레임워크 (SW 애플리케이션이나 솔루션의 개발을 수월하게 하기 위해 SW의 구체적 기능들에 해당하는 부분의 설계와 구현을 재사용 가능하도록 협업화된 형태로 제공하는 SW 환경) 를 사용하는 것입니다. 웹 개발을 혼자 충분히 잘 할 수 있겠지만 프레임워크를 사용하는 것이 훨씬 쉽습니다. 자신만의 코드를 구현하려면 극도로 예민하게 실수가 없는지 스스로 찾아내야 합니다.

 

​

웹 보안 취약점 # 3 : XSS (Cross Site Scripting)

꽤 널리 퍼진 입력값 검사 실패 사례 (본질적으로는 ‘취약점 # 1 인젝션’의 일종) 입니다.

공격자는 입력값에 자바스크립트 태그를 넣습니다. 이 입력값이 사용자에게 돌아가면 (예: 게시판) 사용자의 브라우저가 이를 실행합니다. 구체적인 방법으로는, 링크를 만들어 사용자가 클릭하도록 설득하는 것처럼 간단할 수도 있고, 페이지 로드 시 스크립트가 실행되어 쿠키를 공격자에게 전달하는 역할 등을 할 수도 있습니다.

​

예방 : 간단한 솔루션이 있습니다. HTML 태그가 클라이언트에 돌아가지 않도록 하세요.

이는 공격자가 (이미지나 시끄럽고 보이지 않는 플래시 플레이어 같은) 일반 HTML 콘텐츠를 주입하는 공격 (큰 피해는 없지만 짜증나서 멈추고 싶게 함.)과 유사한 ‘HTML 인젝션’도 방어할 수 있습니다.

일반적으로 이 문제를 해결하려면 단순히 모든 HTML 개체를 변환해야 하므로 <script>는 <script> 로 돌아옵니다.

또 다른 자주 사용하는 검사 방법은 정규 표현식을 사용하여 <와 >에 대해 정규 표현식을 사용하는 HTML 태그를 벗겨내는 것이지만, 많은 브라우저가 심하게 손상된 HTML도 이상 없다고 해석해 버리므로 위험한 방법입니다. 모든 문자를 인코딩하는 것이 좋습니다.

 

​

웹 보안 취약점 # 4 : 안전하지 않은 직접 객체 참조

사용자의 입력값을 믿다가 낭패 보는 것은 보안 취약점의 전형적인 사례입니다.

직접 객체 참조는 파일이나 데이터베이스 키와 같은 내부 객체가 사용자에게 공개된다는 것을 뜻합니다.

이로 인해 공격자가 이 참조에 접근할 수 있고 승인 절차가 적용되지 않거나 ​​깨진 경우, 접근 금지된 것에 접근할 수 있다는 점에서 문제가 됩니다.

예를 들어, 사용자가 파일을 다운받게 하는 download.php 모듈을 가진 코드는 CGI 파라미터를 사용해 파일 이름 (예: download.php?file=something.txt)을 지정합니다. 개발자는 깜박하고 그 코드의 승인 절차를 빠뜨립니다.

이제 공격자는 이를 이용해 PHP를 실행하는 사용자가 접근할 수있는 모든 시스템 파일 (애플리케이션 코드 자체나 백업 처럼 서버에 남은 데이터)을 다운로드 할 수 있습니다.

또다른 취약점 사례는 사용자 입력값 기반으로 리셋된 암호를 정하는 암호 리셋 기능입니다.

유효한 URL을 클릭 후 공격자는 URL의 username 필드를 수정하여 admin 같은 것으로 변경할 수 있습니다 .

위 두 사례는 실제로 자주 일어나는 일입니다.

​

예방 : 사용자 인증을 항상 꼭 수행하고 승인된 사용자를 화이트리스트에 추가하세요.

데이터를 내부적으로 저장하고 클라이언트로부터 파일을 CGI 파라미터를 통해 전송하는 것에 의존하지 않으면 대부분의 문제를 피할 수 있습니다. 대부분의 프레임워크에 있는 세션 변수 기능은 이러한 목적에 부합하는 기능입니다.

 

​

웹 보안 취약점 # 5 : 보안 구성 오류

경험상, 웹 서버와 애플리케이션이 잘못 구성된 경우가 생각보다 많습니다.

실수하는 경우는 무궁무진하기 때문입니다. 다음과 같은 몇 가지 예를 들 수 있습니다.

1) 개발 시, 디버그 (개발 마지막 단계에서, 존재하는 오류를 발견>원인추적>정정하는 툴) 를 사용하여 애플리케이션 실행

2) 서버에 디렉토리 목록을 사용가능으로 설정하여 중요한 정보 유출

3) 오래된 소프트웨어를 실행 (워드프레스 플러그인, 오래된 PhpMyAdmin 같은 경우)

4) 컴퓨터에서 실행 중인 불필요한 서비스

5) 변경하지 않는 기본 키와 암호 (생각보다 자주 일어납니다!)

6) 공격자에게 스택 추적 같은 오류 처리 정보를 공개

​

예방 : 배포시 테스트를 실행할 수 있는 철저한 (가급적 자동화된) "구축 및 배포" 프로세스를 갖추세요.

예산이 부족한 경우, ‘포스트 커밋 후크’ (Post-commit Hook) 기술을 사용하면, 코드가 내장된 기본 암호와 개발된 것들과 함께 빠져 나가는 것을 방지해 줍니다.

 

 

 

출처 : m.blog.naver.com/PostView.nhn?blogId=monitorapp_co&logNo=221329201786