정보보안 스터디 - 8주차 1일 - CSRF 대안 방안

 

☞ 개념 정리

SQLi와 XSS,CSRF의 특징, 차이점 

 

sql injection은 서버 측을 공격합니다.

크게 유저가 있어야 공격이 가능한지 여부를 따질 수 있는데

sqli는 유저가 없어도 서버를 공격해서 자체에 저장되어있는 정보를 탈취할 수 있기 때문입니다.

 

xss와 csrf는 클라이언트 측에 하는 공격입니다.

클라이언트의 컴퓨터의 실행이 없으면 할 수 없는 공격이고, 정보변경 등의 행동을 유도합니다.

 

 

 

XSS와 CSRF의 차이점 

 

xss와 csrf가 헷갈릴 수가 있는데 차이점을 명확히 알아야합니다.

xss는 스크립트를 클라이언트의 웹브라우저에서 실행시키도록 하는 공격이며 웹브라우저에서 세션에 대한 응답이 옵니다.

csrf는 클라이언트가 서버에 직접 요청하게 하는 공격입니다. 정상적인 요청처럼 보이며 서버에서 응답이 옵니다. 이메일 변경, 비밀번호 변경, 글쓰기 등 행동을 유도합니다.

 

 

 

 

☞ CSRF 실행 조건

csrf 공격의 실행 조건은 공격자가 입력값을 예측이 가능하여 링크를 만들 수 있다는 점입니다. 

  

get방식의 요청을 허용한다면 url로 쉽게 링크를 만들어 정보변경이 가능합니다.

예를들어 url링크를 만들어 링크를 클릭하도록 전달하거나  

<img src="http://wonder.com/mypage_update.php?email=www@naver.com"> 또는

<img src="http://wonder.com/mypage_update.php?password=1234" >

이미지를 통해 이미지를 읽는다면 그 url로 요청을 보낼 것입니다. 이미지 파일이 아니더라도 url요청이 가고

응답을 받아오기 때문에 아주 쉽게 사용자가 모르도록 요청을 줄 수 있고, 정보변경을 할 수 있습니다.

 

get방식을 막고 post방식을 받는다고 해도 마찬가지입니다.

form을 만들고 자바스크립트를 통해 관리자가 모르게 서버에 정보변경을 요청을 할 수 있습니다. 이것도 역시 post방식이더라도 입력값 예측이 가능합니다.

예를들어 클릭을 하면 submit이 되어 정보변경이 된다거나

버튼없이도 자바스크립트를 작성하여 글이 로드가 되면 자동으로 submit이 되고 iframe에서 사용자 모르게 실행시킬 수 있습니다.

 

참고로 get방식이 막혀서 post방식으로만 받아들인다면 무조건 Stored xss와 연계를 할 수 밖에 없으며, 큰 시너지를 냅니다.

 

 

그렇다고 Xss가 있어야 csrf를 할 수 있는 것은 아닙니다.

get방식의 경우는 xss를 들어갈 필요없이 url로 쉽게 만들어 csrf를 진행하면 끝입니다.

 

이와 비슷하게 개발자들이 xss만 막으면되지 csrf를 왜 확실히 막아야 할까요?

개발자들은 앞으로 새로운 페이지들을 만들 것인데 post방식으로 요청 못하도록 삽입자체를 막는 stored xss, reflected xss 등 xss에는 신경써서 막았지만 csrf를 신경을 못써서 get방식을 받아들인다면 해당 페이지들은 쉽게 정보변경이 될 것입니다.

 

 

 

 

 

 

☞ csrf 대안 방안

그러면 여기서 공방이 시작됩니다. 개발자들은 이걸 어떻게 막아야할까요?

post 방식을 받아들인다면 예측불가능하게 해야합니다.

 

 

1. 기존비밀번호 등 정보를 입력해야 하는 예시가 있습니다.

하지만 모든 변경관련 요청을 할 때마다 기존비밀번호를 입력해야한다면 매우 번거로울 것입니다.

 

 

2. referer헤더 검증. referer을 정확히 따집니다.

referer같은 경우에는 어디에서 요청이 들어왔냐인데, 마이페이지에서 정보변경을 요청했는지, 아니면 이상한 곳에서 정보변경을 하려고 한다면 높은 확률로 csrf공격이기 때문에 차단해야합니다. 그래서 이런 것은 검사해서 차단해버립니다.

하지만 여기에서 취약점이 있습니다. referer이 있다면 검사를 하지만, 없다면 통과를 시켜버리는 경우입니다.

개발자들은 내가 모르는 곳에서 정상적인 요청이 있지않을까? 라고 생각하면서 보수적인 개발을 하는 경향이 있습니다. 만약 요청을 모두 막아서 기능이 작동하지 않는다면 서비스에 큰 손실이 되기 때문입니다.

 

큰 규모의 사이트에서 만약 referer을 모두 막아 버린다면 확실한 차단이 되겠지만 하지만 그렇게 하는 경우는 손실이 더 많다고 판단합니다. 그래서 다른 대안을 많이 사용합니다.

결론적으로 referer이 없다면 패스해버리기 때문에, meta태그를 이용해 no-referer을 설정해주면 우회가 가능합니다.

 

 

3. CSRF token을 요구합니다.

회원가입을 했을 때 랜덤값인 token을 세션과 함께 포함하여 만듭니다. 그리고 정보변경을 하려고 마이페이지에 이동했을 때 그 때만 주어지는 token값을 부여합니다. 정보변경을 할 때 회원가입 token과 마이페이지 token 값이 같은 값? 일 때만 정보변경을 할 수 있도록 허락합니다.

하지만 그럴 경우에 공격자는 그냥 요청을 한번 더 추가하면 됩니다. 사용자의 token을 받을 수 있도록 마이페이지에 이동시켰다가, 정보변경을 하면 됩니다. 그래서 의미가 없어 보이기도 합니다.

 

그래서 결국 referer을 정확히 차단하거나 번거롭더라도 기존 비밀번호를 입력시키는 방법이 최선입니다.

 

 

 

 

+ 궁금한 점 탐구

XSS가 가능하다면, 쉽게 세션을 탈취하면 되는데 왜 Csrf를 해야하는가?

F12를 눌러 document.cookie를 검색 했을 때, 검색이 안되는 경우가 있습니다. 개발자들이 막아놔서 그렇습니다. 그렇게 되면 document.cookie로 세션탈취를 할 수 없습니다. csrf로 눈을 돌릴 수 밖에없습니다. 

Burp suite로 세션확인을 했을 때 다른 사이트는 확인되지만, 막아놓아서 쿠키확인이 불가능한 것을 볼 수 있습니다.    

 

 

 

 

XSS는 많이들 신경쓰지만 Csrf가 사실 좀 더 취약점이 많이 발견되는 것 같긴합니다.