모의해킹 스터디 13주차(2): CSRF - 보안 정책, 대응 방안

목차

• CSRF 관련 보안 정책

       - SOP

       - CORS: ACAO헤더, ACAC헤더

• 요청 방식과 보안 정책에 따른 CSRF 공격 시나리오

• CSRF 대응 방법

       - Referer 체크

       - 인증 정보

       - CSRF 토큰

 

 

 

 

 CSRF 

Cross-Site Request Forgery

 

피해자가 자신의 의도와 무관하게 서버로 어떤 요청을 하게 만드는 공격.

 

 

 CSRF 관련 보안 정책 

~ 왜 XSS를 찾아야 했나 ~

• SOP
• CORS

 SOP          

Same-Origin-Policy (동일 출처 정책)

• 같은 출처에 있는 자원만 이용하게 함.
• 같은 출처: 도메인, 스키마, 포트가 모두 같은 사이트
• 브라우저가 자체적으로 작동시킴
• 자원을 불러올 수는 있는데 자바스크립트로 접근 불가

https://example.com:443/30 
1.        2.                    3.    4.

1) 스키마(프로토콜)
2) 도메인(호스트)  
3) 포트
4) 파일 경로 -> 달라도 되는 부분

*https://sub.example.com:443 같은 하위 도메인도 다른 출처로 처리

 

이 정책이 적용된 사이트는 자바스크립트로 다른 출처의 자원이나 응답에 접근할 수 없음.

 

아니, 너무 빡빡하잖슴~~

해서 나온 게 cors

 

 

 CORS          

Cross-Origin Resource Sharing (교차 출처 자원 공유 정책)

• 몇 가지 규칙에 해당하면 다른 출처에서도 데이터를 쓸 수 있게 완화된 정책
• 서버 응답 헤더에 포함됨

	Access-Control-Allow-Origin (ACAO) 헤더	Access-Control-Allow-Credentials (ACAC) 헤더
규칙	화이트리스트 기반으로 허용된 다른 출처가 응답의 ACAO 헤더에 표시되면 자바스크립트로 자원 접근 가능	ACAO: * 에 대한 대비책. 다른 출처에서 보낸 요청에 쿠키 등의 인증정보가 포함되면 ACAO 헤더 꼭 써야함.
예시	1) example.com의 게시글에 vuln.com/mypage.php 페이지를 iframe으로 가져옴. 2) 브라우저가 iframe 페이지 요청에 대한 vuln.com 응답의 ACAO헤더와 요청의 Origin(출처) 헤더 값 비교 3) ACAO헤더에 example.com 표시: ACAO == Origin. ->허용. js로 접근 가능 4) ACAO 헤더가 없거나 null 표시: ACAO !== Origin: ->거부. js로 접근 불가	1) 요청에 인증 정보 포함될 경우 -> Access-Control-Allow-Credentials: true 2) 허용: 인증정보 포함한 요청의 출처가 Origin과 같을 경우 -> Access-Control-Allow-Credentials: true -> Access-Control-Allow-Origin: https://example.com  -> js로 접근 가능  3) 거부:  --> 요청에 인증 정보 포함됐는데 ACAC: true 헤더가 없으면 요청 거부 --> ACAC: true인데 ACAO: * 이면 요청 거부  --> ACAC: true인데 ACAO 없으면 (화이트리스트에 없으면) 거부 => 평소엔 ACAO: *을 쓰되 요청에 인증정보 있으면 ACAC: true + ACAO == Origin 조건을 따라라
우회 가능 상황	Access-Control-Allow-Origin: * (모든 도메인에서 자바스크립트 접근 가능)	Access-Control-Allow-Credentials: true일 경우 ACAO에 요청 헤더의 Origin 도메인을 넣어서 보내고 있으면 우회 가능 요청의 Origin 값 변조 시 ACAO헤더가 변조된 값으로 변하면 이 경우에 해당 ACAO: * 와 마찬가지로 모든 도메인에서 js로 데이터에 접근할 수 있게 됨

• 보안 정책이 잘 지켜진 페이지의 경우 외부 공격 페이지에서 자바스크립트 활용 불가능 -> POST방식에서 CSRF 안됨.
• 그래서 이때는 공격 대상 사이트 내부에서 XSS를 찾아야 POST요청에 대한 CSRF 공격이 가능함.

