자유로운설탕

  이번 시간에는 웹 어플리케이션에서 자주 이슈가 되는 업로드, 다운로드 문제를 살펴보려고 한다. 이 부분은 내부에 돌아가는 원리와 패턴을 이해하기만 하면 해법이 아주 명확한 편인 부분이기도 하다. 각각 실제 돌아가는 코드를 한번 살펴본 후, 해당 문제를 보안적으로 바라보는 관점을 설명하려고 한다.

[목차]

1. 보안을 바라보는 방법

2. 보안에서의 코드 읽기

3. 인젝션(Injection) 살펴보기 #1, #2

4. 암복호화

5. 클라이언트 코드

6. 업로드, 다운로드

7. 스크립트 문제

8. API

11. 스캐너 vs 수동 테스트

12. 자동화 잡

13. 리버싱과 포렌식

14. 모니터링 문제

15. 악성코드

16. 보안과 데이터

1. 들어가면서

  사실 컴퓨터안의 데이터라는 것은 사용자나 프로그래머를 위해서 많이 추상화 되긴 했지만, 변하지 않는 사실은 0과 1로 이루어진 일련의 숫자를 로직과 표준이라는 임의의 규칙에 맞춰 구분한 것이라고 볼 수 있다. 물론 이 0과 1로 이루어진 숫자를 보고 실제 환경과 동작을 알수 있는 사람은 현대에는 거의 없을 것 같긴하지만, 추상적인 상위 OS 에서 하위로 파고 내려가는 리버싱이나 포렌식, 악성코드 분석 같은 부분을 보면 그런 하위로 내려가는 노력도 필요한 분야는 여전히 건재한 듯 하다.

  보안 쪽에서는 그런 부분 이외에도 파일의 특정 공간에 숨겨진 데이터 라든지, 프로토콜 안에 숨겨진 데이터 등등 보통 밖에서 보기엔 완전하게 하나의 개체로 추상화된 데이터의 조작된 내부를 봐야 하는 경우가 많은 것 같다. 이러한 해체적 관점(좀 과장은 됬다)에서 한번 업로드, 다운로드를 살펴보려고 한다.

2. 다운로드 문제

  일단 파이썬으로 이루어진 엑셀 다운로드 기능을 하나 보자.

2.1 모듈 설치

  우선 필요한 모듈을 설치한다. 어떤 글을 봤냐에 따라 이미 설치된 모듈도 있을 것이다.

C:\Python\code>pip install pandas

C:\Python\code>pip install openpyxl

C:\Python\code>pip install numpy

C:\Python\code>pip install flask

2.2 엑셀 다운로드 구현

  예전에 파이썬 때 만들었던 pandas 코드와 구글 검색으로 찾은 flask 코드를 대충 합치면 아래와 같다. (플라스크 구현 부분이 이해가 안되면 파이썬 글 19교시 flask 편을 보고 오면 된다)

[flask_excel_down.py]

   c:\python\code 폴더에 "flask_excel_down.py" 이름으로 UTF-8 인코딩으로 저장 후 실행하면 플라스크 웹 서버가 실행 된다.

C:\Python\code>python flask_excel_down.py
....
 * Running on http://127.0.0.1:5000/ (Press CTRL+C to quit)

  이후 브라우저 주소창에 http://127.0.0.1:5000/excel_down 이라고 적으면 아래와 같이 pandas 데이터가 저장된 엑셀 파일이 다운된다.

2.3 코드 살펴보기

  이제 동작은 확인했으니 위의 코드를 한번 살펴보자. 첨에 테이블 형태의 pandas 객체가 만들어지고, io.BytesIO() 라는 바이트 형태의 파일 스트림이 하나 만들어 진 후(output = io.BytesIO()), 해당 스트림안에 pandas 를 사용하여 엑셀 데이터를 만들어 채워 넣게 된다(writer = pd.ExcelWriter(output)).

  이후 해당 파일 스트림을 저장 후에, HTTP 형태로 응답을 생성하면서, 엑셀 파일의 전달에 맞는 헤더를 설정한다(resp.headers['Content-Disposition'] = 'attachment; filename=output.xlsx', resp.headers["Content-type"] = "text/csv"). 브라우저는 해당 응답을 받아 엑셀 파일 형태임을 인지하고, 사용자에게 엑셀 파일로 저장하라는 선택 창을 보여주게 된다.

