작업 환경

• VMware Workstation Pro (17.6.2 ver)
• Server 
  • Web 서버 : Rocky_Linux(8.10 ver, VMnet 2, PHP로 구성)
  • DNS 서버 : Rocky_Linux(8.10 ver, VMnet 1)
• Client
  • Kali Linux : Web 취약점 점검용 (VMnet 1)
• GNS 구성

• 해당 점검은 비밀번호 수정 페이지에 한해서 진행됨

점검 방법

• Step 1) 인증 후 정상적으로 세션이 발행된 페이지의 리퀘스트를 취득하여 일정 시간 (사이트에 따라 다름)이 지난 후에 재전송 시 정상 처리가 되는지 확인

현재 세션 발급에 대한 설정만 존재, 세션 종료 시간 설정은 참고 확인

보안 설정 방법

• 세션 타임아웃 구현 시 타임아웃 시간은 10분으로 설정할 것을 권고함

참고

세션 종료 시간 설정

1. 일정 시간 "미사용"시 자동 만료

→ 권고 사항인 10분으로 설정

• 설정 방법 
  • 해당 페이지만 설정 : session.gc_maxlifetime 값을 600초로 설정
  • 전역 설정 : php.ini 에서 session.gc_maxlifetime 값을 600초로 설정

/var/www/html/update.php <- 비밀번호 수정 페이지만 설정하고싶은 경우

<?php
ini_set('session.gc_maxlifetime', 600); // 서버 세션 수거 주기도 10분으로

session_start();

// 타임아웃 기준 시간
$timeout = 600;

// 마지막 활동 시간 확인
if (isset($_SESSION['last_activity']) && (time() - $_SESSION['last_activity']) > $timeout) {
    session_unset();
    session_destroy();
    header("Location: /proc/logout.php?reason=timeout");
    exit;
}

// 활동 시점 갱신
$_SESSION['last_activity'] = time();

...중략

/etc/php.ini 에서 전역설정 추가
session.gc_maxlifetime = 600

🔐 OWASP TOP 10(2021)과의 연관

OWASP 공식문서 중 일부
“Sessions should be invalidated on the server after logout, idle timeout, and absolute timeout.”

1. A07:  Identification and Authentication Failures

• 외부 입력이 코드나 명령으로 해석되어 실행
• PHP 자체는 이런 구조가 아니지만, PHP로 연동된 네이티브 애플리케이션이 존재할 경우 발생 가능

작업 환경

• VMware Workstation Pro (17.6.2 ver)
• Server 
  • Web 서버 : Rocky_Linux(8.10 ver, VMnet 2, PHP로 구성)
  • DNS 서버 : Rocky_Linux(8.10 ver, VMnet 1)
• Client
  • Kali Linux : Web 취약점 점검용 (VMnet 1)
• GNS 구성

• 해당 점검은 비밀번호 수정 페이지에 한해서 진행됨

점검 방법

• Step 1) 비밀 게시글(또는 개인정보 변경, 패스워드 변경 등) 페이지에서 다른 사용자와의 구분을 ID, 일련번호 등의 단순한 값을 사용하는지 조사

• Step 2) 게시글을 구분하는 파라미터 값을 변경하는 것만으로 다른 사용자의 비밀 게시글 (또는 개인정보 변경, 패스워드 변경 등)에 접근 가능한지 확인

BurpSuite 를 사용하여도 해당 유저의 값만 바꿀 수 있음

다른 사용자의 패스워드에는 접근 불가능

보안 설정 방법

• 접근제어가 필요한 중요 페이지는 세션을 통한 인증 등 통제수단을 구현하여 인가된 사용자 여부를 검증 후 해당 페이지에 접근할 수 있도록 함
• 페이지별 권한 매트릭스를 작성하여 접근제어가 필요한 모든 페이지에서 권한 체크가 이뤄지도록 구현하여야 함

참고

🔐 OWASP TOP 10(2021)과의 연관

