웹 애플리케이션 보안의 경우, 많은 회사들이 취약점 찾으려고 매일 단순히 자사 시스템을 스캔(scan)하고 있지만 이것은 분명 잘못이다. 마이크 뮬린스는 반드시 고려해야 하는 웹 애플리케이션 보안 중 가장 중요한 3가지를 소개했다.

웹 애플리케이션이 회사의 네트워크에 각종 해악의 원인이 될 수 있다. 그래서 누군가 네트워크의 취약점을 찾기 전에, 문제를 해결하는 방법과 공격에 대한 지식을 익혀서 스스로 무장하고 네트워크를 보호해야 한다.

웹 애플리케이션 보안의 경우, 많은 회사들이 취약점 찾으려고 매일 단순히 자사 시스템을 스캔(scan)하고 있지만 이것은 분명 잘못이다. 애플리케이션이 안전한가를 검사하기 위해 웹 플랫폼 분석 시스템에만 의존하지 말아야 한다. 이것은 완전히 다른 영역의 문제로 모든 네트워크의 애플리케이션은 독립적으로 고려돼야 한다.

왜 항상 조심해야 하는지 웹 애플리케이션에서 가장 대표적인 3가지 문제를 살펴보자

인증
SSL을 사용하고 ID와 암호로 인증(strong two-part authentication)해도 인증은 웹 애플리케이션 보안에서 가장 중요하다. 암호를 변경하거나 사용자 정보를 수정하는 것 등을 완벽하지 않게 관리하는 것은 인증을 취약하게 만들 수도 있다. 그래서 계정 관리와 관련된 모든 기능을 수행할 때 사용자 세션이 옳게 인증받은 세션이어도 재인증을 요구하게 해야 한다.

대부분의 웹 애플리케이션은 ID와 암호로 인증한다. 인증을 안전하게 만들기 위해 소프트웨어와 바이오메트릭스(biometrics) 등과 같이 하드웨어 기반의 암호화 기술을 사용할 수 있다.

애플리케이션에 추가비용을 발생시키지만 개발 계획에 포함시켜야 한다고 주장해야 한다. 만약 결정권한이 없다면 다음을 참고하라. FDIC(ederal Deposit Insurance Corporation)는 일 년 전에 개인정보 도난 사건이 증가하고 있기 때문에, 온라인 뱅킹을 서비스하는 은행들은 전통적인 인증방법을 보완하도록 다양한 인증방법(multifactor authentication: 예를 들어, 지문이나 소프트웨어/하드웨어 보안장치를 함께 사용하는 것)을 도입할 책임이 있다고 결론지었다.

접근 제어
접근 제어의 관심은 웹 애플리케이션이 콘텐츠와 기능에 어떻게 인증하고 접근을 허가하거나 거부할 것인가에 있다. 두 가지 접근 제어 문제를 살펴보자

* 패스 트래버설(Path traversal): 악의적인 유저가 상대경로(relative path - 예를 들어, https://your_website.com/target_dir/target_file처럼) 정보를 이용해 이 공격을 자행한다. 이 공격은 일반적으로 직접 접근할 수 없는 파일을 다운받는 시도를 하게 만든다. 웹 브라우저상의 URL, 시스템 콜, 쉘 명령어 등을 이용하는 해킹 도구들이 그러한 공격을 가능하게 만든다.

* 클라이언트-사이드 캐싱(Client-side caching): 보통 대부분의 웹 브라우저는 웹 페이지를 캐시한다. 공격자는 보호되고 있는 사이트에 접근하기 위해서 캐시정보를 뒤져볼 수 있다. 유저는 종종 여러 사람이 사용하는 컴퓨터로 웹 애플리케이션에 접근한다. 그래서 웹 애플리케이션은 브라우저에서 유저 정보를 캐시하지 않도록 민감한 정보는 캐시를 제한하는 기능이 있어야 한다.

잘못된 입력값
웹 애플리케이션이 유저의 HTTP 요청에 응답하는데 공격자는 HTTP 요청에서 URL, SQL, 폼 필드, 숨은 필드 등을 수정해 사이트의 보안 메커니즘을 우회하려 한다. 크로스-사이트 스크립팅(cross-site scripting), 버퍼 오버플로우(buffer overflows), SQL 입력이 가장 일반적인 공격이다.

사이트의 성능과 유용성만 고려해 클라이언트에서만 입력 값을 검사하는 웹 사이트가 있을 때, 공격자는 쉽게 이 검사 방법을 통과할 수 있고 웹 애플리케이션은 악성 입력 값에 무방비 상태로 남게 된다.

해커는 웹 브라우저의 검사를 우회하는 도구를 사용해 HTTP 요청을 보낸다. 서버쪽 검사는 이런 형태의 HTTP 요청 공격을 막기 위해 필요하다.

웹 애플리케이션이 본질적으로 불안전하고 많은 문제가 있다면 어떻게 안전하게 해야 할까? 해답은 간단하다.

애플리케이션이 개발되는 동안에 코드를 문서화하는 것과 독립 코드 확인(independent code review)이 보안을 성공시키는 열쇠다. 모든 코드를 문서화하고 애플리케이션 관리방법과 시스템을 평가를 맡길 제3의 애플리케이션 보안 전문가를 구해야 한다.

만약 웹 애플리케이션이 이미 서비스중이고 아직 보안 단계를 생략했어도 아직 늦지 않았다. 아직 애플리케이션을 안전하게 할 수 있다. 서비스하기 전에 다각도에서 코드를 검토했다고 해도 보안 문제와 취약점을 찾기 위해 지속적으로 애플리케이션을 관리하고 테스트해 해야 한다.

웹 애플리케이션 보안 테스팅에 대해 몇 가지 사항을 살펴 보았다. 어떻게 해야 할지 모르겠다면 웹 애플리케이션 보안 도구에 대한 마이시몬(mySimon)의 검색결과가 안내자가 되어 줄 것이다.

애플리케이션을 만들었다면 회사 내외부의 사람들은 그 애플리케이션을 테스트할 것이다. 애플리케이션이 수정될 때마다 애플리케이션의 취약점이 생길 것이고 애플리케이션을 서비스하기 전에 침입 테스트를 해야 한다.

시스템 보안 검사는 애플리케이션이 아니라 오직 플랫폼만을 검사할 것이다. 추가작업을 통해 애플리케이션을 안전하게 만들어야 한다.@

***필자 소개***:
마이크 뮬린스는 미 재무부 비밀 검찰국과 국방부 정보시스템 계획국에서 네트워크 부관리자 겸 네트워크 보안 관리자로 일하고 있다. 현재는 STNO(Southern Theater
Network Operations)과 시큐리티 센터의 운영 이사를 맡고 있다.