2.4 피들러로 살펴보기

  이제 네크워크 단에서 전송 되는 부분을 살펴보기 위해서 피들러를 통해 봐보자. 피들러의 resonse 섹션에서 raw 탭을 클릭해 보면(이제 기존 글을 봤다면 피들러 사용 법은 어느 정도 익숙해 졌다고 생각해서 자세한 스탭은 생략한다. 잘 모르는 경우는 파이썬 글 WhoIS API 편에 설명되어 있으니 그 쪽을 보고 오면 된다), 아래와 같이 raw 탭을 클릭해 보면 헤더 값 뒤에 암호화 된 것만 같은 엑셀 파일 내용을 인코딩한 데이터가 브라우저로 전달되고 있다.  

  헤더 부분 탭만 클릭해 따로 보게 되면 아래와 같이 text/csv 라는 content-type 으로 지정되어, 브라우저가 이게 엑셀 파일이구나를 명시적으로 알게되어 파일로 저장하도록 유도한다.

2.5 다운로드 문제 생각해 보기

  위의 예제를 보면 우리가 일반적으로 받아들이는 것과는 조금 다르게 내부적으로는 실제 무언가가 다운된다는 행위가 실제로는 엑셀 파일 형태의 일련의 데이터 스트림이 서버에서 만들어져 브라우저 쪽으로 복사되어 전달되는 것이라는 것을 볼 수 있다. 정확하게 얘기하면 복사(또는 반사)에 가깝다. 이렇게 보면 사실 다운로드의 보안 문제는 복사된 데이터가 넘어올때, (누군가가) 원하지 않은 복사된 데이터가 넘어오는 경우라고 볼 수 있다.

  그럼 어떤 경우 원하지 않는 데이터가 복사되어 올까? 사실 취약점이란 공격자에게 이점을 주는 관점에서 명명되는 것이기 때문에, 기대하지 않았던 이상한 데이터가 사용자가 넘어오는 부분은 보통 버그지 보안 쪽에서 초점을 두는 부분이 아닐 것이다. 그래서 보통 다운로드 취약점하면 서버 쪽에서 보내길 원하지 않는 데이터(파일, 데이터)가 전달 될때 문제가 된다. 

  웹에서의 다운로드는 굳이 분류하자면 4가지 정도 타입으로 나눠 볼수 있는데, 첫 번째는 우리가 브라우저에서 이미지 URL 을 입력했을때 이미지가 다운되서 보이게 되는 것 같은거, 두 번째는 서버쪽 프로그램에서 임의의 URL 을 조합해 생성해서 우리한데 해당 경로의 파일이나 이미지를 전달해 주는 경우, 세 번째는 위의 엑셀 다운 프로그램과 같이 서버쪽에서 조합된 데이터(보통 관리자 화면 같은데서 데이터베이스에서 조회한 데이터를 엑셀 형태로 만들어 다운로드가 되는 경우가 많다)를 다운로드 하는 경우, 마지막으로 가장 특수한 경우긴 하지만 사용자가 자신이 올린 파일이나 권한 있는 파일만 다운로드 해야 할 경우가 있는 경우이다.

  첫 번째 URL 을 입력하는 경우는 사실 뭐 거의 막을 수 없는 경우인데, 중요한 파일이 직접 URL 을 입력해서 다운로드가 되는 부분이 문제이므로, 중요한 파일은 웹 루트 바깥의 경로에 두어 URL 로 다운로드가 되지 않게 하거나, 웹 서버 설정에서 접근 가능 확장자 필터링을 하여 다운로드가 불가능하게 하는 방법 밖에는 없다. 또한 디렉토리 리스팅 등의 웹폴더 내부의 파일 이름을 볼수 있는 등의 힌트가 되는 경우를 막고(사실 요즘 웹서버들은 기본적으로 disable 되어있긴 하지만) 근본적으로는 중요한 파일이라면, 뒤에 얘기할 네 번째 경우와 같이  설계를 해야된다.

  두 번째 서버 쪽 프로그램에서 사용자가 전송한 인자나 header 의 특정 값 요소에 따라 임의의 URL 을 조합해서 해당 파일을 전달해 주는 경우인데, 이 경우는 5교시에서 얘기한 클라이언트에서 날라간 인자를 믿는 클라이언트 코드 문제라고 볼 수 있다. 이 경우 부터는 사실 좀 애매모호하게 흘러가는데, 보통 Directory Traveral(디렉토리 트레버셜) 문제인 ../../ 같은 상위 디렉토리를 거슬러 가거나 하는 문자를 파일 이름이나, 경로로 사용될 인자에 넣어 악용해 생기는 문제이므로, 밑의 업로드 예제에서 보이게될 werkzeug.utils 모듈의 secure_filename 같은 함수를 사용하여 인자에서 해당 문자들을 제거하거나 하는 방법이 있긴하다. 하지만 보통 이 부분이 레거시 코드를 수정하는 경우는 디렉토리를 만드는 규칙이나, 파일 이름의 생성 등과 대치되는 상황이 생길수도 있다(뭐 새로 코드를 다시 만든다고 해도 기존에 이미 있는 파일은 어떻게 해냐하는 마이그레이션 문제가 생길 수 있다)

