[SK shieldus Rookies 29기] 26일차

3.5 불필요 파일 존재 취약점

순번	분류	코드	점검 항목
9	불필요 파일 존재	AF-020	불필요한 페이지 존재 여부
		AF-021	백업/압축 등 불필요 파일 존재 여부
		AF-022	테스트/데모 페이지 삭제 여부

표 3-4: 불필요 파일 존재 점검 항목

3.5.1 모의해킹 수행

웹 서버가 제공하는 서비스의 운영 상에 불필요한 페이지가 존재하는지 확인하는 작업이며 불필요한 페이지의 정보로 인해 공격으로 활용될 가능성이 있다.

그림 3-14: gobuster 도구를 이용한 확장자 검색

그림 3-15: gobuster 도구를 이용한 확장자 정렬

gobuster 도구의 -x 옵션을 이용하여 특정 확장자를 검색한다.
이때 -u는 대상 url, -w는 사전단어 경로를 의미한다.

그림 3-16: 불필요한 페이지 존재

gobuster 도구를 이용한 확장자 검색 결과를 바탕으로 페이지 접근가능 여부를 체크한 결과, 접근가능한 것을 확인하였다. 해당 취약점을 바탕으로 공격 표면 확장, 시스템 정보 유출 등이 가능한 것을 검증하였다.

• 공격 표면 확장: /admin, /upload 등 관리자 및 기능 디렉터리 경로가 노출되어 무차별 대입 공격(Brute Force)이나 웹 셸 업로드 공격의 타겟이 된다.
• 시스템 정보 유출: phpinfo.php를 통해 획득한 PHP 버전 정보를 바탕으로 해당 버전에 존재하는 알려진 취약점(CVE) 공격을 시도할 수 있다.

웹 서버 내에 백업, 압축 등의 파일이 존재할 경우 공격자가 웹 취약점을 이용하여 해당 파일이 노출될 경우 해당 파일과 연관된 서비스가 취약하다고 사료된다.

그림 3-17: 웹 서버 내 백업 파일 존재 확인

사전에 탈취한 웹 서버를 통해 직접 접속한 하였을 때, gm.zip을 통해 소스코드와 DB 접속 정보가 유출되어, 데이터베이스 직접 접근 및 데이터 유출/변조가 가능하다.

개발자나 유지보수자가 웹 서버내에 테스트/확인 용도로 만들어논 페이지가 존재할 경우 이는 공격자에게 공격을 위한 정보를 제공해주는 실마리가 된다.

그림 3-18: 웹 루트 내 불필요한 디자인 샘플 및 .txt 파일

서버 내부 파일 목록 점검 및 수동 접근을 통해, 서비스 운영과는 무관한 개발 단계의 테스트 파일들이 웹 루트(/gm/)에 방치되어 있음을 확인하였다.

그림 3-19: http://192.168.206.128/gm/ColorChart.html 접근

해당 URL로 직접 접근을 시도한 결과, 별도의 인증 절차 없이 파일 내용이 그대로 노출되었다. 이러한 파일들은 개발자가 서버에 남겨둔 '흔적'으로, 서버 관리가 철저하게 이루어지지 않고 있음을 보여주는 방증이 된다.

3.5.2 취약점 대응 방안

1. 불필요한 파일 및 디렉터리 즉시 삭제 (물리적 조치)

운영 서버에서는 서비스 구동에 필수적인 파일만 유지하는 것이 원칙이다.
이번 점검을 통해 식별된 불필요 파일들은 즉시 서버에서 제거해야 한다.

• 삭제 대상 파일
  • /gm/ColorChart.html (디자인 샘플)
  • /gm/c_table.html (테이블 예제)
  • /gm/??ġ?????.txt (설치 매뉴얼 또는 Readme 파일)
  • 기타 /gm/ 디렉터리 내 사용하지 않는 .html, .txt 파일 일체
• 주의 사항
  • 삭제 전 반드시 백업을 수행하거나, 테스트 환경에서 서비스 영향도를 사전에 검증해야 한다.

2. 웹 서버 설정을 통한 접근 통제 (기술적 조치)

불필요한 파일은 삭제가 원칙이나, 부득이하게 서버에 남겨야 하거나 실수로 업로드되는 것을 방지하기 위해 웹 서버 설정을 통해 접근을 원천 차단해야 한다.

i. Apache 설정 (httpd.conf 또는 .htaccess)