유튜브 응답 헤더에서 발견할 수 있는 CORS.

 

[+] 유튜브 요청/응답 기록 보면서 CORP 헤더도 발견했는데 이건 이미지나 비디오 등의 자원을 출력도 못하게 막는 정책인 듯함. SOP, CORS는 출력은 가능함. 셋 다 자바스크립트 접근은 불가능.

 

 

 

 

 요청 방식과 보안 정책에 따른 CSRF 공격 시나리오 

제목만큼 거창하진 않음..

▷ 도달하는 결론

• 링크로 공격
• 외부 공격 페이지 활용 가능
• 같은 도메인에서 XSS 쥐 잡듯이 찾기

 

▷ 전제 조건 (CSRF 포인트 발견)

• CSRF 포인트에서 인증 정보를 포함시키지 않음
• CSRF 포인트에서 Referer헤더를 체크하지 않고 있음

 

▷ 로드맵

분기점 발생 기준

1) 요청 방식 (GET / POST)

2) 보안 정책 상태

 

※ 배우는 단계에서 정리하는 거라 예외 있을 수 있음.

 

 

 

 

 CSRF 대응 방법 

경우에 따라 적당한 방법으로..

 Referer  헤더 체크          

• Referer 헤더: 이 요청이 전송된 곳 (파일 경로)

위 요청은 mypage_update.php파일을 요구하며 비번을 변경하고 있지만 referer헤더가 id가 192인 게시글을 읽는 페이지인 상황. 다시 말해 게시글 읽는 페이지에서 비밀번호 변경을 요청하는 중임. (수상)

 

• referer헤더에 올 수 있는 페이지를 화이트리스트로 허용 (특정한 페이지에서 온 요청만 처리함)
• 예를 들어, mypage.php페이지에서 이루어지는 개인정보 변경 요청은 referer가 mypage.php인 요청만 처리
• 요청 출처가 아니라 요청 페이지(상세한 파일 경로)를 가리기 때문에 CORS보다 더 엄격할 듯함.

 

▷ 우회 가능 상황

• 허용되지 않은 요청에 대한 예외 처리가 허술할 경우 우회 가능할 수 있음. (문제가 있대? 걍 보내자..)
• 예를 들어 Referer 헤더를 삭제한 뒤 다시 요청 보내면 통과시켜줌.
• referer 없이 요청 보내기

<meta name="referer" content="no-referer">

 

▷ 예외 처리가 허술해지는 이유

• 허용되지 않은 페이지에서 온 요청에 대한 응답으로 "Invalid referer header." 가  표시됨.
• 일일이 허용된 페이지 리스트에 추가해줘야함. 확장성이 떨어짐.

예외 처리가 허술한 경우가 아니면 우회 불가능

 

 인증 정보          

• 요청에 사용자만 알 수 있는 인증 정보를 포함시키게 함.
• 인증 정보 예시: 비밀번호
• 비밀번호 변경 시 기존 비밀번호 입력 필수 -> 공격자가 알지 못함 (알아도 CSRF를 하기보다 갖다 팖)
• 가장 근본적인 대응 방법

 

 

 CSRF 토큰          

• CSRF 공격에 대응하기 위해 요청에 포함시키는 랜덤한 토큰 값
• 근데 경우에 따라 탈취할 수 있음.

▷ 탈취할 수 있는데도 쓰는 이유

• CSRF는 모든 요청에서 일어날 수 있음.
• 하지만 모든 요청에 비밀번호같은 인증 정보를 요구하면 사용자 경험 개판남.
• 사이트에서 사용되는 요청 중 공격자가 위조했을 때 피해자가 입을 손해가 비교적 적은 요청은 CSRF 토큰으로 일괄 대응
• 요청 위조에 대해 완벽 차단은 못하지만 공격자의 의지를 꺾을 만함. (위험도가 애매한 요청에서 굳이 XSS를 찾아가며 요청을 위조할 이유는 없음.)

 

상황 봐서 가장 추천할만한 대응 방법을 고민!!!