[디렉토리 접근 공격 - H@ck.pe.kr]

https://hack.pe.kr/91

  대부분 이런 경우는 요구사항 구조상 파일 이름이나 번호 등을 인자로 받아 지정한 파일을 전달할 수 밖에 없는 경우므로, 개인적으로 추천하는 방법은 디렉토리 경로는 고정(상수나 config 값으로)시키고, 파일이름만 넘겨 받아 위에 언급한 secure_filename 와 비슷하게 각 언어에서 지원해주는 이름에서 위험한 문자들을 제거해 주는 메서드를 적용하는 것이다. 물론 이렇게 하려면 업로드 할때도 같은 함수를 파일 이름에 적용하거나, 아예 알파벳과 숫자로만 제한된 파일 이름으로 저장해야 호환성 문제가 발생 안한다.

  세 번째는 사실 위와 같이 허용되지 않는 파일을 다운로드 하는 측면의 문제라기 보다는, 허용되지 않는 데이터를 조회하는 측면에 가깝다(그 조회된 내용이 엑셀 형태로 브라우저로 전달될 뿐이다). 이 경우 실제 파일이 다운로드 되는게 아니고 데이터베이스를 조회한 데이터가 엑셀로 만들어 지는 일이 일어날 뿐이므로, 데이터베이스에 조회하는 인자들의 SQL Injection 이라든가, 또는 비슷하게 데이터를 만들어 낼때 악용될 수 있는 클라이언트 인자의 조작 부분을 방어하면 될 듯하다.

  마지막으로 네번째는 가장 엄격한 형태라고 볼수 있는데, 사용자의 이력서가 올라가는 사이트라든지, 해당 회원만 다운받을 수 있는 파일이라든지(예를 들어 웹툰 미리보기?) 같은 문제이다. 이 경우는 보통 권한을 관리해 주는 추가적인 데이터베이스 설계가 필요한데, 파일의 리스트를  관리하면서 해당 파일들을 다운로드 할 수 있는 사용자 권한을 지정하는 형태이다. 사용자가 해당 파일의 다운로드를 요청했을때, 테이블의 다운로드 권한을 조회해 해당 파일이나, 데이터의 로드(사용자에게 보내기 위한)을 결정하게 된다.

  그런 파일들은 보통 웹경로로는 다운 받을 수 없는 위치에 있고, 어플리케이션은 해당 사용자의 토큰을 통해 권한을 획득한 후, 가져와 메모리 상태에서 사용자 브라우저에 전달하게 되며, 개인정보 파일이나 아주 중요한 파일의 경우는 저장 할때도 암호화하여 저장하여 일반적인 권한과 루트로는 접근을 하지 못하도록 해야 된다. 다만 이 부분은 모든 다운로드 가능 파일의 사용권한을 체크하는 번거로움이 있고, 첫번째나 두번째 경우같이 일반적인 웹 서버의 GET 요청에 의해서 파일을 가져가지 못하므로 서버하 하는 일이 많아 조금 더 힘들어할 거 같은 부분이 있긴 하다.

  뭐 여튼 위와 같이 여러 상황과 니즈가 생길 수 있으므로 그때그때 마다 적절히 설계를 하면 될것 같긴하지만, 중요한거는 처음 얘기한 것과 같이 다운로드 문제는 원하지 않는 데이터가 복제되어 나가는 상황이라는 것을 잊지않는 것이다. 해당 이해를 기반으로 다운로드가 필요한 어플리케이션 형태를 고려해 찬찬히 고민해 본다면 적절한 설계를 할 수 있게 될 것 같다.