• 특정 확장자 접근 차단

  <FilesMatch "\.(txt|bak|old|log|sql|zip)$">
    Order allow,deny
    Deny from all
  </FilesMatch>

• 기본 제공 매뉴얼 및 아이콘 디렉터리 차단

  <Directory "/var/www/manual">
    Order allow,deny
    Deny from all
  </Directory>

• ii. Nginx 설정 (nginx.conf)*
• 숨김 파일 및 백업·텍스트 파일 접근 차단

  location ~ /\.(txt|bak|old|log|sql|zip)$ {
    deny all;
    access_log off;
    log_not_found off;
  }

3. 개발 및 배포 프로세스 개선 (관리적 조치)

기술적 대응과 함께 관리적 통제 절차를 병행하여 동일 유형의 취약점 재발을 방지해야 한다.

• 개발/운영 환경 분리
  • 개발 서버(Staging)와 운영 서버(Production)를 물리적 또는 논리적으로 엄격히 분리
  • 테스트 및 검증은 개발 서버에서만 수행
• 배포 스크립트 활용
• FTP 등 수동 업로드 금지
• 자동화된 배포 도구 활용
  • Jenkins
  • GitHub Actions
• .gitignore 등을 이용한 배포 시 다음 항목 자동 제외
  • 테스트 파일
  • README.md
  • .git 디렉터리
• 정기 점검 수행
  • 분기별 1회 이상 웹 루트 디렉터리 스캔
  • 인가되지 않은 파일 생성 여부 모니터링
  • 변경 이력 관리 및 로그 확인

3.6 SQL Injection

순번	분류	코드	점검 항목
14	SQL Injection	AF-027	SQL Injection 허용 여부
표 3-4: SQL Injection 허용 여부 점검 항목

3.6.1 모의해킹 수행

SQL Injection은 공격자가 SQL Injection 취약점이 있는 웹 서버의 입력 값에 악의적인 sql 질의문을 작성하여 데이터베이스의 정보를 조회, 수정, 삭제 시키는 공격으로 해당 공격이 웹 서버에 허용되는지 체크를 해야한다.

그림 3-20: 문법적 오류 체크

GMSHOP의 자유게시판 검색란에 ‘를 입력하여 사용자의 입력 값이 그대로 웹 서버로 전달되는 지 확인한다. 검색 결과 사용자의 입력 값이 그대로 전달되어 문법적 오류를 일으키며 SQL 종류와 오류 위치를 확인할 수 있다.
즉 SQL Injection 공격 가능성이 존재한다.

그림 3-21: SQL Injection 테스트

자유게시판의 검색란에 ‘ or 1=1# 입력하였고, 그 결과 게시판에 특정
데이터 베이스에 존재하는 데이터들이 모두 select 되어 출력되었다.
결국 SQL Injection이 확인되었다.

그림 3-21: order by 절 이용(Error based SQL Injection)

order by 구문을 이용하여 연동된 데이터베이스의 컬럼의 개수를 확인한다.
‘ order by 24#까지는 정상 출력되었다가 ‘ order by 25#입력에서 문법적 오류가 나왔다. order by 숫자는 몇 번째 열(Column)을 기준으로 정렬을 하는 문법이므로 24개의 컬럼이 존재한다.

그림 3-22: UNION SELECT 문 이용(Error based SQL Injection)

0' UNION SELECT '1', '2', '3', '4', '5', '6', '7', '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20', '21', '22', '23', '24'#

위에 입력한 SQL문(UNION SELECT 문)을 이용하여 검색 결과가 출력될 때 연동된 테이블의 어느 부분의 컬럼 값이 출력 되는지 확인한다. 이때 주의할점은 UNION SELECT 문 이전의 컬럼 개수와 이후의 컬럼 개수가 동일 해야 오류가 안난다. 그림 3-22을 보면 3,4,7,8번째 컬럼 값이 출력된 것을 확인할 수 있다.

그림 3-23: table 확인(Error based SQL Injection)

' UNION SELECT 1,2,table_name,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24 from information_schema.tables#

자유게시판 검색란에 위 SQL문을 입력한 결과, 테이블 이름이 출력되었으며 그중에 사용자 정보로 추측되는 member 테이블을 확인하였다.

그림 3-24: Column 확인(Error based SQL Injection)

1' UNION SELECT 1,2,column_name, 4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24 from information_schema.columns where table_name='member'#

