[8주차]CSRF의 현재 모습

*CSRF 현재의 모습.

과거와 다르게 현재는 우회가 어렵다.

우회가 되는 경우 어떠한 조건이 있어야하고 안되는 경우는 왜인지에 대한 이해가 필요하다.

*CSRF 개요
> 사용자들이 그들 스스로 의도치 않은 행동들을 (서버로의 요청) 하게하는 취약점.

브라우저에서 쿠키를 기본적으로 공유하기 때문에 발생하는 문제.
> 크사와 다른점: 클라이언트 측에 특정 스크립트(코드) 실행
크사로 요청 보내도 이게 받아지느냐 아니냐는 CSRF 의 취약점 유무에 달림.

>2017년 새롭게 발표된 OWASP TOP 10에서 제외되었다.

*CSRF
- 특정 수행 행동을 할 수 있다.(비밀번호 변경, 정보 변경, 글쓰기 등)
- 세션값이 필요하다.
- 예측 가능한 파라미터만 있어야한다.(옛날 비번같은게 예측 불가한 파라미터)


*공격/방어
(1) GET 메소드
-> 링크
(* 단 같은 페이지 내에서 링크를 클릭해야한다. 로그인하고있는 동안 수행)

(2) POST 메소드
크사
<form>
</form>

*CSRF 최근 근황 >> 이건 대응방안이아니고 원래 있는 정책들
- CSRF를 막기 위한 노력들


→ 기본적으로 공격자의 서버로 피해자를 유도한 뒤 공격을 발생시켰다.

> 쿠키: 세션아이디 도용을 막으려는 시도로 samesite, path 속성이 생김

예) 사이트 고정
path=/normaltic
~~~/com/normaltic/aaa

예) 도메인 samesite
none 같은 사이트가 아니여도 보내겠다.
lax 특정 규칙에 한해서만
strict 무조건 이 도메인에만

2020년 크롬 80 -> 기본 lax 설정.

> CSRF는 다른 페이지에 전송하는 요청, 이를 막기위한 정책
: CORS

도메인이 달라 samesite로 인해 요청이 막힘.

 

실제 에러 화면

: X-Frame-Option<**우회 불가

> CSRF 토큰넣는게 원래는 취약한데, 이 경우 좋은 대응방안.

과거) 사이트 내에 iframe 작성
이 프레임에서 가져온 정보 파싱해서 공격자에게 보내는 코드를 작성.
이렇게 우회했는데 X-Frame-Option 이 옵션이 이걸 막음.

> CSRF 예측 불가능한 파라미터 삽입
: CSRF 토큰
: 인증 정보

/
*CSRF조건
같은 웹사이트 내에서 요청해야한다.(CORS, X-Frame-Options의 영향)
GET: 피해자가 그 사이트에 로그인해있는 상태에서 그 링크를 클릭해야한다.
(세임사이트와 패스 속성이 있기때문에)
POST: XSS 취약점이 존재해야한다.
폼태그 작성. 같은 웹사이트 내에. 크사 취약점이 존재해야한다.
/

*모의해킹
업무 점검 대상 사이트 내에서만 함.

우회가 가능할 "수"도 있다.

어떻게 고쳐요? 
- 예측 불가능한 파라미터(인증정보)를 항상 넣고
- 그런게 아니고 너무 상시다 싶으면 (게시글 작성) 토큰 넣음

결론은 인증정보를 추가해서 막자.
토큰 시 우회 시도 몇번하고 안되면 안되는 것!

web security academy + 버프스윗
1. 겟방식으로 통하는지 제일 먼저 체크(포스트일 경우 메서드 바꿔서 포워드해봄)
토큰을 지워보고 요청 넣었는데 먹힐 수도 있음. 겟방식은 토큰없어도 실행될 수 있음.
WHY? >> *CSRF 토큰 검증 미흡
에러 처리 방식: False-Positive , False-Negative
$ token = $_POST['csrf'];
if($token){ 

}
2. URL을 만들어서 넣어 전달.
크사가 있을 시 이미지태그 사용해서 자동 실행 가능. 

3. CSRF 토큰이 허울일수있음. 한번 쓴 CSRF코드를 계속 씀.
겟방식으로 처리 안되는 경우, 포스트시 코드 작성함.

*CSRF 토큰 검증 미흡인 경우
(1) False-Positive
(2) CSRF 토큰 재사용
(3) CSRF 토큰 - 사용자 세션 매핑 안될때
원래 재사용 불가, 사용자의 세션과 토큰을 매칭
카를로스가 로그인해서 받은 토큰을 위너가 쓸 수 있음.
세션과 토큰을 검증안한 경우.

토큰 발급받아서 넣고 링크해서 함.

**Referrer을 검증하는 경우
lnvalid referrer header
Referer가 ~~인 경우에만 해. 
Referer를 바꿀순없어도 안보내게 할 수는 있음.

*Referrer
(1) False-Postive
<mete name="referrer" content="no-referrer">

 

TIP) 보고서 쓸때 직관적으로 위험도를 느낄 수 있게 작성
> 관리자 계정 탈취
> 정보 노출 --> 약 5천여명의 학생의 개인정보를 추출했습니다.
> 서비스 거부 공격을 할수있다.
관리자가 글 작성, 브랜드 훼손, 글 전부 삭제 등
관리가 계정을 도용해 수행할 수 있는 모든 행동을 할 수 있다.