3. 업로드 설계

  이번에는 업로드 동작을 살펴 보도록 하겠다. 마찬가지로 파이썬 flask 로 구현하고, 딱히 추가로 설치할 모듈은 없다.

3.1 파일 업로드 구현

  구글을 찾아보니 아래 샘플을 이용하면 될 것 같다. 오타를 수정하고, 내용을 적당히 바꾼 소스를 보면 아래와 같다.

[Flask – File Uploading - Tutorialspoint 사이트]

https://www.tutorialspoint.com/flask/flask_file_uploading.htm

  우선 템플릿을 하나 만든다.

[upload.html]

실습을 하는 c:\python\code 폴더에 templates 폴더를 만들고, 해당 폴더안에 upload.html 이라고 UTF-8 포맷으로 저장한다. c:\python\code\templates\upload.html 파일이 된다.

  이후 실제 로직을 처리할 flask 코드를 만든다.

[flask_upload.py]

  해당 파일을 c:\python\code 폴더에 "flask_upload.py" 이름으로 UTF-8 인코딩으로 저장 후 실행하면 플라스크 웹 서버가 실행 된다. 

C:\Python\code>python flask_upload.py
....
 * Running on http://127.0.0.1:5000/ (Press CTRL+C to quit)

  이후 브라우저에서 http://127.0.0.1:5000/upload 입력하면 아래와 같이 업로드할 파일을 선택하는 창이 뜬다.

  다른 폴더에 있는 그림 파일을 하나 선택한 후, "파일 업로드" 버튼을 누르면 아래와 같이 업로드가 완료되었다는 화면이 나온다. 플라스크를 실행한 c:\python\code 안을 보면 업로드한 이미지가 올라가 있다. 

3.2 코드 살펴보기

  마찬가지로 위의 업로드 코드를 살펴 보자. /upload 호출에서 업로드 upload.html 파일을 랜더링해 화면에 보여준다. 해당 HTML 소스를 보면 파일 형태를  보내기 위해 전송방식이 POST 로 되어있고, 파일 업로드시 내용이 깨지지 않게 인코딩을 해달라는 (enctype = "multipart/form-data") 인코딩 방식이 정의되어 있다(앞의 암호화 파트에서 본 Base64 인코딩을 생각하며 된다)

  실제 올라온 파일을 처리하는 /upload_process 코드를 보면 POST 로 넘어온 값 중에 이름이 upfile 인 폼 요소 값을 가져와서 파일을 저장하는 객체(f)에 담고, 해당 넘어온 파일의 원래 이름을 f.filename 기준으로 플라스크 실행 폴더 루트에 저장을 한다. secure_filename 이라는 함수는 라이브러리에서 넘어오는 보통 업로드나 다운로드 등에서 많이 얘기되는 ../ 같은 악용문자들을 제거해주는 함수 이다. 위에 다운로드 설명할때 언급했었다.