member 테이블의 컬럼 값을 출력하였으며 그중에 로그인에 필요한 칼럼 userid, pwd가 보인다.

그림 3-25: userid, pwd 컬럼 값 확인(Error based SQL Injection)

1' UNION SELECT 1,2,userid,pwd,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24 from member#

member 테이블의 userid,pwd 컬럼 값을 출력하였으며 pwd는 암호화가 되어있다.

그림 3-26 database 첫번째 글자 확인(blind based SQL Injection)

' and substring(database(),1,1)='g'#

and 연산을 이용하여 데이터베이스 이름의 길이를 하나씩 확인한다.
수행결과 6일 경우에 정상적으로 출력이 되었으며, 이는 데이터베이스의 이름이 6글자임을 의미한다.
substring() 함수를 이용하여 database의 첫 번째 글자인 ‘g’를 알아냈다. 반복 작업을 통해 ‘gmshop’이라는 것을 확인하였다.
그러나 이러한 방법은 시간이 오래걸리므로, 자동화 도구인 sqlmap을 이용하여 테이블과 컬럼, 컬럼 값을 확인할 수 있다.

그림 3-27 sqlmap table 검색

그림 3-28 sqlmap table 결과

그림 3-29 sqlmap 컬럼 결과

sqlmap의 -u, -D, -T, --columns 옵션들을 이용하여 admin 테이블의 컬럼을 검색하였다. 검색 결과 admin 계정의 id, pwd로 보이는 컬럼이 존재하여 확인하였다.

그림 3-30 adminId, adminPwd 컬럼의 값 결과

3.6.2 취약점 대응 방안

1. Prepared Statement

PHP 예시 코드:

<?php
// 부적절한 코드
$search = $_GET['q'];
$query = "SELECT * FROM products WHERE name LIKE '%$search%'";
$result = mysqli_query($conn, $query);
?>

// 올바른 코드 - Prepared Statement
<?php
$search = $_GET['q'];
$search = '%' . $search . '%';

$stmt = $conn->prepare("SELECT * FROM products WHERE name LIKE ?");
$stmt->bind_param("s", $search);
$stmt->execute();
$result = $stmt->get_result();

while ($row = $result->fetch_assoc()) {
    echo $row['name'];
}
?>

• 보안 효과
  • SQL Injection 원천 차단
  • 입력 값이 SQL 문법으로 해석되지 않음
  • 실무 환경에서 최우선 적용 권장

2. Parameter Binding (PDO 예시)

<?php
// PDO를 이용한 안전한 쿼리
$search = $_GET['q'];
$stmt = $pdo->prepare("SELECT * FROM products WHERE name LIKE :search");
$stmt->execute(array(':search' => '%' . $search . '%'));
$results = $stmt->fetchAll();
?>

3. 입력 값 검증 및 필터링

입력 값에 대한 사전 검증을 통해 비정상적인 데이터 유입을 차단한다.
다만 단독 사용은 권장되지 않으며, Prepared Statement와 병행 적용해야 한다.

<?php
function safe_search($input) {
    // 1. 길이 제한
    if (strlen($input) > 100) {
        return false;
    }

    // 2. 특수문자 제거
    $input = preg_replace('/[^a-zA-Z0-9가-힣\s]/', '', $input);

    // 3. 따옴표 이스케이프 (보조 방법)
    $input = addslashes($input);

    return $input;
}

$search = safe_search($_GET['q']);
if ($search === false) {
    die('잘못된 검색어입니다.');
}
?>

• 보안 효과
  • 공격 시도 사전 차단
  • 서버 부하 감소
  • 로그 분석 및 이상 행위 탐지에 도움

4. ORM 라이브러리 사용

ORM은 내부적으로 Prepared Statement를 사용하여 개발자가 직접 SQL을 작성하지 않도록 지원한다.

<?php
// Doctrine ORM 사용 예시
$products = $repository->findBy(array('name' => $search));

// 또는 QueryBuilder
$qb = $repository->createQueryBuilder('p')
    ->where('p.name LIKE :search')
    ->setParameter('search', '%' . $search . '%')
    ->getQuery();
$results = $qb->getResult();
?>

• 보안 효과
  • SQL Injection 자동 방어
  • 유지보수성 및 가독성 향상
  • 대규모 프로젝트에 적합

---

3.7 최신 취약점 미패치

순번	분류	코드	점검 항목
15	최신 취약점 미패치	AF-028	보안 취약한 오래된 어플리케이션 사용 여부