OSASP TOP 10 공식 문서중 일부
"Access control enforces policy such that users cannot act outside of their intended permissions. Failures typically lead to unauthorized information disclosure, modification or destruction of all data or performing a business function outside of the user's limits."

1. A01:  Broken Access Control

• URL 또는 요청 파라미터를 조작하여 다른 사용자의 데이터에 접근하는 경우
• 로그인하지 않은 상태에서 인증이 필요한 페이지에 접근하는 경우
• 일반 사용자가 관리자 권한이 필요한 기능을 수행할 수 있는 경우

작업 환경

• VMware Workstation Pro (17.6.2 ver)
• Server 
  • Web 서버 : Rocky_Linux(8.10 ver, VMnet 2, PHP로 구성)
  • DNS 서버 : Rocky_Linux(8.10 ver, VMnet 1)
• Client
  • Kali Linux : Web 취약점 점검용 (VMnet 1)
• GNS 구성

• 해당 점검은 비밀번호 수정 페이지에 한해서 진행됨

PHP의 경우에는 session start(); 를 사용하면 임의의 세션 ID를 발급해준다.

추가적인 설정과 세션에 대해서는 참고 확인

점검 방법

• Step 1) 각기 다른 IP 주소와 다른 사용자명, 시간적 차이로 세션 ID를 발급받음
• Step 2) 발급받은 세션 ID에 일정한 패턴이 있는지 조사
• Step 3) 일정한 패턴이 확인되고, 패턴에 의해 사용 가능한 세션 ID의 예측이 가능한지 확인

① jijibaeee 계정으로 로그인한 경우

② test123 계정으로 로그인한 경우

③ (②) 에서 로그아웃을 하고 다시 test123 계정으로 로그인한 경우

보안 설정 방법

• 아무리 길이가 길고 복잡한 항목으로 세션 ID가 만들어져도 공격자가 충분한 시간과 자원이 있다면 뚫는 것은 불가능하지 않으므로 강력한 세션 ID를 생성하여야 함 주된 목적은 수많은 대역폭과 처리 자원을 가지고 있는 공격자가 하나의 유효한 세션 ID를 추측하는데 최대한 오랜 시간이 걸리게 하여 쉽게 추측하지 못하게 하는 것에 있음
• 단순 조합보다는 상용 웹 서버나 웹 애플리케이션 플랫폼에서 제공하는 세션 ID를 사용하고, 가능하다면 맞춤형 세션 관리 체계를 권고함
• 세션 ID는 로그인 시마다 추측할 수 없는 새로운 세션 ID로 발급하여야 함

참고

📌 세션 ID란 ?

웹 애플리케이션에서 사용자의 상태를 유지하기 위해 생성되는 고유한 식별자

• 세션 값에 접근하기 위한 키(Key) 역할을 하는 고유 식별자
• 즉, 브라우저에 저장되는 임의의 고유 식별자
• 난수를 사용하고 위 점검 예시의 Value 에 해당
  • Name 은 세션 이름(Key)

📌 세션값이란 ?

세션에 저장된 실제 데이터

• 사용자 이름, 권한과 같은 데이터
• 브라우저에 안 보임 → 서버에 저장됨
  • $_SESSION['user_id'] 및 $_SESSION['nickname'] 과 같은 사용자의 정보임
• 사용자의 정보이므로 난수가 아님

비유

PHP에서 세션 설정 

• session_start() 호출 시 PHP가 자동으로 세션을 설정
• 기본값으로 설정한 경우 아래의 기본 설정이 들어감 → 충분히 강력하여 무작위 대입 공격 불가
  • session.sid_length : 26
  • session.sid_bits_per_character : 5
  • session.hash_function : sha1 또는 php

① /etc/php.ini 에서 추가로 설정해보기

session.sid_length = 128
session.sid_bits_per_character = 6
session.hash_function = sha512