3.3 피들러로 살펴보기

  다운로드와 동일하게 업로드 파일이 올라가는 순간의 모습을 피들러로 봐보자. 버튼을 눌렀을때 호출되는 http://localhost:5000/upload_process 호출의 Request 부분에서 Raw 탭을 마찬가지로 보면, 다운로드와 비슷하게, 헤더 쪽에는 데이터의 종류를 알려주는 content-type 이나, 이미지 데이터가 언제 끝나는지 알려주는 boundary 값(하단으로 스크롤 하면 맨 마지막에 저 값이 있다), 폼 요소 이름(name="upfile")이나, 파일 이름(IMG_0071.JPG), 파일의 종류(Content-Type: image/jpeg) 도 있다. 그 밑에 글짜가 깨진거 같이 보이는 이미지 파일이 인코딩된 데이터가 있게 된다.

  형태를 보게되면 앞의 다운로드 코드를 본 것과 많이 비슷하며, 전달되는 여러 정보들이 이번에는 브라우저가 아닌, 서버쪽 처리 프로그램을 위한 것이라는 부분만 상이하다고 봐도 될것 같다.

3.4 업로드 문제 생각해 보기

  결국 업로드도 다운로드와 비슷하게 전달된 데이터의 올바른 처리 문제라고 볼수 있다. 다만 조금 다른 측면은 이번엔 보내는 쪽이 사용자 쪽이므로, 데이터 형태가 비교적 정형화됬던 다운로드와 별개로 적극적으로 공격자의 조작이 가능하다는 것이다.

  정상적인 파일의 헤더 같은 부분에 악성 코드를 살짝 숨겨 놓을 수도 있고(관련 해석기의 취약점이 있다면 영향을 줄수도 있다), 리눅스 쉘을 사용하듯이 특정한 명령어를 원격에서 웹 인터페이스를 통해 실행할 수 있게 해주는 웹쉘(WebShell)이라고 불리우는 악성 코드를 업로드 하려고 시도하거나, CMD Injection 취약점 처럼 특정 파서와 만나서 실행되는 코드를 파일내에 삽입하거나, 확장자나, 저장되는 경로를 속이려는 여러 시도를 할 수 있다.

  업로드는 보통 2가지 정도의 타입으로 분류할 수 있는데, 첫번째는 엑셀이나 텍스트 파일을 업로드해 일괄 처리를 하는 형태가 있고, 두 번째는 아까 얘기한 이미지나, 이력서 파일 등을 서버로 올려서 해당 형태 그대로 저장해 게시물이나, 증빙 목적으로 열람하는 형태가 있다.

  첫번째의 경우는 보통 업로드된 파일을 굳이 서버의 특정 경로에 저장해서 일어나는 경우라고 볼 수 있는데 종종 장애 등의 디버깅 상황을 위해서 그런 경우도 있고, 구글 등 검색 엔진에서 노출되는 레거시 코드를 참조해 만들다가 그런 경우도 있는듯 싶다(경험상 예전 프로그램 코드들이 좀 이런 형태가 많은 듯 하다). 요즘은 아예 자바스크립트에서 파싱해서 데이터만 JSON 형태로 보내거나, 서버에서 바로 메모리상에서 처리하고 저장하지 않는 경우도 많아 잘 발생하지 않는 듯도 싶다. 해당 언어에서도 그렇게 가이드 하고 말이다. 

  파일을 저장하는 레거시 코드인 경우 같은 경우는 코드 전체를 뜯어고치기 힘들다면, 저장 경로를 웹 서버 바깥으로 저장하고, 처리 후 삭제를 하게하는 것이 보안적이나, 웹서버에 쓸데없는 파일이 남게 되는 것을 방지하는 차원에서도 좋다. 물론 이 경우에도 뜻하지 않던 경로를 가리키도록 조작하여 접근하는 이슈는 남을 수 있어서, 뒤에 얘기할 부분들도 함께 적용을 고려해야만 한다.

  두번째의 경우가 보통 웹의 업로드 문제에서 자주 일어나는 부분인데, 보통 웹 형태로 된 게시판 등에서 이미지를 업로드 하거나, PDF 등의 문서 등을 업로드 하는 경우이다. 이 경우 확장자를 체크한다던지, MIME 타입을 체크한다든지, 이름과 경로가 될 인자에서 특수문자를 제거한다든지, 실제 업로드된 이미지 같은 파일이 실제로 그런 종류의 파일인지 체크하는 등 여러 방법을 혼용해서 가이드 하긴 하지만, 개인적으로 가장 안전한 방법은 저장 경로나 이름을 결정할 때 클라이언트 코드를 참고 안 하는 거라고 생각한다.

  예를 들어 서버 쪽의 저장 폴더 경로를 고정된 상수나 config 값으로 정해 놓은 후, 파일 이름을 날짜와 해시값, 난수 등을 조합한 서버를 기반한 고유 값으로 생성하고, 검증이 끝난 특정 확장자를 명시적으로(예를 들어 exe = ".jpg" 후) 확장자로 연결해 저장한다면, 외부에서 공격을 하고 싶어도 공격할 수 있는 부분이 안 생기게 된다(이 부분은 클라이언트 코드 편에서도 얘기를 했다). 만약 실제의 포맷이 다른 이상한 파일이 올라가는게 탐탁치 않은 경우는(예로서 .jpg 인데 안의 내용은 스크립트) 서버쪽에서 저장하기 전에 실제 해당 포맷의 파일이 맞는지를 확인하는 메서드를 쓰면 될듯 싶다. 물론 업로드 폴더의 스크립트 실행권한을 제거한다든지, 상황에 따라 업로드 폴더를 웹 경로 바깥으로 뺀다든지 하는 부분도 기본적으로 필요하다.

  다만 이러한 설계라해도 100% 안전한다고는 볼수는 없다. 예를 들어 웹서버 파싱 모듈에 취약점이 있어서 스크립트로  내용이 구성된 .jpg 확장자의 파일이, 호출시 스크립트를 실행한다는 경우가 생길 수도 있겠지만, 현실적으로 일어나긴 힘들고 해당 경우는 일어나더라도 해당 해석 모듈의 패치로 해결하는게 정석일 거 같다. 뭐 여튼 버그건 취약점이건 간에 앞에 얘기했듯이 컴퓨터의 모든건 0과 1의 세상이기 때문에 발생할 가능성이 zero 라고는 절대 말하진 못한다. 