표 3-5: 보안 취약한 오래된 어플리케이션 사용 여부 점검 항목

3.7.1 모의해킹 수행

웹 애플리케이션은 보안, 편의성 등의 여러 목적에 따라 패치가 이루어진다. 오래된 버전의 애플리케이션을 사용할 경우 보안에 취약하기에 최신 버전의 패치가 이루어져야 한다. 특히 공격자들은 공개된 취약점을 통해 다양한 해킹 공격을 수행하기 때문에 반드시 최신 버전의 패치가 이루어져야 이러한 공격들을 사전에 예방할 수 있다.

그림 3-31 오랜 버전의 취약한 애플리케이션 버전 사용 여부

알려진 CVE 검색을 진행하여 각종 공격을 이용할 수 있습니다.
https://nvd.nist.gov/ (NIST National Vulnerability Database)
https://cve.mitre.org/
https://www.exploit-db.com/
검색어: Apache 2.2.8, PHP 5.2.4, OpenSSL 0.9.8 등
이러한 버전은 오래된 버전이라 well-known CVE인 경우가 많기 때문에 최신 버전의 패치가 강력 권장된다.

3.7.2 취약점 대응 방안

1. 패치 관리 정책 수립
   • 월간 보안 업데이트 일정 정의
   • 테스트 환경에서 우선 패치 적용
   • 프로덕션 환경에 순차 배포
2. 버전 관리
   • 모든 소프트웨어 버전 목록 유지
   • 정기적인 버전 업그레이드 계획

3. 패치 적용

# Ubuntu/Debian
sudo apt update
sudo apt upgrade
sudo apt install --only-upgrade apache2 php mysql-server

# Rocky Linux/CentOS
sudo yum update
sudo yum upgrade

4. 버전 업그레이드

# Apache 업그레이드
sudo systemctl stop apache2
sudo apt install apache2=2.4.latest
sudo systemctl start apache2

# PHP 업그레이드 (7.0 → 8.0)
sudo apt install php8.0 php8.0-mysql php8.0-curl

# MySQL 업그레이드
sudo mysql_upgrade -u root -p

5. 보안 설정 강화

# Apache 보안 헤더 추가
sudo a2enmod headers
sudo a2enmod rewrite

# .htaccess에 보안 헤더 추가

3.8 부적절한 서버 설정

순번	분류	코드	점검 항목
16	부적절한 서버 설정	AF-029	서버 보안 설정 여부
표 3-6: 서버 보안 설정 여부 점검 항목

3.8.1 모의해킹 수행

웹 서버를 운영하는데 불필요한 서비스나 취약한 버전의 소프트웨어를 사용하고 있는지 확인해야 하며 서버 설정에 있어서 취약한 부분이 있는지 확인해야 한다.

그림 3-32 Chrome 개발자 도구에서 확인

그림 3-33 Nmap스캔을 통한 확인

명령어: sudo namp -sV --script=vuln 192.168.206.128

3.8.2 취약점 대응 방안

1. Apache 보안 설정(.htaccess)

# 디렉토리 리스팅 비활성화
Options -Indexes

# 보안 헤더 추가
<IfModule mod_headers.c>
    Header set X-Frame-Options "SAMEORIGIN"
    Header set X-Content-Type-Options "nosniff"
    Header set X-XSS-Protection "1; mode=block"
    Header set Strict-Transport-Security "max-age=31536000; includeSubDomains"
    Header set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'"
</IfModule>

# 에러 메시지 숨기기
ErrorDocument 403 "Forbidden"
ErrorDocument 404 "Not Found"

# PHP 에러 표시 비활성화
php_flag display_errors off
php_flag display_startup_errors off

# 위험한 파일 보호
<FilesMatch "^\.ht">
    Deny from all
</FilesMatch>

<FilesMatch "\.(config|sql|ini|bak|old)$">
    Deny from all
</FilesMatch>

2. Nginx 보안 설정(nginx.conf)

# 서버 정보 숨기기
server_tokens off;

# 보안 헤더
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

# PHP 파일 보호
location ~ \.php$ {
    try_files $uri =404;
    include fastcgi_params;
    fastcgi_pass unix:/var/run/php-fpm.sock;
}

# 디렉토리 리스팅 비활성화
location / {
    autoindex off;
}

# 민감한 파일 보호
location ~ /\. {
    deny all;
}

3. PHP 보안 설정(php.ini)