• sid_length : 세션 ID의 전체 길이
• sid_bits_per_character : 세션 ID를 구성할 때 한 문자당 몇 비트를 사용할지 (6 이상 권장)
• hash_function : 내부적으로 세션 ID를 생성할 때 사용할 해시 알고리즘 (sha512 권장)

② 로그인 시마다 세션 ID 재발급

• 로그인 성공 시 아래의 코드에 발급

/var/www/html/proc/login_proc.php

session_start();
session_regenerate_id(true);

• session_regenerate_id(true) : 세션 ID를 로그인 시마다 재발급 받음으로 세션 하이재킹 방지
• 세션 고정(Session Fixation) 공격 방지

🔐 OWASP TOP 10(2021)과의 연관

OWASP TOP 10 공식문서중 일부
"CWE-384: Session Fixation – The application does not assign a new session ID upon successful login. This allows an attacker to set or predict a user’s session identifier and hijack their session once they log in."

1. A07 :  Identification and Authentication Failures

• 세션 ID가 단순하거나 순차적으로 생성되어 공격자가 쉽게 추측할 수 있는 경우
• 사용자가 로그인하기 전에 세션 ID가 고정되어 있어, 공격자가 해당 세션 ID를 이용하여 사용자의 세션을 탈취할 수 있는 경우

작업 환경

• VMware Workstation Pro (17.6.2 ver)
• Server 
  • Web 서버 : Rocky_Linux(8.10 ver, VMnet 2, PHP로 구성)
  • DNS 서버 : Rocky_Linux(8.10 ver, VMnet 1)
• Client
  • Kali Linux : Web 취약점 점검용 (VMnet 1)
• GNS 구성

• 해당 점검은 게시글 페이지에 한해서 진행됨

점검 방법

• Step 1) XSS 취약점이 존재하는지 확인
  • XSS 취약점 → 이전 발행글 확인

2025.05.13 - [주요정보통신기반시설가이드/Web 취약점 점검] - [XS (상)] 11. 크로스사이트 스크립팅

• Step 2) 등록 및 변경 등의 데이터 수정 기능의 페이지가 있는지 조사함
  • 비밀번호 수정 페이지는 데이터의 수정 가능
• Step 3) 데이터 수정 페이지에서 전송되는 요청(Request) 정보를 분석하여 임의의 명령을 수행하는 스크립트 삽입 후 해당 게시글을 타 사용자가 열람하였을 경우 스크립트가 실행되는지 확인
  • 공격자가 게시글 페이지에 아래의 코드를 포함하여 게시물 작성
  • 해당 버튼을 클릭시 해당 사용자의 비밀번호가 1 로 변경됨

<form method=POST action=proc/update_proc.php>
<input type=hidden name=pw value=1>
<input type=submit value='lotto!!!'>
</form>

해시 함수를 사용하여 비밀번호 암호화를 하여도 비밀번호가 변경되는 것을 확인할 수 있으며
이를 이용하여 공격자가 test123 계정으로 로그인하여 피해를 줄 수 있음

보안 설정 방법

• 웹 사이트에 사용자 입력 값이 저장되는 페이지는 요청이 일회성이 될 수 있도록 설계
• 사용 중인 프레임워크에 기본적으로 제공되는 CSRF 보호 기능 사용
• 사용자가 정상적인 프로세스를 통해 요청하였는지 HTTP 헤더의 Referer 검증 로직 구현
• 정상적인 요청(Request)과 비정상적인 요청(Request)를 구분할 수 있도록 Hidden Form을 사용하여 임의의 암호화된 토큰(세션 ID, Timestamp, nonce 등)을 추가하고 이 토큰을 검증하도록 설계
• HTML이나 자바스크립트에 해당되는 태그 사용을 사전에 제한하고, 서버 단에서 사용자 입력 값에 대한 필터링 구현
• HTML Editor 사용으로 인한 상기사항 조치 불가 시, 서버 사이드/서블릿/DAO(Data Access Object) 영역에서 조치하도록 설계
• XSS 조치 방안 참조

참고

📌 CSRF 란 ?

