[week_8] CSRF - 2 (feat. 문제풀이)

정신이 하나도 없다... 일본여행 다녀오고 바로 수업이라니..

0. 들어가기

[커리큘럼]

SCRF 문제 풀이 및 대응 방안

 

수업시작 후 동기부여 및 불안한 마음에 대해 용기를 주셨다.

[버려야하는 마인드]

- 아 몰라!!!!!!라는 마인드를 버려야한다.

==>진짜 게시판 개발하면서 느낀점이 그렇다. 여러 블로그를 보면서 작성하는데 밤잠을 설치면서 한거같다.

- 모든 일에 대해 왜???이렇게 될까? 라는 호기심, 궁금증으로 접근을 하다보면 풀리게 된다.

그리고 해킹대회에 대한 이야기를 했다.

해킹대회를 도전해보는 것도 경험상으로 좋다는 이야기를 했다.

입상을 하라는 이야기가 아닌 문제를 풀어보고 노력해보고 최근 해킹 동양도 파악하는데 도움이되고

결국은 많은 문재를 풀어보라는 뜻이였다.

자만하지말고 겸손해져라! 단! 기죽지말자~!

해킹 컨퍼런스(?)에 대한 이야기도 있었다. 코드게이트라는 컨퍼런스이다. 1년에 한번 진행된다고 한다.

 

1. 수업 CSRF 2회차

[+] 분류

- 서버측 공격 : SQLi

- 클라이언트 측 공격 : 크사(XSS),CSRF 

(생각 : 어느 공격이 어디측 공격인지 정리가 필요함)

크사 :  공격자(해커)가 짜놓은 임의의 스크립트가 클라이언트 측에서 실행되도록 만드는 공격!

CSRF : 클라이언트 측에서 자기(사용자)가 의도치 않게 서버에 특정 행위를 요청하는 공격 (비밀번호와 같은 인증 정보?)

 

 

그리고 발견한 XSS취약점을 설명해주셨다.(이런거보면 실무에서 배우는 느낌이다. 차근차근알려주시는 거 보면!!!!)

<script>
if('$_GET['id']' != '' && '$_GET['id']' = '')
</script>

위 코드는 <'">와 같은 특수문자를 전부 막아놓으면? 해당 특수문자를 사용못한다고???

또 그런건 아닌듯 하다 우회는 잘 찾아보면~크사를 사용 못하는건 아니라는 이야기?

 

[+]CSRF 공방 [시점표기]

[보안] 문제가 발생하면 문제에 대한 원인 파악하기

CSRF가 발생한 근본적인 원인이 뭘까??????????

==> 임의의 태그를 만들 수 있기 때문에 CSRF가 발생한다.

 

[해킹] iframe은 웹 안에 웹을 하나 더 만드는것? 또, 높이와 너비(폭) 값을 0으로 하면 도출 되지 않는다는 뜻!

==> CSRF 공격시 화면에 노출되지 않게 작성하기 위한 방법이라고 할 수 있다.(화면에 표시되면 알아차리기 쉽다.)

 

[보안] Referer Header 검증!

개인정보 업데이트 이벤트가 마이페이지에서 발생해야하는데, 게시판과 같은 다른 곳에서 발생한다면 

==> 높은 확률로 CSRF공격이다.

 

Referer Header(레퍼러 헤더)를 제대로 검증을 했다면 우회가 불가능하다

즉, Referer Header를 제대로 구현해라!

 

Referer이 게시판에서 발생했기 때문에 Invalid가 발생했다

==> Referer값을 마이페이지로 바뀌면 어떻게 될까?

==> 클라이언트 측에서 레퍼러 값을 바꾸는 것을 불가능......

 

Referer Header를 지운다면 또, 통과가 된다......(창과 방패 이야기 같다.)

WHY?? 레퍼러 헤더 검증같은 경우에 개발 단계에서 구현되는 경우가 없고, 개발이후 검증,유지보수 단계에서 문제 지적으로 인해 코드가 추가되는데 개발시 코드 작성된 코드와 호환성 문제로 적용되는 곳과 안되는 곳이 존재 (개발자에게는 악몽같은 일)

만약, Referer Header가 있으면 검사해보자!

 

e2e 암호화를 우회하는데 위의 방식이 많이 사용이 된다. 암호화되어 있지 않으면 그대로 처리되도록 개발된 경우가 많기 때문!

(e2e....End to End Encryption 종단간 암호화 맞나? 해당 부분도 주가로 공부해야겠다. 나머지 공부가 상당하다 ㅎㅎ.....)

 

 

[보안] CSRF 토큰

개발자들도 CSRF 공격을 막기 위해 임의의 인증값을 만들어 세션에 저장하고 그 값을 체크해서 CSRF에 대한 방안을 세웠다??

예를들어 마이페이지에서 비밀번호 변경을 요청 => session에 토큰을 저장=> 마이페이지에 요청을 받으면 CSRF 토큰을 넣음.

그 다음에 이 사람이 비밀번호 변경 요청을 할 때 랜덤한 값을 같이 넣는다. 서버에서 토큰 값을 체크한 다음 결과값이 같으면 통과! 아니면~ 나가리 된다.

[해킹] 다만, XSS가 발생한다면 해당 토큰(랜덤값)을 가져오는 것은 쉽다.. 어떻게?

마이페이지에 들어가서 토큰을 저장하고 그 토큰값을 바꿔서 다시 보내면 됨.(창과 방패...)

 

[+] 대응방안

1. Referer 제대로 검증!!!!

2. 개인정보 변경시 기존 정보(인증)를 활용 (즉, 공격자가 모르는 기존 비밀번호 와 같은?)

   ==> 근본적인 대응 방안~~~