CSS SSS
CSS : 클라이언트에서 실행되는 스크립트
SSS : 서버에서 실행되는 스크립트

Server안에 C드라이브 안에 webhack으로 들어와서 새로운 파일을 하나 만들어줌
script_test.asp를 생성해주고 이렇게 작성을 해준다.

그렇게 하고 Client에서 192.168.1.20/script_test.asp를 치게 되면 이런 경고문이 나옴

뒤에 물음표를 붙이고 띄우고싶은 말을 적어주고 치게되면 경고문이 같이 나오면서 웹페이지도 뜨게됨


원문은 위에있는 사진인데 그 사진에 있는 표시된 부분을 서버가 해석해서 hack이라고 출력했기 때문에
저 표시된 부분이 SSS라고 하는것이고 나머지 부분이 그대로 출력되어서 CSS라고 하는 것
URL 읽는 방법

https라는 걸 쓰고 news.naver.com이라는 도메인을 사용한다.
main이라는 디렉터리 안에 main.naver이라는 페이지를 요청하고
?이전까지가 경로이다.(요청한 실제 페이지) ?이후부터는 요청한 파라미터이다.
mode=LSD, mid=shm, sid1=104으로 3개의 파라미터요청을 %로 구분했다.
구글에 쏘니를 검색하면 주소창이 엄청 길게 나오는데 그 뒤에 알아볼 수 없게 되어있는 것이 encoding이다.
encoding : 데이터를 안전하게 전달할 목적으로 데이터를 변환해서 전달하는 것
encoding은 encryption은 아니다.
암호화는 제 3자가 해석하지 못하게 하려는 목적으로 사용함.
아스키코드도 encoding의 종류중 하나이다.

만약 URL에서 표현할 수 없는게 검색이 된다면 ?
예시로 time & effort = skill이라고 검색을 해보니
&는 %26으로 표현했고 =은 %3D로 표현이 되었다. 이것들은 아스키 코드로부터 파생 되었다. 공백은 +로 표현
파일이 깨지는 문제는 인코딩문제일 가능성이 높음 + 솔루션은 저장하고 불러오는 코드를 일치시킨다.
네이버에서 <>로 검색하게 되면
html안에서 인코딩이 되었음으로 html인코딩이라고 한다.


html인코딩을 시험하기위해서 가상머신으로 와서 html_encoding.html로 보면
<>으로 한거랑 <와 >이렇게 바꿔주어도 똑같이 바뀐다.


이런식으로 다시 바꿔주면 공격자가 임의로 넣어둔 악의적인 공격이라고 한다.
이렇게 하게 되면 경고문이 뜨게된다.


이걸 효과적으로 처리 하는 방법은 서버로 다시 와서
<는 <로 바꿔주고 >는 >로 바꿔주면 스크립트로 받지 못한다.
다방면으로 사용하는 encoding방법이 있는데 base64 encoding이다.
base64 encoding에서 자주 쓰이는곳이 MIME이다.
Web이라는 단어를 base64 인코딩 하고싶다면
아스키코드로 먼저 변환함 W = 87 e = 101 b = 98
이진수로 변환해주면
87 = 01010111
101 = 01100101
98 = 01100010
앞에서부터 6자리로 수를 표현해준다.
010101 110110 010101 100010
6자리 수로 안맞아 떨어질 때도 있는데 base64에서 padding으로 처리해준다.
padding은 3자리 단위로 맞추기 위해서 추가해준다.
앞에서부터 6자리로 수를 표현한걸 10진수로 표현하면 21 54 21 34로 할 수 있다.
이걸 base64표를 확인해서 바꾸면 V 2 V i이다.
Web = V2Vi이다.
예시로 Hack이라는걸 Base64로 변환하면
H a c k이라는 단어를 ascii코드의 10진수로 변환한다.
72 97 99 107
이걸 2진수로 변환하면
0100 1000 0110 0001 0110 0011 0110 1011
이걸 다시 6자리로 나눠준다.
010010 000110 000101 100011 011010 11====
나눈 6자리 2진수를 10진수로 변환 뒤에 남은11에는 0000을 붙여서 해준다.
18 6 5 35 26 48
이 수를 base64표를 확인해서 대입해본다.
SGFjaw==이 나온다 뒤에 빈 두자리는 padding으로 처리하면
Hack = SGFjaw== 로 나옴
이 기능은 paros에 Tools에 쉽게하는 도구가 있다.
Base64와 아스키코드표 인터넷에 찾아봄
인증
웹상에서 인증할 때는 크게
Basic Authentication 베이직 인증
Anonymous Authentication 익명인증 어디들어가는데 인증을 안한다면 이것이다.
Form Based Authentication이 웹페이지에서 제일 많이 사용하는 인증
[ 실습 ]
- 기본 인증시 Response의 응답코드가 무엇인가 ?
- 전달되는 ID와 PW의 Encoding 방식을 확인하세요


