[심의준의 웹 보안 실무] ASP 웹 소스 보안

오 늘은 ASP를 이용한 웹 어플리케이션 제작할 때 보안을 강화하기 위해 해야하는 주요 작업들에 대해 소개하도록 하겠다. 이 칼럼은 XSS, SQL Injection 등 외부 공격을 효과적으로 막을 수 있는 ASP 스크립트의 방어 기법을 소개하는 글이다.

필 자가 작년에 코리아인터넷닷컴을 통해 XSS와 SQL Incjection에 대해 소개한 적이 있으나, 이번에는 웹 어플리케이션 보안을 주제로 전반적으로 살펴보는 칼럼이기에 다소 중복되는 부분도 있으나 되짚어 보고 의미를 재확인한다는 차원에서 다시 하나씩 살펴보도록 하겠다.

웹 서버를 해킹하고자 할 때 가장 쉽게 들어오는 경로가 바로 웹사이트 상에 존재하는 파일 업로드 부분이다. 대부분의 웹사이트들이 사용자들에게 파일을 업로드 할 수 있게 허용하고 있다. 하지만, 아쉽게도 업로드되는 파일들을 완벽히 필터링 하는 사이트들은 그리 많지 않아 보인다.

업로드 기능을 우회적으로 접근하여 해커가 원하는 행위를 할 수 있는 스크립트를 포함한 파일을 실행할 수 있는 구조가 많이 노출되어 있다. IIS 보안에서 소개한 내용과 같이 응용프로그램 실행권한을 제어하지 않았다면 쉘스크립트를 가지고 있는 ASP 파일을 올려서 웹서버를 치명적인 상황으로 만들 수 있다는 것이다. 따라서, 업로드 소스에서는 반드시 업로드 되는 파일들에 대해 필터링 작업을 해야만 한다.

필터링 작업을 할 때 반드시 지켜야 할 사항이 있다. 그건 바로 서버스크립트를 통한 필터링이 이루어져야 한다는 것이다. 대부분 파일 필터링을 하는 경우 파일을 업로드 하는 폼이 있는 페이지에서 클라이언트 스크립트(자바스크립트)를 통해 확장자 등을 체크하여 파일 검증을 한다. 하지만, 클라이언트 스크립트로만 제어한다고 할 때 해커의 로컬 PC 에서 파일업로드 폼 페이지를 작성한 후 폼 Submit 의 Target을 실제 파일을 업로드 처리하는 페이지로 설정한다면 외부에서도 충분히 원하는 파일을 마음껏 올리는 것이 가능하다. 따라서, 폼 페이지에서 클라이언트 스크립트를 통해서도 파일 검증작업을 하는 것과 동시에, 반드시 실제 파일을 업로드 처리하는 Process 페이지에서 서버스크립트를 통해 파일 검증 작업을 하여야 한다. 대부분의 파일 업로드 컴포넌트 들이 파일형식을 체크하는 메소드를 제공하기 때문에 쉽게 체크할 수 있다.

그리고, 이미지 소스가 아닌 다른 기타 파일들의 업로드를 허용해야 하는 경우 되도록이면 zip 과 같이 압축된 파일만을 허용하는 것도 좋은 방안이다. 그리고, 파일을 업로드 할 때 파일명을 정해진 규칙에 따라 치환하여 파일을 쉽게 접근하지 못하게 하는것도 도움이 된다.

다시 한번 강조하지만, 서버 보안에서 가장 중요한 부분이므로 반드시 기억하도록 하자. 파일을 업로드 하는 로직이 필요한 경우 “IIS응용프로그램 실행권한을 없음 + ASP 소스 내에서 파일 검증” 작업을 반드시 해야 한다.

2. 파라미터 필터링

1) XSS를 방지하기 위한 필터링

XSS 공격이 무엇인지 간략히 설명하자면 Cross Site Scripting의 약자로 Script 나 Tag 공격을 통해 웹 페이지가 비정상적으로 동작하게 하거나 페이지에 접근하는 유저들의 특정 데이터를 추출해가는 공격을 말한다.

특정 폼의 입력란(Input Box나 TextArea)에 태그와 자바스크립트를 통해 공격문자열을 입력하게 되면, 그 페이지를 로딩했을 때 해당 명령이 실행되게 된다. 예를 들어, <xmp> 라는 HTML 명령어를 입력하였을 때, < 와 > 로 변경하여 저장하지 않았다면, 해당 페이지는 파싱된 HTML이 실행되지 않고 <xmp>가 실행되어 <xmp> 이하의 HTML 코드들을 페이지상에 노출하게 된다. 또한, <script> 문을 작성하여 저장하게 되면 페이지가 로딩될 때마다 해당 스크립트가 실행되어 사용자의 쿠키 값을 해커가 원하는 서버로 전송시킬 수 도 있으며, 해당 페이지를 자유자재로 다른 특정 페이지로 리다이렉트 시키는 등 이외에도 여러 가지 행위를 할 수 있게 된다.