CSRF는 공격자가 사용자의 브라우저를 이용해 인증된 상태로
원하지 않는 요청을 서버에 보내도록 유도하는 공격

• 피해자가 로그인된 상태를 노려 의도하지 않은 요청을 서버가 수행하게 만드는 공격
• 요청 예시 : 비밀번호 변경, 글 삭제, 계좌 이체 등

XSS vs CSRF 차이점

CSRF 방어 방법

1. CSRF 토큰

• 요청마다 임의 토큰을 부여하고, 서버는 이 값이 맞는지 검증
  • 이 예시에는 update.php 에 CSRF 토큰을 삽입하고, update_proc.php 에서 검증을 한다

① update.php 에 CSRF 토큰 생성

<?php
session_start();

// CSRF 토큰 생성 (세션에 저장)
if (empty($_SESSION['csrf_token'])) {
    $_SESSION['csrf_token'] = bin2hex(random_bytes(32));
}
$token = $_SESSION['csrf_token'];
?>

...중략

• random_bytes(32) : 매 요청모다 고유하게 생성 가능(유일성)
• 세션 기반 : 토큰은 세션에 저장되어 서버 기준 유효성 검증 가능

②  토큰을 update.php form 안에 <input type="hidden">으로 추가

...중략

<form action="proc/update_proc.php" method="POST">
    <input type="password" name="pw" placeholder="새 비밀번호" required><br>
    <input type="hidden" name="csrf_token" value="<?= htmlspecialchars($token) ?>">
    <input type="submit" value="비밀번호 변경">
</form>

...중략

• hidden input 이라서 사용자 모르게 자동 제출

③ update_proc.php 에서 토큰 검증 로직 추가

<?php
session_start();

// CSRF 토큰 검증
if (!isset($_POST['csrf_token'], $_SESSION['csrf_token']) || $_POST['csrf_token'] !== $_SESSION['csrf_token']) {
    die("CSRF 공격 의심: 요청이 거부되었습니다.");
}

③ - ① 더 자세한 결과를 위해 update_proc.php 추가

if (!isset($_POST['csrf_token'], $_SESSION['csrf_token']) || $_POST['csrf_token'] !== $_SESSION['csrf_token']) {
    echo "POST 토큰: " . htmlspecialchars($_POST['csrf_token'] ?? '없음') . "<br>";
    echo "SESSION 토큰: " . htmlspecialchars($_SESSION['csrf_token'] ?? '없음') . "<br>";
    die("CSRF 공격 의심: 요청이 거부되었습니다.");
}

• 검증 성공 시 정상적으로 비밀번호 변경 로직 실행
• 실패 시 요청 중단

해시 값이 클릭 전, 후로 동일한 것을 확인
비밀번호 변경 요청이 서버에서 거부되었다.

2. SameSite 쿠키

• PHP 7.2 이하 : SameSite 공식으로 미지원
• PHP 7.3 이상 : SameSite 공식 지원

① /var/www/html/include/session_secure.php 파일에 아래 내용 추가

<?php
session_set_cookie_params(
    0,
    '/; samesite=Strict',
    '',
    true,
    true
);
session_start();

•  path + SameSite 속성 우회하여 삽입

② 모든 페이지 상단에서 다음을 추가

require_once("../include/session_secure.php");

• 현재 폴더 구조는 상단으로 한 번 올라가야 /var/www/html 인 구조

🔐 OWASP TOP 10(2021)과의 연관

OWASP TOP 10 공식문서중 일부
"Cross-Site Request Forgery (CSRF) vulnerabilities allow attackers to induce users to perform actions they do not intend to. CSRF attacks exploit the trust that a site has in a user's browser."

1. A01:  Broken Access Control

• 서버가 인증된 사용자의 의도를 검증하지 않고 민감 요청을 수행

2. A07 : Identification & Authentication Failures

• 인증된 요청이라도 별도의 확인 절차 없이 민감 작업 수행 시 포함