[13 WEEK] CSRF Protection, CSRF + XSS, SOP / CORS
CSRF 대응방안
Referer Check
어떤 페이지로부터의 요청인지를 체크
만약, 마이페이지에서 비밀번호 변경 요청이 뜬금없이 게시글에서 왔다면 부적절한 요청일 가능성이 높으므로 해당 요청은 통과시켜주지 않는 등의 응답으로 방어
해당 방안은 다소 확장성이 부족하여 예외처리가 필요함. 만약 Referrer에 문제가 생겼다면 요청을 어떻게 처리할까?
> 보통의 개발 방식으로는 Referer에 분제가 발생하면 맞는 요청으로 생각하고 통과시켜줌
해당 개발 방식을 사용하여 Referer를 삭제하는 등 일부러 Referrer에 문제를 야기시켜 우회가 가능
//Referer를 삭제하는 코드
<meta name="referer" content="no=referer">
CSRF_Token
중요한 데이터를 다루는 인증 절차가 필요한 곳에서 많이 사용.
해당 Token을 검사하여 일치하는 경우에만 해당 행위를 허가.
예를 들어, 게시판 글 작성 같은 기능에 추가하면 도움이 됨
XSS가 함께 있는 경우에는 우회가 가능
인증정보 추가
요청을 '위조'하는 CSRF를 해결할 수 있는 가장 근본적인 방법. 하지만 가장 불편하기도 함
예를 들어, 마이페이지에서 비밀번호 변경 시에 원래 비밀번호를 물어보는 것은 이상하지 않으나, 게시판 글을 작성할 때에 혹은 읽을 때마다 비밀번호를 물어본다면 큰 불편을 야기
때문에 가장 민감한 정보를 다루는 부분에서 사용
CSRF가 POST Method로 가능할 때 XSS가 필요한 이유
> SOP / CORS 설정 때문
> SOP 때문이라면 같은 도메인 내에서 취약점을 찾아서 접근
> CORS 때문이라면 ACAO에 등록된 도메인 내에서 취약점을 찾아서 접근
SOP/ CORS
SOP
Same-Origin Policy (동일 출처 정체)
같은 출처의 자원끼리만 접근할 수 있도록 허용
같은 출처의 기준
1) 도메인
2) 스키마
3) 포트
CORS
SOP의 유연성 부족으로 인해 생김
Cross Origin Resource Sharing
SOP를 기본적으로 적용하되, 몇 가지 규칙으로 다른 출처의 자원끼리도 접근을 허용하여 유연성을 높임
ACAO
Access Conrol Resource Origin
자원 접근을 허용하고자 하는 사이트들의 모음집
기본적으로 Whitelist 방식으로 사용
Response에 포함됨
💥개발자 : "넣을 사이트가 너무 많아! * 로 대체해야겠어! 그냥 모든 데이터를 허용할래!"
ACAO에 *를 넣기 시작하여 SOP의 의도가 무용지물
💥CORS : "아니 그게 무슨 말이야! * 라니! 그래, 개발 해놓은게 많다고? 허가할게 대신!"
"타 도메인에서 쿠키를 포함해서 온 요청에는 * 못 써!"
> 마이페이지 등 중요한 정보가 쿠키에 담겨 오는 페이지의 응답에는 *를 사용하지 못하게 됨
ACAC
Access Control Allow Credentials
쿠키를 포함한 요청인지 아닌지 알려줌
true일 때 ACAO에 *를 사용하지 못하게 됨
💥개발자 : "흥.. 그럼 * 를 쓰지 않고 *처럼 동작하면 되지!"
Request의 Origin에 있는 값을 그대로 ACAO에 붙여버림
SOP의 의도가 무용지물