; 에러 표시 비활성화
display_errors = Off
display_startup_errors = Off

; 에러 로깅
log_errors = On
error_log = /var/log/php-errors.log

; 위험한 함수 비활성화
disable_functions = system,exec,passthru,shell_exec,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source

; 파일 업로드 제한
file_uploads = On
upload_max_filesize = 10M
post_max_size = 10M

; 세션 보안
session.cookie_httponly = On
session.cookie_secure = On
session.use_strict_mode = On

; 기본 문자 인코딩
default_charset = "UTF-8"

3.9 법적 요구사항 검토

순번	분류	코드	점검 항목
17	법적 요구사항 검토	AF-030	개인정보보호법 적절성 여부
표 3-7: 개인정보보호법 적절성 여부 점검 항목

3.9.1 모의해킹 수행

웹 사이트 운영 시 준수해야 할 개인정보 수집, 이용, 파기 및 고지 의무가 최신 법령에 맞게 적용되었는지 검토를 중점으로 진행하였습니다. 만일 이러한 사항이 준수되지 않을 경우 법적 제재(과징금), 서비스 신뢰도 하락, 회원 가입 불가(RRN 수집 금지 위반 등) 등이 악영향이 자사에 미칠 수 있습니다.

그림 3-34: gmshop의 개인보호정책

그림 3-35: gmshop의 이용약관

현재 귀사의 개인보호정책 및 이용약관을 분석한 결과 개인정보 보호법의 주요 조항을 다수 위반하고 있음이 식별되었습니다.

i. 주민등록번호 수집 금지 위반 (제24조의2)

이용약관 제17조 제1항 제2호에 “주민등록번호(회원의 경우) 또는 외국인등록번호”를 필수 수집 항목으로 명시하고 있습니다. 그러나 2014년 8월 7일부터 법적 근거가 있는 경우를 제외하고 주민등록번호 수집·처리는 원칙적으로 금지하고 있으며, 일반 쇼핑몰 회원가입은 허용 대상이 아닙니다. 이는 헌법상 합목적성 원칙에 위배됩니다.

ii. 만 14세 미만 아동 법정대리인 동의 미비 (제22조의2, 제39조의3)

회원가입 약관 및 개인정보처리방침에 만 14세 미만 아동 가입 시 법정대리인 동의 절차가 전무한 상태입니다. 만 14세 미만 아동의 개인정보 수집 시 법정대리인의 동의 및 본인확인 절차는 법적 의무에 해당하므로 반드시 준수 해야합니다.

iii. 개인정보 수집·이용 고지 의무 미비 (제15조, 제22조)

이용약관 제17조에 수집 항목만 나열하였으며 개인정보 보유 및 이용 기간, 동의 거부 권리, 동의 거부 시 불이익 내용과 같은 필수 고지 사항이 누락되어있음을 확인하였습니다.

iv. 개인정보 파기 절차 및 방법 미흡 (제21조)

이용약관에 “지체 없이 파기합니다”라는 포괄적 표현만 존재하므로 헌법상 명확성의 원칙에 위배됩니다. 파기 절차(DB 삭제, 문서 분쇄 등)와 파기 방법(복구 불가능한 방식) 등을 구체적으로 명시해야 합니다.

3.9.2 취약점 대응 방안

i. 주민등록번호 수집 금지 위반 (제24조의2)

수집 항목에서 주민등록번호를 완전히 삭제하여야 합니다.

예시

[삭제] 주민등록번호(회원의 경우)
[변경] 본인인증기관(CI/DI), 생년월일, 성별 (본인인증 시 수집)

ii. 만 14세 미만 아동 법정대리인 동의 미비 (제22조의2, 제39조의3)

아래와 같은 문구 혹은 절차 등를 수행해야 합니다. 기타 방법은 개인정보 보호법 시행령 제17조의2의 각 호의 어느 하나에 해당하는 방법으로 해야 합니다.

• 가입 제한

“본 사이트는 만 14세 미만의 회원가입을 제한합니다.”

• 별도 동의 절차

만 14세 미만 확인 시 법정대리인 휴대폰 인증 절차 강제 수행

iii. 개인정보 수집·이용 고지 의무 미비 (제15조, 제22조)

개인정보 수집·이용 동의서를 구체화하여야 합니다.

개선된 개인정보 수집 및 이용 동의 예시

