목차
- 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 공격이 가능함.
[+] 유튜브 요청/응답 기록 보면서 CORP 헤더도 발견했는데 이건 이미지나 비디오 등의 자원을 출력도 못하게 막는 정책인 듯함. SOP, CORS는 출력은 가능함. 셋 다 자바스크립트 접근은 불가능.
요청 방식과 보안 정책에 따른 CSRF 공격 시나리오
제목만큼 거창하진 않음..
▷ 도달하는 결론
- 링크로 공격
- 외부 공격 페이지 활용 가능
- 같은 도메인에서 XSS 쥐 잡듯이 찾기
▷ 전제 조건 (CSRF 포인트 발견)
- CSRF 포인트에서 인증 정보를 포함시키지 않음
- CSRF 포인트에서 Referer헤더를 체크하지 않고 있음
▷ 로드맵
분기점 발생 기준
1) 요청 방식 (GET / POST)
2) 보안 정책 상태
※ 배우는 단계에서 정리하는 거라 예외 있을 수 있음.
SOP와 CORS 모두 외부에서 불러온 자원을 자바스크립트로 활용하는 걸 막는 정책이기 때문에 CSRF 토큰조차 필요 없는 요청이면 그냥 외부에서 공격 가능한 것 같음. 단순히 요청을 보내는 건 외부 자원을 불러올 필요도 없응께...
근데 세션쿠키가 아니라 JWT같은 걸로 사용자 식별/인증하면 요청에 자동으로 포함시킬 수 없으니까 그냥 같은 도메인에서 크사 쥐 잡듯이 찾이야 함
CSRF 대응 방법
경우에 따라 적당한 방법으로..
Referer 헤더 체크
- Referer 헤더: 이 요청이 전송된 곳 (파일 경로)
- referer헤더에 올 수 있는 페이지를 화이트리스트로 허용 (특정한 페이지에서 온 요청만 처리함)
- 예를 들어, mypage.php페이지에서 이루어지는 개인정보 변경 요청은 referer가 mypage.php인 요청만 처리
- 요청 출처가 아니라 요청 페이지(상세한 파일 경로)를 가리기 때문에 CORS보다 더 엄격할 듯함.
▷ 우회 가능 상황
- 허용되지 않은 요청에 대한 예외 처리가 허술할 경우 우회 가능할 수 있음. (문제가 있대? 걍 보내자..)
- 예를 들어 Referer 헤더를 삭제한 뒤 다시 요청 보내면 통과시켜줌.
- referer 없이 요청 보내기
<meta name="referer" content="no-referer">▷ 예외 처리가 허술해지는 이유
- 허용되지 않은 페이지에서 온 요청에 대한 응답으로 "Invalid referer header." 가 표시됨.
- 일일이 허용된 페이지 리스트에 추가해줘야함. 확장성이 떨어짐.
예외 처리가 허술한 경우가 아니면 우회 불가능
인증 정보
- 요청에 사용자만 알 수 있는 인증 정보를 포함시키게 함.
- 인증 정보 예시: 비밀번호
- 비밀번호 변경 시 기존 비밀번호 입력 필수 -> 공격자가 알지 못함 (알아도 CSRF를 하기보다 갖다 팖)
- 가장 근본적인 대응 방법
CSRF 토큰
- CSRF 공격에 대응하기 위해 요청에 포함시키는 랜덤한 토큰 값
- 근데 경우에 따라 탈취할 수 있음.
▷ 탈취할 수 있는데도 쓰는 이유
- CSRF는 모든 요청에서 일어날 수 있음.
- 하지만 모든 요청에 비밀번호같은 인증 정보를 요구하면 사용자 경험 개판남.
- 사이트에서 사용되는 요청 중 공격자가 위조했을 때 피해자가 입을 손해가 비교적 적은 요청은 CSRF 토큰으로 일괄 대응
- 요청 위조에 대해 완벽 차단은 못하지만 공격자의 의지를 꺾을 만함. (위험도가 애매한 요청에서 굳이 XSS를 찾아가며 요청을 위조할 이유는 없음.)
상황 봐서 가장 추천할만한 대응 방법을 고민!!!
'웹 > 모의해킹 스터디 복습' 카테고리의 다른 글
| 모의해킹 스터디 14주차(2): 파일 업로드 - 우회 가능 케이스 (1) | 2025.02.05 |
|---|---|
| 모의해킹 스터디 14주차(1): 파일 업로드 (0) | 2025.01.31 |
| 모의해킹 스터디 13주차(1): CSRF vs XSS (1) | 2025.01.17 |
| 모의해킹 스터디 12주차: CSRF (사이트 간 요청 위조) (0) | 2025.01.14 |
| 모의해킹 스터디 11주차: XSS - 데이터 추출, 대응 방안 (0) | 2024.12.30 |