여기에서 익명엑세스 체크를 풀어주고 기본인증으로 체크를 해주고 확인함
그럼 응답코드가 401(권한 인증 필요 코드)를 반환하고
ID/PW값은 base64 encoding방식으로 encoding되었음을 확인할 수 있다.

깨끗한 상태를 만들기 위해서 인터넷에서 옵션들어가서 LAN설정에서 체크를 풀어주고
cmd에서 arp -d로 캐시 삭제도 해준다.
http는 tcp기반이다 그럼에도 stateless 성격을 지닌다. stateorient성격을 지닐 필요도 있다 > Cookie 도입 배경

깨끗하게 해놓음
세션토큰값을 생성해서 클라이언트에게 준 클라이언트는 그걸 받아서 캐시에 저장함
서버는 자기가 발행해준 쿠키값인지 확인하고 확인이 된다면 서버 응답을 해준다.
쉽게 비유를 하자면 놀이공원에서 자유이용권을 쿠키라고 하면 될듯
만약 공격자가 사용자의 쿠키값을 가져다가 접속을 시도하게 된다면 ?
정상사용자의 값으로 하게된다.


webhack사이트에 내 아이디로 접속한다.
공격자 컴퓨터에서 wireshark패킷 켜서 response의 http의 패킷을 확인하고 거기서
사용자의 쿠키값을 복사한다.


공격자 컴퓨터에서 IP를 검색해서 접속해 Paros에서 잡는다. 그리고 아까 복사한 캐시값을 복사해서
넣어주면 사용자의 아이디로 접속이 가능하다.
[ 실습 1 ] 탈취한 Session(Cookie) 값을 수동으로 변경하지 않고 자동으로 변경될 수 있게 하세요.
- paros를 이용한 filter기능을 사용하면 해결 가능함
filter request head에 로그인을 할수있었던 패킷의 쿠키값을 복사해오고 아래에 복사해서
붙여 넣어줌 위에는 Cookie:* 라고 와일드카드를 작성해서 매 시도에서 바뀌는 쿠키를 모두 포함한다는 소리
그렇게 해주면 가능해짐
[ 실습 2 ] Switch 환경에서 Session Hijacking을 시도하세요.
- 스위치 환경이라 패킷을 포워드하고 필터링 하니까 와이어샤크에 안찍히는데 ARP스푸핑이 필요함
# arpspoof -i eth1 -t 192.168.1.10 192.168.1.20
이렇게 하면 스푸핑이 시작되는데
# fragrouter -B1
이렇게 하면 리다이렉션이 되어서 다시 돌아가니까 공격자 입장에서 와이어샤크가 쿠키가 찍히는 것
쿠키가 찍히니까 paros에서 가져온 쿠키로 Session Hijacking이 가능해진다.
'학원' 카테고리의 다른 글
2023/07/20 크로스 사이트 스크립팅 (0) | 2023.07.20 |
---|---|
2023/07/19 디렉터리 리스닝 (0) | 2023.07.19 |
2023/07/17 Web (0) | 2023.07.17 |
2023/07/14 SNMP (0) | 2023.07.14 |
2023/07/13 SSH, 암호화 (0) | 2023.07.13 |