구분	목적	항목	보유 및 이용 기간
필수	본인 확인, 회원 관리	아이디, 비밀번호, 이름, 휴대폰번호, 이메일, 생년월일	회원 탈퇴 시까지
필수	상품 배송	배송지 주소, 수령인 연락처	5년 (전자상거래법)

※ 동의 거부 권리 고지 예시
귀하는 개인정보 수집·이용에 거부할 권리가 있으나, 거부 시 회원가입 및 서비스 이용이 제한됩니다.

iv. 개인정보 파기 절차 및 방법 미흡 (제21조)

보유 기간의 법적 근거를 명시하여야 합니다.
관계 법령에 따라 다음과 같이 개인정보를 보관합니다.

1. 계약 또는 청약철회 기록: 5년 (전자상거래법)
2. 대금결제 및 재화 공급 기록: 5년 (전자상거래법)
3. 소비자 불만·분쟁 처리 기록: 3년 (전자상거래법)
4. 접속 로그, 접속 IP: 3개월 (통신비밀보호법)

참고 자료

1. KISA 주요정보통신기반시설 기술적 취약점 분석 평가 상세가이드(2021.04)

2. 개인정보 보호법

3. 정보통신망 이용촉진 및 정보보호 등에 관한 법률
4. 개인정보 보호법 시행령
5. CVE 데이터베이스_NIST, CVE 데이터베이스_MITRE
6. CVSS v3.1 계산

---

마치며...

아직 점검항목에 따라서 모든 항목을 수행하기에는 시간이 모자르기 때문에 제가 수행한 점검항목만 우선 남겼습니다. 추후에 시간이 난다면 수정하여 다시 업데이트 하겠습니다.(근데 시간이 날지 모르겠네..??)발표 진행할 때 보니까 다른 조들도 시간이 부족하셨는지 모든 점검항목을 수행한 조는 없었던 것 같습니다. 그리고 사실 gmshop말고도 test.php 등의 취약한 웹사이트를 하나 더 수행하여 보고서를 작성해야 했는데 이 역시 gmshop하기에도 굉장히 벅차서 수행을 못 하였습니다. 강사님께서 실무에서 gmshop같은 곳은 한 6시간 정도만에 모의해킹을 수행하고 보고서까지 만들어야 된다고....
???????????????????????
물론 이렇게 점검항목에 따라서 모의해킹을 수행하고 보고서를 제작하는 과정이 처음이라서 시간이 오래걸리기는 했다. 저번 게시물을 보면 수행일정이 나와있는데 약 30시간 정도 시간을 주셨다. 덕분에 학교에서 노숙을....
작성한 게시물 내용을 읽어보면 알겠지만 상당히 개판이다.
내가 평가할 입장은 아니지만....
아무튼 여러모로 진행과정에서 탈도 많아서 다시 한 번 팀플은 쉽지 않다는 것을 느꼈다. ㅋㅋㅋ 웃음밖에 안 나오네 ㅋㅋㅋ
그나마 위안 삼았던 것은 해당 점검항목을 모두 수행한 뒤에 수행 결과 요약 파트에서 강사님께 잘했다는 말을 들은 것이다. 내가 위에서 수행한 항목이 이거라고 했는데 모두 수행했다는 말이 뭔소리냐고 물어본다면 모의해킹은 모두 수행하였는데 그걸 보고서에 녹이지 못했다는 말이다. 따라서 당연히 캡처와 취약점, 취약점 대응 방안은 작성하지 못하였다.
그래서 강사님 가라사대 '여러분이 모의 해킹을 다 수행하고 보고서를 작성하려고 하면 안 됩니다! 바로바로 보고서에 적으세요!!'
이래나저래나 내가 직접 모의해킹을 수행하고 보고서를 작성했다는 것에 의의를 둔다면 이번 프로젝트(?)는 상당한 경험이었다고 사료된다.
마지막으로 이 글을 읽는 사람들에게 하고싶은 말은 조오오온나~ ~ 열심히 해야한다!
찐막으로 말하자면 원본 보고서 양식은 저작권법에 의하여 보호되기 때문에 공유드리지 못한다. 그래서 내가 일부 양식과 서식은 변경하였다. 그러면 당연히 내가 작성한 게시물도 저작권법에 의해 보호되니 제발 ~ ~ ~ ~ 긁지 마라! 정 긁고 싶으면 댓글다세요! 그럼 인정해드림. 우리 모두 리걸마인드를 탑재하고 삶을 살아갑시다. 애플리케이션 보안 기술 끝

~