이를 방지하기 위해서는 Tag를 저장할 때, “<”와 “>” 부분을 “&lt;”와 “&gt;”로 변경하여야 한며, 입력폼의 MaxLength 제어, “<script”와 같은 단어의 입력 방지 작업들을 하여야 한다. 그리고, 페이지상에 Request.QueryString 과 같은 Value를 나타내야 하는 경우, URLEncoding과 같은 메소드를 이용하여 값을 인코딩하기 바란다.

2) SQL Injection을 방지하기 위한 필터링

너무나도 유명한 SQL Injection 이다. SQL Injection을 논할 때 마다, 예전에 방안을 마련하기 위해 수없이 테스트 했던 기억이 늘 떠오르곤 한다. SQL Injection 이 무엇인지 간략히 설명하자면, 데이터를 처리하는 과정을 침투하여 의도되지 않은 데이터 핸들링이 잃어나게 하여 데이터를 변조하거나 획득해가는 공격을 말한다. 따라서, SQL Injection 은 주요한 데이터에 대한 공격이기 때문에 절대적으로 방어해야만 하는 아주 중요한 대상이다. 실감나지 않는다면 만약 공격에 의해 테이블을 Drop 했거나 회원 Data를 획득했다고 가정해 보라.

SQL Injection 을 방지하기 위해 ADO를 통한 데이터 핸들링 시 전달되는 파라미터들에 대한 필터링 작업이 필요하게 된다. 이러한 필터링 작업만 완벽히 처리해 준다면 보안이 월등히 높아질 것이다.

파라미터 검증을 위한 함수를 작성할 시에 고려해야 할 사항에 대해 살펴보자.

ⅰ. 데이터 타입 검증 – 데이터는 크게 INT와 Char 형식으로 나뉘게 된다. 따라서, 숫자형의 데이터를 전달해야만 하는 경우 ASP의 IsNumeric 함수를 통해 검증할 수 있다.

ⅱ. 싱글 쿼테이션의 치환 – ADO의 RecordSet 객체를 이용하는 경우 해당 로직에 따라 싱글 퀘테이션을 치환하도록 한다. Ex) ‘ -> ‘’

ⅲ. 문자열 체크 – 문자열이 넘어오는 경우 해당 파라미터의 사이즈에 맞도록 사이즈를 체크하여 불필요한 값이 전달되지 않도록 한다. Left 함수 등을 이용하여 전달되는 데이터의 값을 잘라내는 것도 한 방법이다.

ⅳ. 널 체크 – 반드시 파라미터에 데이터가 전달되어야 하는 경우 널 체크를 통해 값을 인증하도록 한다.

ⅴ. 태그의 허용 - HTML게시판과 같이 태그를 허용하는 경우를 제외하고는 &lt;와 &gt;로 치환하도록 한다.

이렇게 5가지가 파라미터 검증을 위한 가장 핵심적인 부분이다. 이외에도 해당 로직에 따라 추가적인 파라미터 검증작업이 필요하므로 구현시 보안로직에 대해 잘 고민해야만 한다.

여 기서 주의해야 할 사항이 있다. 이렇게 ASP에서 파라미터 검증을 한다고 하여 SQL Injection 이 완벽히 막아지는 건 아니라는 사실이다. 이번 칼럼은 ASP 웹 소스 보안이기 때문에, 이 내용은 ASP 웹 소스상에서 최대한 할 수 있는 방어 기법이라는 것이다. 이를 완벽이 막기 위해서는 데이터베이스 차원에서의 방어까지 이루어 져야 한다. 이 내용은 다음에 이어질 데이터베이스 보안에서 다시 소개하도록 하겠다. 위 내용은 웹 소스상에서 기본적으로 반드시 해줘야 할 작업들에 내한 내용이다.

XSS 와 SQL Injection 과 관련하여 간략히 소개하면서 웹 소스상에서 어떠한 작업들을 해줘야 하는지에 대해 설명하였다. 온라인 칼럼 특징상 주요 사항만 작성되었기 때문에 구현하는데 있어 해당 로직을 잘 판단하여 예상되는 공격을 막아내는 작업이 필요하다. 위에서 설명한 내용들을 모두 함수로 작성하고, 개발표준안에 추가하여 모든 스크립트가 항상 보안 로직을 통해 작성되도록 해야 한다.

3. 주요 데이터 보안

웹 의 특징상 페이지간의 전환에서 많은 데이터들이 전달되며, 쿠키 값과 같이 특정한 데이터들을 보관하게 된다. 즉, 바꾸어 말하면 많은 데이터들이 우회적인 공격에 의해 노출될 소지가 있다는 얘기이다. 따라서, 주요 데이터들에 대한 보안작업이 필요하게 된다.

