1. CSRF 개요
▶ CSRF 개요
- 정상적인 요청과 조작된 요청을 서버가 구분하기 못 할 경우 발생하는 취약점
- 애플리케이션을 이용하는 사용자로 하여금 조작된 요청을 웹 어플리케이션에 전송하도록 유도하여 피해를 발생시킴
- 공격 당한 사용자의 권한을 그대로 사용하므로 사용자의 권한 수준에 따라 피해 범위 달라짐
- XSS 취약점과 무관하게 공격이 간으하나 XSS 취약점과 연계 시 더 공격 범위가 증가함
▶ CSRF 예제
- 공격자는 조작된 요청 게시물 등록
- 희생자는 공격자가 등록한 게시물을 열람하고, 희생자 브라우저는 서버로 요청 패킷을 전송
- 서버는 조작된 요청에 대한 응답 패킷 전송
- 브라우저는 조작됨 요청에 대한 응답값을 수행 ( 공격자 목적대로 됨 )
▶ CSRF 원인
- 사용자의 요청을 서버가 적절한 검증절차 없이 받아들여서 해당 사용자의 권한으로 임의의 동작을 그대로 실행시켜 발생함
- 취약점 발생 point : 글 등록, 정보 수정 등 사용자가 서버에 일정한 데이터를 요청하는 모든 기능
- 예상되는 피해 : 타 사용자 권한 도용, 임의의 사용자 정보 변경
▶ CSRF vs XSS
| CSRF | XSS |
|
|
XSS
- 공격자는 XSS 취약점이 존재하는 사이트에 악성 스크립트를 삽입
- 관리자는 공격자의 악성 스크립트가 포함된 페이지에 접근
- 페이지를 불러오면서 관리자의 브라우저는 악성 스크립트를 실행
- 악성 스크립트 실행의 결과로 관리자의 정보가 공격자에게 넘어감
CSRF
- 공격자는 관리자가 열람할 만한 곳에 공격대상 페이지로 접속을 유도하는 글을 작성
- 관리자는 공격자가 작성한 글을 열람
- 관리자가 글에 포함된 URL을 클릭하거나 관리자의 브라우저가 스크립트를 실행
- 관리자의 브라우저는 공격 대상 서버로 공격자가 원하는 특정 행위를 요청
- 공격 대상의 세부 예시 : 메일 전송, 금융거래, 공지 작성 등 다양한 행위 유도할 수 있음
2. CSRF 예제 / 진단방법
▶ 예제 1 : 타 사용자의 원한 도용
게시글에 스크립트를 포함하여 놓고 게시클을 타사용자가 클릭할 때 스크립트 내용처럼 사용자가 움직임
사용자 브라우저는 아래 브라우저로 요청 패킷을 보내고 사용자 권한으로 자동으로 댓글 달림
▶ 예제 2 : 권한 상승
관리자가 해당 게시글 열람시 권한상승함
▶ 예제 3 : 타 사용자 비밀번호 변경
▶ CSPF 공격포인트 예
- 중요한 기능에 대해서 CSRF 공격 가능 여부 검토 : 선물하기, 추천하기, 친구 추가/삭제, 개인정보 변경, 온라인 캐쉬 사용, 개인설정 변경, 비밀번호 변경
- 사용자가 데이터를 서버로 전송하는 기능 : 서버로 전송할 데이터 중 사용자 권한, 인증과 관련된 항목을 변조 후 서버의 정상처리 여부 확인
- 추가 인증을 하지 않는 페이지 : 비밀번호 변경시 현재 패스워드 같은 추가 인증 수단이 적용되지 않은 경우
3. 보안 대책 / 우회
▶ 보안 대책 요약
▶ 예제
- GET 메소드로 보내서 실패함
- 위를 우회해서 POST 메소드로 보냄 -> 권한 변경됨
6-9 : POST 메소드로 전송 ( id에 skinfosec을 level에 9를 넣어 권한상승시킴 )
11 : 원래 0 0으로 해서 눈에 보이지 않게함
15 : 어디로 전송할것인지
- 토큰 보안대책 우회하여 공격
토큰값은 이 페이지에 접근할 때 일회성으로 생김 -> 매번 바뀌는 토큰값 몰라서 공격 불가능
토큰값 변조에 권한 수정
10 : 토큰값 보이는 페이지 - > 열릴때 토큰 생성됨 csrf() 불러옴
13-16 : csrfi 불러와 값 가져옴 token값도 가져옴
21-24 : 새로운 요소를 만들어 자식 요소로 만들음
▶ CSRF GET/POST
- HTTP Method에 대한 검증을 하지 않을 경우 GET/POST 메소드는 서버에서 동일한 요청으로 처리
- GET 메소드 허용시 공격자는 URL로 CSRF 공격을 하여 관리자가 서버로 요청을 보내도록 유도할 수 있음
- 따라서 POST 메소드만 가능하도록 로직을 추가하면 URL로 요청하는 CSRF 공격을 막을 수 있음
- POST 메소듬나 허용하는 보안 대책의 한계 : POST 메소드로 요청을 보내도록 하는 스크립트로 우회 가능
- GET/POST 우회 : 아래의 POST 메소드로 id와 level 파라미터를 변조하는 스크립트를 포함한 게시글을 작성하여 관리자가 게시글 클릭 시 공격자 권한으로 수정됨, POST 메소드만 허용하는 방식의 CSRF 보안 대책은 안전하지 않음
▶ Submit Button
- 사용자 권한 변경 요청이 관리자 권한의 요청인지 확인하는 검증 로직을 구현
- 예를 들어 사용자 권한 변경 페이지에서 관리자의 요청인지 확인할 수 있는 버튼을 만드는 것
- Submit Button 대신 Prompt 형태로 관리자의 권한 요청인지 확인 받을 수 있음
- 한계 : 관리자 권한 요청의 인증값이 고정되어 있으면 공격자가 그 값을 사용하여 우회 가능
- Submint Button 우회 방법 고정된 인증 정보가 포함되어 있는 공격 스크립트 게시글을 작성하여 관리자가 게시글 클릭 시 공격 가능 Submint Button, Prompt 등 관리자 요청인지 확인하는 방식의 CSRF 보안 대책은 안전하지 않음
▶ XSS 취약점 제거
- 동일 도메인 내 XSS 취약점을 제거할 경우 CSRF 공격 범위가 줄어듬
- XSS 취약점 제거 우회 : XSS 취약점이 있는 다른 도메인에서 공격 스크립트에 접근하게 만들면 CSRF 공격이 발생, 외부 사이트에서 공격 스크립트 유도
▶ 보안토큰 사용
- Submit Button 에서 본 것처럼 고정된 값으로 인증할 경우 우회가 가능
- 고정값이 아닌 수시로 변경되는 인증값을 가질 경우 CSRF 공격을 할 수 없을 것임
- 관리자가 요청을 보내는 페이지를 호출할 때마다 페이지 자체에 임의의 값(Token)을 삽입하여 서버로 Request를 보낼 때 서버에서 그 값을 검증하여 관리자가 보낸 요청인지 확인함
- 한계 : 스크립트를 이용해 hidden 필드의 Token을 획득하여 우회가 가능
- Token 프로세스 요약 관리자가 권한 수정 페이지를 요청하면 서버는 Token을 생성해서 페이지에 같이 포함하여 응답하고, 관리자의 브라우저는 Token값을 웹페이지와 함께 전달받아 권한 수정 페이지를 출력함. 이후 관리자가 권한 수정 페이지에서 수정버튼을 누르면 서버로부터 받은 Token을 포함하여 요청 패킷이 전송되는 서버는 Token 값이 변조되지 않았는지 확인하는 방법으로 Token값이 없거나 직전 페이지에서 저장한 값이 아니면 CSRF공격이라고 탐지하는 보안기법
- 우회 방안 : 첫 번째 Request로 Token을 획득, 두번째 Request로 Token을 포함하여 파라미터 인자를 변조하는 방식으로 Request를 두 번 보내는 스크립트를 작성하여 관리자가 해당 스크립트 접근 시 CSRF 공격 가능
- 보안토큰 사용 : 앞 페이지의 스크립트가 포함된 게시글을 관리자가 클릭 시 아래와 같이 요청값을 두 번 보내게 되어 CSRF 가능
▶ Captcha
- Captcha : 요청을 보낸 대상이 사람인지 컴퓨터 프로그램인지를 구별하기 위해 사용되는 방법 / 자동가입 방지에서 CSRF 방지용으로 많이 사용됨 / 중간에 개입 못해 가장 안전
- Token 방식과의 차이점 : 인증값을 미리 획득 할 수 있는지 여부 / Captcha는 이전 페이지에서 인증값에 해당하는 이미지를 전달하고 이미지는 매번 바뀌어 인증값을 미리 획득 할 수 없게 구서외어 있음 / 인증값을 획득할 수 없으므로 보안상 가장 안전하고 우회가 불가능 / 관리자가 접근 시 추가적으로 입력해야 하는 번거로움이 있음
- Captcha 예제 페이지 화면 : Captcha 방식이 적용된 로직 / 관리자로부터 Captcha를 입력 받는 페이지 화면 / 다른 페이지로 입력을 받을 수도 있고 동일 페이지에서 입력을 받도록 구현 가능 / 예제는 페이지를 추가하여 입력을 받음 / 이미지 파일에 있는 값을 모르므로 더 안정
- Captcha 검증 : 인터넷에서 쉽게 찾을 수 있는 simpleCaptcha를 사용 / 서버로 오는 Request와 Captcha의 값을 비교하여 값이 다른 경우 CSRF로 판단하고 경고창을 띄우며 요청 전 페이지로 돌아가게 함
- Captcha 프로세스
