CSRF(Cross Site Request Forgery. 사이트 간 요청 위조 공격)
서버 애플리케이션이 요청을 보내는 사용자가 사용자 본인이 맞는지 확인하지 않고 사용자의 브라우저에 저장된 세션이나 쿠키를 신뢰하는 것을 악용한 공격.
CSRF는 2008년에 옥션에서 1080만명의 개인정보가 유출된 공격에 쓰인 기법 중 하나이다.
CSRF에 대해서는 아래 블로그가 정리 잘 되어 있어 참고하기 좋다.
DVWA 실습 #4 - CSRF
DVWA의 세 번째 실습 대상인 CSRF다. 이 입력 폼은 비밀번호를 변경하는 시스템이며 이를 로그인한 사용자가 모르게 사용하여 비밀번호를 원하는 비밀번호로 변경하는 공격을 실습해볼 수 있다. CS
haruhiism.tistory.com
CSRF는 주로 패스워드를 변경하는 데 쓰인다. 해커가 사용자에게 피싱을 해서 악성코드가 포함된 링크를 누르게 하면, 사이트는 패스워드가 바뀌는 동작을 하게 된다.
과정을 자세히 쓰면,
1. 사용자가 사이트에 정상 접속, 로그인
2. 해커가 사용자 피싱에 성공
3. 사용자 의지와는 무관하게 사이트로 패스워드 변경 요청 보냄
4. 사용자 계정으로 해커는 변경된 패스워드로 사이트에 접속할 수 있게 됨.
!! 이 때 사용자가 사이트에 로그인 된 상태여야만 패스워드 변경 요청이 갈 수 있다 !!
사용자가 사이트에서 로그아웃 한 상태이면 피싱에 성공해도 패스워드가 변경되지 않는다.
실습
※ "화이트 해커를 위한 웹 해킹의 기술" 강의 및 책에 수록된 실습이다.
※ 허가 받지 않은 웹사이트에 해킹을 시도 하는 것은 불법.
※ dvwa 등 테스트 가능하게 만들어진 곳에서만 모의해킹을 해야한다.
low 단계
burp suite로 http 프록시 서버를 연 뒤, localhost/dvwa에 접속해서 security를 low로 설정했다.
그 다음 CSRF 탭으로 가서 패스워드를 hello로 바꿨다.
패스워드가 변경될 때 어떤 요청이 가는지 HTTPhistory에서 확인할 수 있다
피싱을 당해 어떤 링크를 눌렀을 때 이 요청이 보내진다면(로그인 되어있다는 전제 하에) 패스워드가 바뀌는 것이다.
로그인 여부가 중요한 이유는, 로그인 된 상태여야만 세션쿠키를 요청에 자동으로 포함할 수 있기 때문이다.
이제 나한테 피싱메일을 보내야 하는데, 나는 아직 burpsuite에 https 인증서를 안 받아놔서 메일창 로그인이 안 돼 간단하게 실습했다.
다음과 같은 js코드를 이용했다. 패스워드를 hacker로 바꾸는 요청을 보내는 코드이다.
아직 ajax는 잘 모르는데... ajax를 사용하면 사용자를 완전히 속이는 게 가능하다고 한다. js공부 더 해야지
위의 코드파일을 /opt/lampp/htdocs로 이동시킨 뒤,
창을 하나 더 열어 localhost/csrf.html에 접속한다. Click! 링크를 눌러서 위의 코드가 실행되게 한다.
실제 해킹에서는 링크없이 페이지에 접속하는 순간 공격이 실행될 수도 있다.
이제 다시 dvwa로 돌아가서 로그아웃 후 패스워드를 hello로 입력하면 로그인 되지 않는다.
hacker로 로그인되면, 공격이 잘 실행된 것이다.
HTTP히스토리를 확인해보면 패스워드를 hacker로 바꾸는 요청이 간 것을 확인할 수 있다.
이걸 앞의 패스워드를 hello로 바꾸는 요청과 비교하기 위해, 두 히스토리를 클릭해서 comparer로 보낸다.
comparer탭에 들어가면 선택한 요청 두 개가 각각 다른 창에 떠있다.
화면 오른쪽 하단에 Words를 누르면 두 요청을 비교할 수 있다.
midium 단계
dvwa 난이도를 midium으로 설정한 뒤 csrf 탭에 가서 패스워드를 subway로 바꿨다.
코드 소스를 보면 Referer헤더를 검사하고 있는 걸 알 수 있다.
Referer주소가 실제 서버 주소와 동일한 지 검사해서 사용자가 정상적인 경로를 통해 요청했는지 확인하는 것이다.
Referer 헤더
: 어떤 요청이 전송될 때, 클라이언트가 어떤 웹페이지에서 현재 요청을 보냈는지를 알려주기 위해 웹브라우저가 자동으로 설정하는 헤더.
보통 웹 페이지에서 링크를 클릭하거나 폼 데이터를 제출할 때 사용된다. 예를 들어, 사용자가 A 웹 사이트의 페이지에서 B 웹 사이트로 이동하는 경우, B 웹 사이트는 Referer 헤더를 사용하여 사용자가 이전 페이지가 A 웹 사이트임을 알 수 있다.
Referer 헤더는 보안 문제를 일으킬 수 있기 때문에, 일부 브라우저에서는 이 헤더를 보내지 않도록 설정할 수 있다. 또한, HTTPS에서 HTTP로 이동하는 경우 브라우저는 Referer 헤더를 보내지 않는다.
Referer 헤더는 주로 분석 목적으로 사용된다. 웹 사이트 소유자들은 이 헤더를 사용하여 트래픽 원본을 파악하고 사용자의 행동 패턴을 분석할 수 있다.
(by chatGPT)
만약 CSRF 공격이 해커 사이트가 아니라 웹서버 자체에서 실행된다면?
Referer 헤더에 서버주소가 설정되기 때문에 CSRF 공격이 통한다.
거기다 위의 소스코드를 잘 살펴보면 Referer 헤더를 검사할 때, eregi()라는 함수를 쓰고 있다.
이 함수는 간단히 말하면 정규 표현식에 일치하는 문자열이 대상 문자열에 존재하는지 여부를 확인한다.
(참고로 eregi()함수는 PHP 5.3.0 버전부터 사용이 중단되었다고.. 대신해서 preg_match() 함수를 쓴다고 한다.
eregi()함수는 대소문자를 구분 안 하지만 preg_match()는 대소문자 구분 여부도 선택할 수 있다.)
즉, 요청할 때 서버주소가 Referer 헤더 내에 포함되기만 하면 공격이 실행될 수 있다.
패스워드를 subway로 바꿨을 때 Referer를 살펴보니, localhost라는 서버주소이다(당연하지!)
그러면 공격 링크가 포함된 파일을 열 때 아까 low단계에서와 마찬가지로 localhost에서 열면 된다.
링크를 누른 뒤 요청 부분을 보면 서버주소 localhost로 똑같.
dvwa 로그아웃 했다가 로그인 할 때 hacker로 로그인 된다.
링크파일을 다른 서버에서 열면 공격이 실패할 것이다.
localhost 와 127.0.0.1는 둘 다 내 서버 주소를 가리키지만
midium 단계의 소스코드는 "단순히 문자열이 포함되는지만 확인하는" Referer 검사를 하고 있으므로
127.0.0.1로 열면 패스워드가 hacker로 바뀌지 않을 것이다.
다시 패스워드를 subway로 바꾼 후, 127.0.0.1로 열어서 링크를 눌렀다.
패스워드를 hacker로 했을 때 로그인 되지 않는다. subway 그대로이다.
다음 게시글에서 high 단계랑 impossible 단계까지 기록해야겠다.
'Web hacking > 기법' 카테고리의 다른 글
| SQL injection_(1) 공격 개요 (0) | 2023.04.18 |
|---|---|
| 파일 인클루전 (0) | 2023.04.03 |
| CSRF(2) (0) | 2023.03.23 |
| 커맨드 인젝션(command injection) (1) | 2023.02.23 |
| 브루트 포스(Brute Force) (0) | 2023.02.17 |