kjh00n의 기록저장소

WEB Session Attack 본문

어플리케이션 보안 운영

WEB Session Attack

kjh00n 2025. 1. 6. 11:48

WEB Session Attack

● WEB Session의 관리가 안전하게 이뤄지지 않을 때 공격자가 사용자의 Session을 획득하여 사용자의 권한을 도용함

 

취약한 Session 관리

사용자의 인증 정보가 저장될 때 Hash 또는 암호화되어 보호되지 않음

인증 정보가 취약한 계정관리 기능을 통해 추측되거나 덮어쓰기가 가능함

세션 ID가 URL에 노출, 적절한 시간에 타임아웃 되지 않음, 로그인 후 교체되지 않음

암호화 되지 않은 연결을 통해 세션 ID 및 증명 정보가 전송됨

 

공격 종류

● Brute Forcing Session Token, WEB Session Fixation, WEB Session Hijacking

 

Brute Forcing Session Token

● Session Token (= Session ID)을 생성하는 알고리즘이 간단하여 쉽게 유추할 수 있는 경우 Session ID를 추측하거나 Brute Forcing하여 획득한다

● 공격자가 취득한 Session의 권한을 도용함

● 해당 Session 사용자의 중요 정보가 노출될 위험성이 있음

 

대응책

● 평문 형태의 Session Token 사용 금지

  • 식별 가능한 구조가 되지 않도록 함

● 일련 번호 등 추측이 가능한 값 사용 금지

  • Random 값이 사용되어야 함

● 검증된 암호화를 이용하여 인코딩된 값을 사용함 → 자체 개발한 암호화 사용 자제

 

WEB Session Hijacking

● 클라이언트(피해자)가 정상적으로 할당 받은 Session ID를 획득하여 클라이언트의 권한을 도용하는 공격

● 클라이언트가 로그인 요청을 수행해서 발급받은 Session Cookie를 획득함 → wireshark를 통해서

● 공격자는 Proxy에 획득한 Session Cookie값을 설정하여 피해자가 접속한 서버에 접속

● 서버는 로그인된 정상 클라이언트라고 인식하고 클라이언트의 정보를 응답함

● Sniffing

  • 공격자가 피해 대상과 동일한 네트워크에 존재할 때 Sniffing을 통해 로그인에 사용되는 Cookie를 획득함

● XSS

  • 공격자가 피해 대상과 원격 네트워크에 존재할 때 XSS등의 추가 WEB Hacking 공격을 통해 Cookie를 획득함

 

대응책

● Sniffing 공격 차단

● 강력한 보안이 필요한 경우 페이지 별 Session Cookie를 할당함

  • 개인정보 변경 페이지 → 패스워드 재인증

회원정보를 수정하려면 info_check.php로 이동시키게 설정
info_check.php 설정
info_check_ok.php 설정
URL에 직접 info_change.php를 입력하면 이동이 가능해져버리는 취약점이 발생
login_check.php
info.php 설정
URL에 강제로 접속하려하면 인증해달라는 문구가 발생
그러면서 인증페이지로 자동으로 연결시키는 모습

$_SESSION["info_check"]=0; 를
board_list.php, index.php, nick.php에 추가해줬음

 

● Session Cookie의 만료 시간을 적절히 설정함

● 로그아웃을 수행한 경우 Session을 파기함

● Session Cookie와 클라이언트의 주소를 함께 확인함

※이전에 설정한 코드들은 전부 주석처리해놓고 실습 진행함

login_check.php 설정
info.php 설정
kali에서 접속하였을 때 (세션에는 Window의 IP가 저장되어있기 때문)

● Session ID가 한번 탈취되면 그 뒤로 계속 공격받기에 Session ID도 재생성되게 변경하는 설정

login_check.php

session_regenerate_id();를 info.php, logout.php, login_check.php에 입력함으로써 Session Hijacking을 방지하도록 설정

WEB Session Fixation

● 클라이언트(피해자)가 로그인하기 전에 클라이언트의 Session ID를 공격자가 원하는 값으로 고정함

● 로그인 후 클라이언트가 할당받은 Session ID를 공격자가 이미 가지고 있으므로 공격자는 클라이언트와 동일한 권한으로 서버에게 요청할 수 있음

 

대응책

● 익명 인증을 통한 사용자를 인증할 때 새로운 Session ID(Cookie)를 발급함

● 서버에서 임의의 Session ID를 받아들이지 않도록 함

● 로그인 전과 로그인 후의 Session ID를 다르게 사용함

 


WEB Session Hijacking 간단 실습

Window(클라이언트)에서 50.50접속할 때 Session ID 탈취
firefox의 settings에 들어가서 network 검색
Proxy 설정
burpsuite 프로그램 사용
Proxy settings에 들어가기
proxy settings → Match and replace rules → Add → 사진처럼 세팅
추가한 정책이 적용되어있음
Window에서 root계정으로 접속했을 때 탈취한 Session ID를 사용하여 자동 로그인 되었다.

Window에서 로그아웃하면 Hacker 쪽에서도 로그아웃되고 Window에서 다른 계정으로 로그인하면

Hacker도 그 계정으로 로그인 된다.

'어플리케이션 보안 운영' 카테고리의 다른 글

XSS 보안 및 우회  (0) 2025.01.07
XSS  (0) 2025.01.06
WEB 인증 공격  (0) 2025.01.03
데이터 검증  (0) 2025.01.03
Information Gathering (정보 수집)  (0) 2025.01.02