1) 페이지 Referer 체크

일반적으로 웹페이지의 구조상 데이터로직을 가지고 있는 페이지는 이전단계에 폼을 갖는 페이지를 거치게 된다. 따라서, 데이터로직 페이지에서는 이전페이지가 개발자에 의해 작성된 페이지인지를 체크하여 외부에서 의도하지 않은 접근이 이루어 지지 않도록 하여야 한다.

Referer를 체크해야 하는 또 하나의 단편적인 예를 보자. 회원가입 페이지에서 대부분 팝업창을 이용하여 우편번호 검색과 같은 로직을 대부분 갖고 있다. 우편번호 검색페이지와 같이 단순히 SELECT 하는 페이지를 툴을 이용하여 외부에서 끊임없이 호출하는 경우 데이터베이스가 어떤 상황에 처하게 될지 생각해 보라. 따라서, 페이지 유입경로에 대한 검증 작업이 필요하다.

2) 파라미터 이름의 규칙 정의

많은 웹사이트들에서 쿼리스트링으로 전달되는 값들을 보면 UserCode 혹은 MemberCode등 해당 값이 무엇인지 유추할 수 있게 제작되어 있다. 이러한 값들은 URL 확인 만으로도 값을 확인할 수 있게 된다. 누군가 공격하려 할 때 웹의 구조를 쉽게 파악할수 있다는 것이다. 따라서, 쉽게 알아내지 못하도록 해당 파라미터들의 이름을 약어로 사용하거나 암호화 하는 작업이 중요하다.

3) GET 방식의 지양

회원코드, 주민번호와 같이 주요한 데이터를 전송시에 GET 방식을 지양하고 POST방식을 활용토록 하며, POST로 값을 전송할 시에 해당 데이터를 암호화하여 전달하도록 한다. GET 방식을 사용하는 경우 해당 데이터들이 너무나 쉽게 노출되는 경향이 있기 때문이다.

4) 유저 인증정보의 암호화

XSS를 소개하면서 XSS 공격을 통해 페이지에 접근하는 유저들의 정보를 쉽게 획득할 수 있다고 하였다. 유저들이 로그인후 갖게 되는 인증정보는 일반적으로 세션 혹은 쿠키를 이용해 저장되게 된다. 따라서, 세션, 쿠키 값을 생성할 시에 암호화를 하여 저장한다면 해당 데이터를 획득했다 할지라도 복호화해야 하는 작업이 필요하게 된다. 따라서, 유저들의 인증정보를 암호화 하는 작업은 상당히 유용한 작업이다.

5) 기타

이 외에도 크게 의미가 있다고 보지는 않지만, 보안 관련 권장사항을 보면 태그 제어를 통해 상태표시줄에 URL 노출을 방지하는 것과, 마우스 우클릭 제어등이 있다. 그리고, 웹 폴더 및 페이지 이름에 대해서도 네이밍룰에 대한 권장사항이 있다. 보안 점검 툴을 실행하게 되면 찾는 취약점 중 하나가 웹 폴더 및 페이지의 이름 구조이다. Password.asp 같이 너무나 쉽게 탐지할 수 있는 페이지 구조는 취약점으로 판단하게 된다. 참고하기 바란다.

4. 마무리

지금까지 ASP 웹 소스 보안에 대해 살펴보았다. 웹 소스 보안중 중요하다고 판단되는 내용에 대해 소개하였다. 위 방법 말고도 여러가지 접근이 가능하리라 본다. 위에서 소개한 내용은 필자가 현업에서 활동하면서 적용해왔던 방법들이다. 중요한건 웹 어플리케이션을 작성할 시에 보안 로직을 작성하여 모든 소스가 해당 로직을 거치도록 구현해야 한다는 것이다. 어떤 방법을 선택하든 보안작업은 이루어 져야 한다.

다음 회에는 이번 보안 칼럼의 마지막 주제인 데이터베이스 보안에 대해 알아보도록 하겠다. 다음 회에는 어떠한 작업들을 통해 데이터베이스에 대한 보안이 강화되는지에 대해 살펴보도록 하자.

작성자 : 심의준(열정과 발전이란 단어를 좋아하는 개발자이다. 현재 MCSD 이며 비영리 공익 개발자 커뮤니티인 SmartVB.NET의 운영자이다)

작성일 : 2006년 04월 04일 / 2006년 04월 10일 / 2006년 04월 18일

원   문 :

Part 1 http://korea.internet.com/channel/content.asp?kid=4&cid=185&nid=38616

Part 2 http://korea.internet.com/channel/content.asp?kid=4&cid=185&nid=38669

Part 3 http://korea.internet.com/channel/content.asp?kid=4&cid=185&nid=38769