4. 마무리 하면서

  이번에는 방어코드 보다는 구현코드 위주로 구성한게 조금 걸리긴 하지만, 어차피 업로드, 다운로드 취약점에 대한 가이드 들은 구글을 찾아보면 많이 나오고, 그 세세한 내용 보다는 그 글들이 왜 이런 방어를 하자고 얘기하고, 그 경우 생길 수 있는 blind spot 을 생각해 보자는 의미에서, 동작 구조를 이해할 수 있는 코드를 위주로 설명했다. 사실 공식화 되어 있는 듯한 다른 보안 이슈들도 이런 모호한 측면들이 언제든 현실에서 발생할 수 있다. 그래서 계속적으로 관련된 프로그램의 구조나 환경을 이해하려 해야 되는 것이고 말이다.

  또 하나 더 강조하고 싶은건 결국 모든 컴퓨터 내를 구성하는 요소들은 0과 1들을 임의의 로직대로 추상화해 놓은 것이라는 것을 마음속 한 구석에 담아두길 바라는 맘도 있었다. 예전에 파이썬 글에서도 소개했었지만 마음의 여유가 있으신 분들은 아래 책을 꼭 한번 읽어보기를 추천한다. 결국 스스로에게 갇히지 않기 위해서는 다양한 관점에서 같은 대상을 바라보는 훈련도 계속 필요한 듯은 싶다. 

CODE 코드 : 하드웨어와 소프트웨어에 숨어 있는 언어(이건 프로그래밍 공부가 의미 없게 느껴지는 분들을 위해서 덤으로~ 불빛 신호에서 컴퓨터가 만들어지기 까지의 과정을 설명한다. 중간에서 길을 잃어 필름이 끊기더라도 읽어볼 가치가 있다고 본다. 비 전공자한테는 생각보다 어려울지도 모르지만, 해당 책의 저자가 비전공자도 읽을 수 있도록 노력해 쓴 책이고 파이썬 공부를 하고자 하는 의지 정도만 있음 가능할 듯 싶다.)

  그럼 즐거운 공부되길 바라며, 아직 어떻게 표현하면 좋을지 감이 안잡히는 주제들도 있지만 금년엔 가능한 자주 올려 이 시리즈를 마쳐볼 수 있도록 노력해 보려 한다 --;