Phát Hiện Lỗ Hổng Lộ Dữ Liệu CCCD Của 896 Thí Sinh Tại Một Trường Đại Học Việt Nam
by Hoang Phi Pham
March 24, 2026 · IDOR, Broken Access Control, API Abuse, Data Exposure, CVSS Critical
https://hoangphi01.github.io/blog/2026/03/24/vn-universityx-candidate-data-exposure-CNMENU/
Phát Hiện Lỗ Hổng Lộ Dữ Liệu CCCD Của 896 Thí Sinh Tại Một Trường Đại Học Việt Nam

Phát Hiện Lỗ Hổng Lộ Dữ Liệu CCCD Của 896 Thí Sinh Tại Một Trường Đại Học Việt Nam

March 24, 2026 · 52 min read IDOR Broken Access Control API Abuse Data Exposure CVSS Critical

Cập nhật (23 tháng 6, 2026): Đã khắc phục một phần

Công ty Y đã thêm xác thực phía server trên cổng API XHR và chặn IDOR cấp tài khoản. Tuy nhiên, dữ liệu thí sinh vẫn bị lộ một phần, liệt kê ID hàng loạt vẫn hoạt động, và truy cập ảnh CDN đã bị hồi quy. Xem chi tiết kiểm tra lại bên dưới.

LOW MEDIUM HIGH CRITICAL

CVSS 3.1: 9.1 (CRITICAL)

Lỗ hổng cho phép trích xuất dữ liệu định danh và sinh trắc học không cần xác thực.

Tóm tắt

Trường Đại học X là một trong những trường đại học công lập danh tiếng tại Việt Nam, với khoảng 40.000 sinh viên theo học ở nhiều khoa khác nhau. Trung tâm Khảo thí của trường tổ chức các kỳ thi năng lực ngoại ngữ chuẩn hóa cho hàng trăm thí sinh mỗi đợt. Khi đăng ký dự thi, thí sinh phải cung cấp những thông tin cá nhân vô cùng nhạy cảm: họ tên đầy đủ, ngày sinh, số điện thoại, email, số CCCD, và đặc biệt là ảnh chụp độ phân giải cao mặt trước và mặt sau của thẻ căn cước công dân. Nếu bị lộ, khối dữ liệu này tạo thành một bộ hồ sơ danh tính hoàn chỉnh – mà không giống như mật khẩu, nó không bao giờ có thể “đặt lại” được.

Mọi chuyện bắt đầu từ một tìm kiếm Google bình thường. Khi gõ các từ khóa liên quan đến kỳ thi, kết quả trả về một đường dẫn trực tiếp đến trang web Trung tâm Khảo thí. Chỉ cần nhấp chuột, toàn bộ hồ sơ đăng ký của một thí sinh hiện ra trên màn hình: họ tên, ngày sinh, số CCCD, và cả ảnh chụp thẻ căn cước – tất cả được hiển thị công khai trên một trang web không yêu cầu đăng nhập.

Không cần mật khẩu. Không cần công cụ đặc biệt. Chỉ cần một cú tìm kiếm Google và một cú nhấp chuột.

Thông qua việc dịch ngược framework JavaScript của nền tảng, tôi xác nhận rằng đây không phải sự cố đơn lẻ. Toàn bộ hệ thống, được xây dựng bởi Công ty Y trên nền tảng SaaS “Connections,” hoàn toàn không có bất kỳ cơ chế kiểm soát truy cập nào. Dữ liệu cá nhân của toàn bộ 896 thí sinh bao gồm số CCCD/CMND, dân tộc, nơi sinh, và ảnh chụp mặt trước và mặt sau của căn cước công dân đều có thể bị trích xuất một cách có hệ thống bởi bất kỳ ai có trình duyệt web.

1. Giới thiệu

1.1. Bối cảnh

Trường Đại học X là một trong những trường đại học công lập có tiếng tại Việt Nam, với khoảng 40.000 sinh viên theo học ở nhiều khoa. Trường đặc biệt được biết đến với các chương trình đào tạo ngoại ngữ và nghiên cứu quốc tế. Trung tâm Khảo thí của trường vận hành hệ thống web tại tec.universityx.vn, nơi tổ chức các kỳ thi năng lực ngoại ngữ chuẩn hóa như VSTEP (Vietnamese Standardized Test of English Proficiency) cho hàng trăm thí sinh mỗi đợt. Hệ thống quản lý toàn bộ vòng đời thi cử: đăng ký dự thi, phân phòng thi, công bố danh sách thí sinh, và thông báo kết quả.

Trong quá trình đăng ký, thí sinh phải cung cấp những thông tin cá nhân vô cùng nhạy cảm: họ tên đầy đủ, ngày sinh, số điện thoại, email, số CCCD, dân tộc, và đặc biệt là ảnh chụp độ phân giải cao mặt trước và mặt sau của thẻ căn cước công dân. Nếu bị lộ, khối dữ liệu này tạo thành bộ hồ sơ danh tính hoàn chỉnh cho mỗi cá nhân – một bộ hồ sơ mà khác với mật khẩu, không bao giờ có thể thay đổi hay thu hồi được.

1.2. Nền tảng Bên thứ ba: Công ty Y

Giống như nhiều cơ sở giáo dục tại Việt Nam, Trường Đại học X không tự xây dựng hay vận hành phần mềm của mình. Thay vào đó, toàn bộ hệ thống quản lý thi cử bao gồm cơ sở dữ liệu, tầng API (Application Programming Interface - giao diện lập trình ứng dụng), lưu trữ tập tin, và CDN (Content Delivery Network - mạng phân phối nội dung) đều chạy trên nền tảng SaaS mang tên “Connections,” do Công ty Y (companyy.com) phát triển và vận hành.

Điều này có nghĩa là Trường Đại học X đã giao toàn quyền kiểm soát dữ liệu nhạy cảm nhất của thí sinh cho một nhà cung cấp bên ngoài. Nhà trường nhiều khả năng tin tưởng rằng nền tảng này có các biện pháp bảo mật phù hợp. Câu hỏi mà báo cáo này trả lời: liệu nó có an toàn không?

Câu trả lời là không. Nền tảng Connections hoàn toàn không có bất kỳ ranh giới kiểm soát truy cập nào giữa một người lạ trên internet và dữ liệu cá nhân lưu trong cơ sở dữ liệu.

Mọi chuyện bắt đầu từ một cú tìm kiếm Google đơn giản. Khi gõ các từ khóa liên quan đến kỳ thi, kết quả trả về một đường dẫn trực tiếp đến trang web Trung tâm Khảo thí. Chỉ cần nhấp vào, toàn bộ phiếu đăng ký thi của một thí sinh hiện ra: họ tên đầy đủ, ngày sinh, số CCCD, và cả ảnh chụp thẻ căn cước – tất cả được hiển thị trên một trang web công khai.

Không cần đăng nhập. Không cần công cụ đặc biệt. Chỉ cần một cú tìm kiếm Google và một cú nhấp chuột.

Điều này đặt ra câu hỏi then chốt: đây là sự cố lộ dữ liệu của riêng một thí sinh, hay toàn bộ thông tin cá nhân của mọi thí sinh đều đang bị phơi bày?

Câu trả lời, như báo cáo này chứng minh, là trường hợp thứ hai.

Kết quả tìm kiếm Google hiển thị thông tin cá nhân thí sinh được lập chỉ mục công khai Hình 1: Kết quả tìm kiếm Google tiết lộ dữ liệu đăng ký của thí sinh bao gồm họ tên, ngày sinh, và số CCCD – được lập chỉ mục công khai và bất kỳ ai cũng có thể truy cập.

1.4. Phạm vi và Đạo đức

Nghiên cứu được thực hiện nghiêm ngặt cho mục đích đánh giá bảo mật:

  • Mọi truy cập dữ liệu đều sử dụng các điểm cuối công khai.
  • Không có xác thực nào bị vượt qua - vì không có xác thực nào tồn tại để vượt qua.
  • Không có dữ liệu nào bị sửa đổi, xóa, hoặc tuồn ra cho bên thứ ba.
  • Không thực hiện tấn công brute-force lên các tài nguyên được bảo vệ.
  • Các kỹ thuật mô tả sao chép lại những gì bất kỳ người dùng internet nào có kiến thức kỹ thuật cơ bản cũng có thể thực hiện thông qua developer console của trình duyệt web.

1.5. Phân loại Kỹ thuật Tấn công

Các kỹ thuật MITRE ATT&CK và danh mục OWASP sau đây có liên quan đến các phương pháp được sử dụng trong nghiên cứu này:

Kỹ thuật Framework Ứng dụng trong nghiên cứu
IDOR (Insecure Direct Object Reference) OWASP Top 10 ID đối tượng CSDL được dùng trực tiếp trong API không cấp phép
Broken Access Control OWASP Top 10 Không có xác thực trên bất kỳ điểm cuối API nào
API Abuse OWASP API Top 10 Truy cập không giới hạn vào thao tác tìm kiếm và tải dữ liệu
Reconnaissance (T1592) MITRE ATT&CK Google dorking để phát hiện trang PII được lập chỉ mục
Active Scanning (T1595) MITRE ATT&CK Quét thăm dò các điểm cuối API và schema cơ sở dữ liệu
Data from Info Repos (T1213) MITRE ATT&CK Trích xuất dữ liệu từ API cơ sở dữ liệu bị phơi bày
JS API Hijacking Web Security Gọi hàm nội bộ của framework qua page.evaluate()
Foreign Key Traversal Database Security Theo dõi khóa ngoại để khám phá các bảng ẩn
CDN URL Harvesting Web Security Trích xuất URL ảnh đã mã hóa từ DOM đã render

2. Lập Bản đồ Hạ tầng: Trường Đại học X, Công ty Y và Connections

Trước khi đi sâu vào lỗ hổng, cần hiểu rõ ai thực sự vận hành hệ thống này và các thành phần được kết nối với nhau như thế nào. Trang web Trung tâm Khảo thí không đơn giản như vẻ bề ngoài của nó.

2.1. Phát hiện Mối quan hệ Nhà cung cấp

Bước đầu tiên trong phân tích là tìm hiểu ai thực sự vận hành hạ tầng đằng sau tec.universityx.vn. Kiểm tra mã nguồn HTML cho thấy ứng dụng web tải framework JavaScript cốt lõi từ tên miền bên ngoài:

<script src="https://cdn.companyy.com/js/jquery.main.isj"></script>
<script src="https://cdn.companyy.com/js/include.core.isj"></script>

Tên miền companyy.com thuộc về Công ty Y, một công ty công nghệ tại Việt Nam. Phân tích sâu hơn cho thấy một hạ tầng nhiều tên miền ngổn ngang:

Tên miền Vai trò Liên hệ với Trường Đại học X
companyy.com Tên miền công ty Nhà cung cấp nền tảng
cdn.companyy.com CDN JavaScript Phân phối framework JS/CSS
xhr.companyy.com Cổng API Xử lý mọi cuộc gọi XHR (XMLHttpRequest - API trao đổi dữ liệu nền) đến CSDL
tts.companyy.vn Máy chủ framework Lưu trữ file cấu hình ứng dụng
connections.vn Thương hiệu nền tảng Nền tảng SaaS “Connections”
connections.universityx.vn API riêng Trường Đại học X Điểm cuối API dành riêng cho Trường Đại học X
local.universityx.connections.vn Lưu trữ tập tin Chứa PDF và các tập tin tải lên
i0.connections.vn CDN ảnh (node 0) Phân phối ảnh chụp CCCD
i3.connections.vn CDN ảnh (node 3) Phân phối ảnh chụp CCCD
thuctap.companyy.com Máy chủ CSS Phân phối CSS cho ứng dụng con

2.2. Kiến trúc Nền tảng “Connections”

Nền tảng “Connections” dường như là một framework SaaS đa mục đích tương tự như Salesforce hoặc Airtable – cung cấp:

  • Một tầng cơ sở dữ liệu nơi các bảng được định danh bằng các mã băm hệ thập lục phân 32 ký tự
  • Một framework JavaScript phía client với các hàm API tiếng Việt (xửLý, CĂN.db, config)
  • Một CDN lưu trữ tập tin tại local.{org}.connections.vn
  • Một CDN ảnh tại i{N}.connections.vn với tham số URL được mã hóa
  • Một kiến trúc multi-tenant nơi nhiều tổ chức (Trường Đại học X, và có thể nhiều đơn vị khác) dùng chung một hạ tầng

Hệ quả bảo mật quan trọng: dữ liệu thí sinh của Trường Đại học X bao gồm ảnh chụp CCCD được lưu trữ trên và phân phối bởi hạ tầng chung của Công ty Y, không phải trên các máy chủ do Trường Đại học X kiểm soát.

2.3. Cấu trúc Tên miền con và Luồng Dữ liệu

Trinh duyet nguoi dung
    |
    |-- (1) GET tec.universityx.vn/page
    |         |-- Tai bo khung HTML
    |
    |-- Tai JS tu cdn.companyy.com
    |         |-- Tai CSS tu thuctap.companyy.com
    |
    |-- (2) XHR den xhr.companyy.com/xhr/ (hoac connections.universityx.vn/xhr/)
    |
    |-- "doiTuong.tai.{table_hash}" = truy van co so du lieu
    |         |-- Tra ve danh sach cac ID doi tuong
    |
    |-- (3) XHR den xhr.companyy.com/xhr/
    |         |-- "CAN.db({table}.{id})" = tai doi tuong
    |
    |-- Tra ve TAT CA cac truong bao gom CCCD, SDT, v.v.
    |
    |-- (4) GET local.universityx.connections.vn/upload/{cat}/{date}/{file}
    |
    |-- Tai xuong cac file PDF (danh sach thi sinh)
    |
    |-- (5) GET i0.connections.vn/{duong_dan_ma_hoa}?q={token_ma_hoa}
              |-- Tai xuong anh chup the CCCD (mat truoc/mat sau)

Không có yêu cầu nào trong số này cần xác thực.

3. Dịch ngược Cấu trúc Cơ sở Dữ liệu

Bước tiếp theo là tìm hiểu cách cơ sở dữ liệu được tổ chức. Quá trình này đòi hỏi phải đọc mã nguồn JavaScript của trang web – một framework được viết hoàn toàn bằng tiếng Việt – và phát hiện ra rằng các mã định danh bảng cùng ID bản ghi được truyền qua lại mà không có bất kỳ kiểm tra bảo mật nào.

3.1. Giai đoạn 1: Phân tích Cấu trúc URL

URL ban đầu được Google lập chỉ mục cung cấp manh mối đầu tiên về cấu trúc cơ sở dữ liệu:

https://tec.universityx.vn/7fdc5fa41f345xxxx4bba6b0d3e449385/1518250/2368M35018
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^  ^^^^^^^  ^^^^^^^^^^
                    Ma bam bang (Dang ky)             ID obj   Ma ho so

URL này trực tiếp lộ ra:

  1. Mã băm bảng Đăng ký: 7fdc5fa41f345xxxx4bba6b0d3e449385
  2. ID đối tượng đăng ký: 1518250
  3. Mã hồ sơ của thí sinh: 2368M35018

3.2. Giai đoạn 2: Dịch ngược Framework JavaScript

Mã nguồn framework tại cdn.companyy.com/js/include.core.isj bị nén mạnh (heavily minified) và sử dụng các định danh tiếng Việt. Qua phân tích runtime (thực thi hàm trong console trình duyệt và quan sát lưu lượng XHR), tôi đã xác định được các hàm API cốt lõi:

Hàm Hành vi (Được khám phá)
xửLý(action, params, opts, cb) Bộ điều phối chính. Gửi XHR đến xhr.companyy.com/xhr/. Chuỗi action quyết định hành động.
CĂN.db(key, callback) Tải đối tượng CSDL theo key (định dạng: ma_bam_bang.id_doi_tuong). Cache kết quả vào bộ nhớ cục bộ.
config(key) Lấy đối tượng đã tải trước đó từ cache cục bộ. Trả về đối tượng JavaScript với ID trường (số) làm key.
dữLiệu Đối tượng toàn cục (Global) chứa ngữ cảnh dữ liệu của trang web.

3.3. Giai đoạn 3: Khám phá Schema CSDL qua IDOR

Phát hiện then chốt là API sử dụng Tham chiếu Đối tượng Trực tiếp Không An toàn (IDOR): mã băm bảng cơ sở dữ liệu và ID đối tượng được truyền trực tiếp từ client lên server mà không có kiểm tra ủy quyền. Điều này cho phép tôi:

  1. Tải mã băm bảng Đăng ký (nhìn thấy trong URL)
  2. Truy vấn bảng Đăng ký bằng cách sử dụng xửLý("đốiTượng.tải.{hash}", ...) với bộ lọc trường bất kỳ
  3. Tải một đối tượng Đăng ký và kiểm tra tất cả các trường của nó – khám phá các ID trường, kiểu dữ liệu, và tham chiếu khóa ngoại
  4. Khám phá mã băm bảng Thí sinh bằng cách theo dõi khóa ngoại trong trường 1686869 (ID Thí sinh), trường này tham chiếu đến các đối tượng trong bảng 3576ff3533bb4xxxx8e394a0aa83a461f
  5. Tải đối tượng Thí sinh để truy cập toàn bộ các trường dữ liệu cá nhân

3.4. Giai đoạn 4: Ánh xạ từng trường dữ liệu

Mỗi đối tượng cơ sở dữ liệu được trả về dưới dạng một từ điển (dictionary) với các key là chuỗi số (ID trường). Tôi đã ánh xạ chúng bằng cách:

  1. Tải nhiều đối tượng thí sinh
  2. Đối chiếu chéo (Cross-referencing) các giá trị trường với nội dung trang được render
  3. Xác định kiểu trường (chuỗi, số nguyên, ngày tháng, tham chiếu, tập tin)

Hệ thống Kiểu Trường

Framework sử dụng các ký tự tiếng Việt đơn lẻ để đánh dấu kiểu trường trong các giá trị lưu trữ:

Ký hiệu Định dạng lưu trữ Ý nghĩa
(không có) Chuỗi/Số thông thường Giá trị trực tiếp (họ tên, SDT, CCCD)
{"ậ":["ID"]} JSON với ID tham chiếu Tham chiếu đến đối tượng khác (dân tộc, tỉnh)
{"ị":["ID"]} JSON với ID tập tin Tham chiếu đến một tập tin/ảnh đã tải lên

Kiểu "ậ" (tham chiếu) lưu trữ một con trỏ tới một đối tượng tra cứu (lookup object) ví dụ, trường dân tộc 1626773 lưu {"ậ":["146992"]}, giá trị này được phân giải thành “Kinh” khi trang web render. Kiểu "ị" (tập tin) lưu trữ con trỏ tới tập tin tải lên ví dụ, trường 1658487 lưu {"ị":["4296"]}, giá trị này được phân giải thành bức ảnh CCCD trên image CDN.

Bảng Ánh xạ Trường Bảng Đăng ký (Đã dịch ngược)

ID Trường Tên trường Kiểu Ví dụ
1626725 ID Ca thi Khóa ngoại (FK) 54914
1626730 Mã hồ sơ Chuỗi 2368M35018
1630529 Mã trạng thái Số nguyên 1
1630538 Cờ hoạt động Boolean 1
1642331 SBD (Số báo danh) Chuỗi AN1001
1654914 Thời gian đăng ký Timestamp 1726716820
1686869 ID Thí sinh Khóa ngoại (FK) 582319
1704995 Điểm số JSON [{“nghe”:”8.5”}]
mãĐịnhDanh Mã ID Chuỗi V2KT2106AN1114
tổngTiền Lệ phí Số nguyên 1800000

Bảng Ánh xạ Trường Bảng Thí sinh (Đã dịch ngược)

ID Trường Tên trường Kiểu Ví dụ / Chú thích
1686868 Họ tên đầy đủ Chuỗi Nguyễn xxx xxxx Trà
1626768 Họ và Tên đệm Chuỗi Nguyễn Thị xxxx
1626772 Tên Chuỗi Trà
1626773 Dân tộc Tham chiếu {“ậ”:[“146992”]} → Kinh
1626783 Ngày sinh Ngày 28/09/2000
1626784 Giới tính Enum 1=Nam, 2=Nữ
1626788 Số điện thoại Chuỗi 037xxxx973
1626793 Email Chuỗi email@gmail.com
1626818 Nơi sinh Tham chiếu {“ậ”:[“147000”]} → Tỉnh Bắc Kạn
1626820 Tỉnh/Thành phố (Hiện tại) Tham chiếu {“ậ”:[“146999”]}
1646777 Số CCCD/CMND Chuỗi 0222xxxx2576
1658487 Ảnh CCCD (mặt trước) Tham chiếu file {“ị”:[“4296”]}
1658488 Ảnh CCCD (mặt sau) Tham chiếu file {“ị”:[“243”]}
2102859 Đơn vị công tác Chuỗi Văn bản tự do

3.5. Giai đoạn 5: Sơ đồ Duyệt Khóa ngoại

Đường dẫn duyệt (traversal path) hoàn chỉnh từ một URL công khai đến các bức ảnh thẻ CCCD:

+-------------------------------------------+
|           URL Công khai                    |
|  tec.universityx.vn/{hash}/{id}/{file}            |
+---------------------+---------------------+
                      |
          lộ mã băm bảng + ID đối tượng
                      |
                      v
+-------------------------------------------+
|        Đối tượng Đăng ký                   |
|  Bảng: 7fdc5fa4...                         |
|  Chứa SBD, mã hồ sơ                       |
+---------------------+---------------------+
                      |
           trường khóa ngoại 1686869
                      |
                      v
+-------------------------------------------+
|        Đối tượng Thí sinh                  |
|  Bảng: 3576ff35...                         |
|  Chứa TẤT CẢ PII                          |
+----------+----------------+---------------+
           |                |
           v                v
+-------------------+  +----------------------+
| Dữ liệu Cá nhân  |  | Ảnh Thẻ CCCD         |
| CCCD, SDT, Email, |  | Mặt trước + Mặt sau  |
| Dân tộc, Nơi sinh |  | trên i0.connections.vn |
+-------------------+  +----------------------+

4. Khám phá CDN: Hạ tầng Ảnh và Tập tin

Ảnh chụp căn cước công dân được lưu trữ trên một máy chủ hình ảnh riêng biệt, không nằm trong cơ sở dữ liệu chính. Việc hiểu cách các URL hình ảnh được tạo ra là chìa khóa để chứng minh rằng bất kỳ ai cũng có thể tải xuống hàng loạt ảnh CCCD.

4.1. CDN Tập tin tĩnh: local.universityx.connections.vn

Tất cả tài liệu được tải lên (PDF, danh sách thí sinh) được lưu tại máy chủ tập tin tĩnh với cấu trúc URL có thể dự đoán được:

https://local.universityx.connections.vn/upload/{category_id}/{YYYY/MM/DD}/{uuid_filename}

Metadata của file bao gồm toàn bộ các thành phần tạo nên URL được nhúng vào HTML của trang chính dưới dạng một khối JSON được cache lại. Các metadata này sử dụng tên trường bằng tiếng Việt bị làm ngắn (minified):

Key JSON Ý nghĩa Ví dụ
"i" ID Tập tin 534167
"ạ" ID Danh mục 25
"ô" Hostname máy chủ local.universityx.connections.vn
"ớ" Đường dẫn ngày tháng 2024/09/19
"ũ" Tên file gốc Danh sach phong thi.pdf
"ợ" Tên file trên máy chủ (UUID) f2247559bcac…03.pdf

Tôi đã phát hiện ra 32 tập PDF danh sách thí sinh bằng cách phân tích metadata này và lọc các tên file có chứa “danh sach” hoặc “phong thi.” Tôi đã gặp phải một lỗi nghiêm trọng (critical bug): các dấu gạch chéo trong đường dẫn ngày tháng bị escape bằng JSON (2024\/09\/19) đã gây ra lỗi HTTP 404 cho đến khi tôi thêm logic unescape đường dẫn vào code.

4.2. CDN Ảnh: i{N}.connections.vn

Phát hiện nhạy cảm nhất là hạ tầng CDN ảnh. Ảnh chụp CCCD được phân phối từ CDN cân bằng tải với các node i0.connections.vn, i3.connections.vn, v.v.

URL Ảnh Mã hóa

Khác với CDN tập tin tĩnh (sử dụng đường dẫn có thể đọc được), CDN ảnh sử dụng đường dẫn và tham số truy vấn mã hóa/được mã hóa:

# Anh CCCD mat truoc:
https://i0.connections.vn/kt3PG1hPTgTPG1MJ.u54.L8JKx-X.LDJ9Ei
  tREHqGaAN9ZWP6gM46Wbb?q=wqQ2KLBn6g3dDaf29mOnD7stDafo9aAo...

# Anh CCCD mat sau:
https://i0.connections.vn/kt3PG1hPTgTPG1MJ.u54.L8JKx-X.LDJ9Ei
  z9mONGaAN9ZWP6gM46Wbb?q=wqQ2KLBn6g3dDaf29mOnD7stDafo9aAo...

# Anh the chan dung:
https://i0.connections.vn/kt3PG1hPTgTPG1MJ.u54.L8JKx-X.LDJ9Ei
  tREHdGaAN9ZWP6gM46Wbb?q=wqQ2KLBn6g3dDaf29mOnD7stDafo9aAo...

Các quan sát quan trọng về cấu trúc URL:

  • Đường dẫn (path) của URL mã hóa tham chiếu tập tin - các hình ảnh khác nhau của cùng một thí sinh khác biệt vài ký tự trong phần đường dẫn
  • Tham số truy vấn q= dường như là một token phiên hoặc token xác thực, nhưng lại giống hệt nhau trên tất cả hình ảnh trong cùng một lần tải trang, cho thấy nó là token cấp độ trang chứ không phải cho từng hình ảnh riêng lẻ
  • Các URL này không thể đoán được - chỉ có thể lấy được bằng cách render trang chi tiết của thí sinh trong trình duyệt (do framework JavaScript sinh ra chúng tại runtime)
  • Tuy nhiên, một khi trang đã được render, các URL này có thể tải xuống trực tiếp qua HTTP GET đơn giản mà không cần cookie hay header bổ sung nào

Cách thức URL Ảnh được tạo ra

Framework JavaScript tạo các URL CDN ảnh trong quá trình render trang thông qua quá trình:

  1. Đọc trường tham chiếu tập tin (ví dụ: {"ị":["4296"]})
  2. Mã hóa ID tập tin, ngữ cảnh tổ chức, và một session token vào đường dẫn URL và chuỗi truy vấn (query string)
  3. Gán URL đó làm thuộc tính background-image của CSS trên một thẻ <div>

Điều này có nghĩa là URL ảnh không thể được xây dựng bằng code chỉ với các ID tập tin thuật toán mã hóa của framework JavaScript bắt buộc phải được thực thi trong môi trường trình duyệt. Công cụ của tôi giải quyết vấn đề này bằng cách render trang của mỗi thí sinh bằng trình duyệt headless và trích xuất URL background-image từ DOM.

Xác minh quá trình Tải Ảnh

Các hình ảnh tải xuống được xác minh là ảnh chụp CCCD thực tế:

  • Dung lượng file từ 44KB đến 228KB (phù hợp với ảnh chụp điện thoại thẻ ID)
  • Là các tệp hình ảnh JPEG hợp lệ
  • Ba hình ảnh cho mỗi thí sinh (thông thường): ảnh thẻ chân dung, CCCD mặt trước, CCCD mặt sau
  • Các hình ảnh chứa văn bản có thể đọc được bao gồm họ tên thí sinh, số CCCD, ngày sinh, và địa chỉ in trên thẻ vật lý

Trình quản lý tệp hiển thị ảnh căn cước công dân đã tải xuống Hình 3: Trình quản lý tệp hiển thị hơn 2.600 ảnh căn cước công dân đã tải xuống (ảnh chân dung, mặt trước, và mặt sau) của các thí sinh.

5. Chuỗi Tấn công Hoàn chỉnh

Dưới đây là toàn bộ chuỗi các bước, từ lần phát hiện ban đầu qua Google cho đến khi tải xuống ảnh căn cước công dân của toàn bộ 896 thí sinh. Mỗi bước đều xây dựng trên bước trước đó, và không một bước nào yêu cầu bất kỳ hình thức xác thực nào.

5.1. Tổng quan

Chuỗi tấn công kết hợp nhiều kỹ thuật để leo thang từ một kết quả Google đơn lẻ đến việc trích xuất toàn bộ PII bao gồm cả ảnh chụp CCCD:

  1. Google Dorking (Trinh sát)
  2. Phân tích Mã nguồn (Nhận dạng Framework)
  3. Dịch ngược JavaScript API (Khám phá Schema)
  4. Khai thác IDOR (Duyệt CSDL)
  5. Duyệt Khóa ngoại (Truy cập liên bảng)
  6. Trích xuất Metadata PDF (Thu thập dữ liệu làm hạt giống Seed Data)
  7. Tiêm API qua Trình duyệt Headless (Trích xuất hàng loạt) – Headless Browser là trình duyệt web chạy ở chế độ nền, không có giao diện đồ họa, cho phép điều khiển tự động hóa (ví dụ: Playwright, Puppeteer)
  8. Quét DOM (Giải quyết tham chiếu + Thu thập ảnh)
  9. Tải ảnh từ CDN (Trích xuất ảnh CCCD)

5.2. Bước 1: Google Dorking - Phát hiện Ban đầu

Một tìm kiếm Google thông thường chứa tên của một thí sinh và các từ khóa liên quan đến Trường Đại học X đã trả về một liên kết trực tiếp đến trang web Trung tâm Khảo thí:

TRUNG TAM KHAO THI TRUONG DAI HOC X
https://tec.universityx.vn/7fdc5fa41f345xxxx4bba6b0d3e449385/1518250/2368M35018
"Phieu dang ky thi nang luc ngoai ngu..."

Trang web được render hiển thị đầy đủ phiếu đăng ký thi bao gồm số CCCD, ngày sinh, dân tộc, thông tin liên hệ, và ảnh chụp thẻ CCCD.

5.3. Bước 2: Phân tích Mã nguồn - Xác định Công ty Y

Kiểm tra mã nguồn trang cho thấy:

  • JavaScript được tải từ cdn.companyy.com (Công ty Y)
  • CSS được tải từ thuctap.companyy.com
  • Lời gọi API đến xhr.companyy.com và connections.universityx.vn
  • Cấu hình Framework nằm tại tts.companyy.vn/nguyendinhhuy
  • Tên các hàm bằng tiếng Việt (xửLý, CĂN.db, config)

5.4. Bước 3: Dịch ngược Framework JavaScript API

Bằng cách sử dụng developer console của trình duyệt, tôi đã dò xét (probe) phạm vi toàn cục của framework:

> typeof xuLy       // "function" trinh xu ly API chinh
> typeof CAN.db     // "function" trinh tai co so du lieu
> typeof config     // "function" trinh lay cau hinh
> typeof duLieu     // "object"   ngu canh du lieu cua trang
> CAN               // {fn, khoa, lib, js, db, _db}

Bằng cách chặn bắt lưu lượng XHR trong tab Network khi tải một trang thí sinh, tôi đã quan sát được pattern yêu cầu/phản hồi:

POST https://xhr.companyy.com/xhr/
  Request:  {action: "doiTuong.tai.7fdc5fa4...", d: {thuocTinh: {...}}}
  Response: ["1518250", "1518251", ...]  // Danh sach ID Doi tuong

5.5. Bước 4: IDOR + Duyệt Khóa ngoại

Với các hàm API đã được xác định, tôi khai thác IDOR để duyệt cơ sở dữ liệu:

// 1. Tim bang Dang ky theo SBD (so bao danh tu file PDF)
xuLy("doiTuong.tai.7fdc5fa41f345xxxx4bba6b0d3e449385",
  {d: {thuocTinh: {"1642331": "AN1001"}}}, {}, function(ids) {
    console.log(ids);
    // ["1518250"]
  });

// 2. Tai doi tuong Dang ky -> kham pha bang Thi sinh
CAN.db("7fdc5fa41f345xxxx4bba6b0d3e449385.1518250", function() {
  var reg = config("7fdc5fa41f345xxxx4bba6b0d3e449385.1518250");
  console.log(reg["1686869"]);  // "582319" (ID Thi sinh)
  // Ma bam bang Thi sinh duoc kham pha tu moi quan he khoa ngoai
});

// 3. Tai doi tuong Thi sinh -> truy cap TOAN BO du lieu ca nhan
CAN.db("3576ff3533bb4xxxx8e394a0aa83a461f.582319", function() {
  var c = config("3576ff3533bb4xxxx8e394a0aa83a461f.582319");
  console.log(c["1646777"]);  // "0222xxxx2576" (So CCCD)
  console.log(c["1626788"]);  // "098xxxx321"   (So dien thoai)
  console.log(c["1626793"]);  // "email@example.com"
  console.log(c["1626773"]);  // {"ậ":["146992"]}  (Tham chieu dan toc)
  console.log(c["1658487"]);  // {"ị":["4296"]}     (Anh CCCD mat truoc)
  console.log(c["1658488"]);  // {"ị":["243"]}      (Anh CCCD mat sau)
});

5.6. Bước 5: Trích xuất Dữ liệu Hạt giống từ PDF

Để liệt kê tất cả các thí sinh, tôi đã trích xuất danh sách số báo danh (SBD) từ 32 tệp PDF có thể truy cập công khai. Metadata của PDF được nhúng trong HTML của trang web dưới dạng một đối tượng JSON cache với các tên trường bằng tiếng Việt viết tắt. Sau khi unescape các đường dẫn mã hóa JSON, tất cả các tệp PDF đều có thể tải xuống từ CDN tập tin tĩnh tại local.universityx.connections.vn. Kết quả: 896 SBD duy nhất được trích xuất từ 32 PDF.

5.7. Bước 6: Trích xuất Hàng loạt Tự động

Tôi đã phát triển một công cụ Python (crawl_xxxx.py) tự động hóa toàn bộ chuỗi sử dụng Playwright (trình duyệt Chromium headless):

# Moi worker chay 2 trang trinh duyet (pages):
#   api_page:    giu nguyen o /dangkythi de goi nhanh cac JS API
#   render_page: dieu huong den tung trang chi tiet cua thi sinh

def lookup_sbd(api_page, render_page, sbd):
    # Tra cuu API nhanh (~2 giay)
    reg_ids = _api_search(api_page, REG_TABLE, {F_SBD: sbd})
    reg_data = _api_load_object(api_page, REG_TABLE, reg_ids[0])
    cand_data = _api_load_object(api_page, CAND_TABLE, reg_data[F_CAND_ID])
    # -> CCCD, SDT, email, don vi cong tac luc nay da duoc lay

    # Render trang de lay cac tham chieu + hinh anh (~20 giay)
    render_page.goto(f"tec.universityx.vn/{REG_TABLE}/{reg_id}/{file_num}")
    # Cho doi thong minh (Smart wait): doi cho den khi chu "Dan toc" xuat hien
    # -> Trich xuat dan toc, noi sinh tu van ban DOM
    # -> Trich xuat URL hinh anh tu thuoc tinh background-image CSS
    # -> Tai cac anh chup CCCD tu CDN connections.vn

Bảng tính hiển thị dữ liệu thí sinh đã thu thập Hình 2: Bảng tính chứa dữ liệu thí sinh đã trích xuất bao gồm họ tên, số báo danh, số CCCD, ngày sinh, email, số điện thoại, dân tộc, và nơi sinh cho thấy quy mô của vụ lộ lọt dữ liệu.

5.8. Bước 7: Thực thi Song song với Điều chỉnh Tốc độ Thích ứng

Công cụ hỗ trợ 3 worker song song theo mặc định, mỗi worker có instance trình duyệt Playwright riêng (để đảm bảo an toàn luồng thread safety). Nếu server bắt đầu từ chối yêu cầu (3 lỗi liên tiếp), công cụ sẽ tự động lùi về sử dụng 1 worker duy nhất:

Workers: 3 (Mac dinh)
    |
    +-- Worker 1: Browser + 2 pages (api + render)
    +-- Worker 2: Browser + 2 pages (api + render)
    +-- Worker 3: Browser + 2 pages (api + render)
    |
[3 loi lien tiep tren bat ky worker nao]
    |
    v
Workers: 1 (Du phong Fallback)
    +-- Worker 1: Browser + 2 pages (api + render)

5.9. Bước 8: Xử lý Lỗi Uyển chuyển

Công cụ thực hiện nhiều cơ chế phục hồi mạnh mẽ:

  • Xử lý Ctrl+C: Khi bị ngắt, công cụ lập tức lưu tất cả dữ liệu đã thu thập vào CSV trước khi thoát.
  • Phục hồi lỗi mạng: Khi bị timeout, công cụ tự thiết lập lại phiên trình duyệt và tiếp tục.
  • Lưu định kỳ: Flush dữ liệu ra file CSV cứ sau mỗi 10 thí sinh để giảm thiểu mất mát dữ liệu.
  • Hỗ trợ tiếp tục (Resume): Khi khởi động lại, công cụ sẽ đọc tệp CSV hiện có và bỏ qua các SBD đã xử lý.
  • Cache tham chiếu: Việc tra cứu Dân tộc và Nơi sinh được lưu vào cache (chỉ có khoảng ~54 dân tộc và ~63 tỉnh ở Việt Nam), vì vậy việc render trang trở nên không cần thiết đối với các ID tham chiếu đã gặp trước đó.

6. Kết quả: Dữ liệu đã Trích xuất

6.1. Khối lượng Dữ liệu

Chỉ số Giá trị
Tổng thí sinh (từ các PDF) 896
Thí sinh có CCCD được phân giải 896 (100%)
Thí sinh có thông tin dân tộc 896 (100%)
Thí sinh có thông tin nơi sinh 896 (100%)
Ảnh CCCD đã tải xuống 2.600+ (ảnh thẻ + mặt trước + mặt sau)
Tỉ lệ thành công 100%
Worker sử dụng 3 (chạy song song)
Tốc độ xử lý ~5 thí sinh/phút (bao gồm render trang)

6.2. Các Trường Dữ liệu được Trích xuất trên mỗi Thí sinh

Trường Nguồn Mức nhạy cảm Ví dụ
SBD (số báo danh) PDF Thấp AN1001
Họ và Tên API Trung bình Nguyễn Thị xxxx Trà
Ngày sinh API + PDF Trung bình 28/09/2000
Giới tính API + PDF Thấp Nữ
Số CCCD/CMND API Nghiêm trọng 0222xxxx2576
Số điện thoại API Cao 037xxxx973
Email API Cao email@gmail.com
Nơi công tác API Trung bình Văn bản tự do
Dân tộc DOM render Cao Kinh
Nơi sinh DOM render Trung bình Tỉnh Bắc Kạn
Ảnh CCCD (mặt trước) CDN Nghiêm trọng JPEG, 44–228 KB
Ảnh CCCD (mặt sau) CDN Nghiêm trọng JPEG, 44–228 KB
Điểm số API + PDF Trung bình 8.5/6.0/5.5/7.0
Mã hồ sơ (File number) API Thấp 2368M35018

6.3. Cấu trúc Thư mục Đầu ra

output/
  candidates_phase1.csv     # 896 thi sinh (SBD, ten, ngay sinh, gioi tinh, diem)
  candidates_phase2.csv     # 896 thi sinh (+ CCCD, SDT, email, dan toc,
                            #   noi sinh, duong dan anh)
  candidates_full.csv       # Bo du lieu hoan chinh cuoi cung da hop nhat
  images/
    AN1001_front.jpg        # Anh CCCD mat truoc
    AN1001_back.jpg         # Anh CCCD mat sau
    AN1001_extra.jpg        # Anh the chan dung/anh bo sung cua thi sinh
    AN1002_front.jpg
    ...                     # Tong cong ~2.600 anh
  pdfs/                     # 32 PDF danh sach thi sinh goc
  file_index.json           # File Index Metadata cua PDF

7. Phân tích Dữ liệu Chi tiết

Phần này trình bày phân tích thống kê đối với 896 bản ghi của thí sinh được trích xuất từ tệp candidates_phase2.csv. Tất cả các số liệu thống kê đều được tính toán bằng lập trình từ dữ liệu thô.

7.1. Nhân khẩu học

  • Tổng số thí sinh: 896 cá nhân duy nhất
  • Giới tính: 661 Nữ (73.8%), 235 Nam (26.2%)
  • Độ tuổi (năm sinh): 1969–2005 (khoảng cách 37 năm)
  • Năm sinh trung vị: ≈ 2000 (phổ biến nhất: 2000 với 234 thí sinh, tiếp theo là 1998 với 117 và 1999 với 102)
  • Tỷ lệ nữ/nam là 3:1 và sự tập trung vào nhóm sinh năm 1998–2002 là hoàn toàn phù hợp với đặc thù của nhóm thí sinh thi năng lực ngoại ngữ tại một trường đại học chuyên về ngoại ngữ.

7.2. Độ hoàn thiện của Dữ liệu

Trường Có dữ liệu Bị trống % Điền
SBD (số báo danh) 896 0 100.0%
Họ và tên 896 0 100.0%
Ngày sinh 896 0 100.0%
Giới tính 896 0 100.0%
CCCD/CMND 896 0 100.0%
Số điện thoại 896 0 100.0%
Email 896 0 100.0%
Dân tộc 818 78 91.3%
Ảnh CCCD (mặt trước) 820 76 91.5%
Ảnh CCCD (mặt sau) 816 80 91.1%
Nơi sinh/Tỉnh thành 576 320 64.3%
Nơi công tác 135 761 15.1%

7 trường thông tin cá nhân (PII) cốt lõi (họ tên, ngày sinh, giới tính, CCCD, số điện thoại, email, mã hồ sơ) đều có tỷ lệ điền 100%. Tỷ lệ điền thông tin nơi công tác thấp (15.1%) cho thấy hầu hết thí sinh là sinh viên nên đã bỏ trống trường không bắt buộc này.

7.3. Phân tích Tên miền Email

Tên miền Số lượng %
gmail.com 766 85.5%
s.universityx.edu.vn 87 9.7%
universityx.edu.vn 22 2.5%
yahoo.com / yahoo.com.vn 4 0.4%
gmail.con (lỗi gõ phím) 3 0.3%
Khác (.edu.vn, .gov.vn) 14 1.6%

3 trường hợp gõ sai thành gmail.con và 87 sinh viên sử dụng MSSV làm tiền tố cho email Trường Đại học X ({mssv}@s.universityx.edu.vn) là những điểm đáng chú ý: các lỗi chính tả xác nhận đây là dữ liệu thật do người dùng tự nhập, trong khi mẫu email kia lại vô tình tạo ra một kênh thứ hai làm lộ số MSSV.

7.4. Phân tích Định dạng CCCD/CMND

Việt Nam đã phát hành tài liệu định danh dưới ba định dạng, tất cả đều xuất hiện trong tập dữ liệu này:

Định dạng Số lượng % Mô tả
CCCD 12 số 474 52.9% Thẻ Căn cước công dân mới (sau 2021)
CMND 10 số 271 30.2% Chứng minh nhân dân cũ (10 số)
CMND 9 số 135 15.1% Chứng minh nhân dân cũ (9 số)
Độ dài khác 16 1.8% Mã số sinh viên/Số hộ chiếu/Lỗi nhập liệu

Phát hiện 6 số CCCD bị trùng lặp (mỗi số xuất hiện trong 2 lượt đăng ký), cho thấy có những thí sinh đã đăng ký thi nhiều lần. Điều này xác nhận rằng đây là các hồ sơ đăng ký thực tế, trải dài xuyên suốt trong giai đoạn từ tháng 9/2024 đến tháng 2/2026.

7.5. Phân bố Địa lý

3 chữ số đầu tiên của một CCCD 12 số mã hóa cho tỉnh thành nơi cấp. Trong số 474 CCCD định dạng mới:

Mã Tỉnh/Thành phố Số lượng %
001 Hà Nội 144 30.4%
036 Nam Định 38 8.0%
038 Thanh Hoá 36 7.6%
034 Thái Bình 31 6.5%
030 Hải Dương 25 5.3%
024 Bắc Giang 23 4.9%
035 Hà Nam 16 3.4%
033 Hưng Yên 16 3.4%
027 Bắc Ninh 15 3.2%
037 Ninh Bình 15 3.2%

Sự phân bố tập trung rất cao ở khu vực Đồng bằng sông Hồng tại miền Bắc Việt Nam, phù hợp với vị trí của Trường Đại học X tại Hà Nội. Riêng các thí sinh đến từ Hà Nội đã chiếm 30.4% tổng số người sở hữu CCCD mẫu mới.

7.6. Thống kê Kho Dữ liệu Ảnh

Loại ảnh Số lượng Mô tả
*_front.jpg 820 Ảnh chụp mặt trước CCCD/CMND
*_back.jpg 816 Ảnh chụp mặt sau CCCD/CMND
*_extra.jpg 813 Ảnh thẻ chân dung của thí sinh
Tổng cộng 2.449 223 MB trên ổ cứng

Khoảng 76–80 thí sinh bị thiếu ảnh rất có thể đã đăng ký từ trước khi quy định bắt buộc tải lên ảnh CCCD được áp dụng, hoặc họ đã tải lên các tài liệu ở định dạng không chuẩn khiến công cụ quét DOM không thể trích xuất được.

7.7. Phân tích Nguồn PDF

Thời gian Số PDF Loại kỳ thi
Tháng 9/2024 4 C1 Tiếng Anh, Trung, Nhật, Hàn
Tháng 3/2025 4 C1 Tiếng Anh, Trung, Nhật, Hàn
Tháng 5/2025 1 Bài thi Trường Đại học X Test
Tháng 6/2025 6 NN2 SĐH (Ngoại ngữ 2 - Sau đại học)
Tháng 10/2025 4 Tiếng Anh, Trung, Nhật, Hàn
Tháng 1/2026 9 Các ca thi Sáng/Chiều (nhiều ngày)
Tháng 2/2026 4 Các ca thi Sáng/Chiều
Tổng cộng 32 Giai đoạn: T9/2024 – T2/2026

8. Phân tích Nguyên nhân Gốc rễ

8.1. Lỗi Kiến trúc trong Nền tảng Connections

Việc lộ dữ liệu bắt nguồn từ những quyết định thiết kế kiến trúc cơ bản trong nền tảng Connections của Công ty Y:

  1. Không có Tầng Xác thực API: Các điểm cuối API XHR tại xhr.companyy.com và connections.universityx.vn chấp nhận yêu cầu từ bất kỳ ngữ cảnh thực thi JavaScript nào. Không có token, cookie phiên, hay kiểm tra API key nào.

  2. Không có Kiểm soát Truy cập Cấp trường: API trả về toàn bộ các trường cho bất kỳ đối tượng nào được yêu cầu. Một người dùng truy cập trang công khai để xem lịch thi sẽ nhận được toàn bộ dữ liệu giống hệt như một quản trị viên đang xem số CCCD và ảnh thẻ căn cước.

  3. Lỗi IDOR do Thiết kế: ID đối tượng cơ sở dữ liệu được sử dụng trực tiếp trong URL và lời gọi API. Các mã băm bảng (table hashes) đóng vai trò định danh không cung cấp bảo mật chúng lộ rành rành trên URL và có thể khám phá dễ dàng thông qua việc duyệt khóa ngoại.

  4. Chỉ Bảo mật ở Phía Client: Toàn bộ logic nghiệp vụ và bộ lọc dữ liệu xảy ra tại JavaScript trên trình duyệt. Máy chủ đóng vai trò như một kho dữ liệu trong suốt, không thực thi bất kỳ kiểm soát truy cập nào.

  5. Không có Kiểm soát trên CDN: Cả CDN chứa tệp tĩnh và CDN chứa hình ảnh đều phân phối nội dung mà không cần xác thực. Khi một URL được biết (hoặc trích xuất từ trang đã render), bất kỳ HTTP client nào cũng có thể tải tệp xuống.

  6. Không có Rate Limiting: API chấp nhận hàng trăm truy vấn tuần tự từ một client duy nhất mà không bị “bóp băng thông” (throttling), cho phép trích xuất dữ liệu hàng loạt dễ dàng.

8.2. Rủi ro Nhà cung cấp Bên Thứ Ba

Trường Đại học X đã giao phó dữ liệu nhạy cảm của thí sinh bao gồm các bức ảnh thẻ CCCD/CMND do nhà nước cấp cho nền tảng Connections của Công ty Y. Điều này tạo ra một lỗ hổng chuỗi cung ứng (supply chain vulnerability):

  • Trường Đại học X có thể không hề hay biết nền tảng này hoàn toàn không có kiểm soát truy cập.
  • Cùng một lỗi kiến trúc này khả năng cao sẽ ảnh hưởng tới tất cả các tổ chức đang sử dụng nền tảng Connections, không riêng gì Trường Đại học X.
  • Trường Đại học X bị giới hạn khả năng tự triển khai các biện pháp kiểm soát bảo mật trên một hạ tầng không do họ vận hành.
  • Mối quan hệ với nhà cung cấp đồng nghĩa với việc để khắc phục lỗ hổng này, Công ty Y phải thiết kế lại kiến trúc nền tảng của họ.

8.3. Tại sao Mã hóa trên Image CDN Không phải là Bảo mật

Image CDN sử dụng các đường dẫn URL được mã hóa (ví dụ: kt3PG1hPTgTPG1MJ.u54.L8J...), điều này bề ngoài có vẻ là để cung cấp tính năng bảo mật. Tuy nhiên:

  • Quá trình mã hóa được thực hiện bởi client-side JavaScript, thứ mà người dùng hoàn toàn kiểm soát được.
  • Các URL đã mã hóa được nhúng trực tiếp dưới dạng thuộc tính background-image của CSS trong DOM, cực kỳ dễ trích xuất.
  • Sau khi trích xuất, các URL này không yêu cầu cookie, token, hoặc header nào để tải hình ảnh.
  • Bất kỳ trình duyệt headless nào cũng có thể render trang của thí sinh và tự động thu thập toàn bộ các URL hình ảnh đó.

9. Đánh giá Tác động

Dữ liệu bị lộ trong lỗ hổng này không chỉ là những con số “PII” trừu tượng trên giấy. Đối với 896 con người thực, đây là tất cả những gì cần thiết để đánh cắp danh tính của họ. Tại Việt Nam, ảnh CCCD được sử dụng rộng rãi để xác minh KYC (Know Your Customer - Xác minh khách hàng) tại các ngân hàng, ví điện tử như MoMo và ZaloPay, và các nhà mạng viễn thông. Một bức ảnh CCCD bị lộ về bản chất là chìa khóa vạn năng mở cửa vào đời sống tài chính của một người. Phần tiếp theo đánh giá hậu quả thực tế đối với những sinh viên và người lao động mà dữ liệu của họ đã bị phơi bày.

9.1. Đối tượng Bị ảnh hưởng

  • 896 thí sinh duy nhất đã được xác nhận từ các kỳ thi năm 2024.
  • Cơ sở dữ liệu rất có thể chứa danh sách thí sinh từ tất cả các kỳ thi trong lịch sử, có khả năng lên đến hàng nghìn người.
  • Tất cả các thí sinh đều có toàn bộ hồ sơ PII và ảnh chụp thẻ CCCD bị truy cập được mà không cần xác thực.

9.2. Mức độ Nghiêm trọng: Sự Lộ lọt Hình ảnh thẻ CCCD

Việc lộ lọt ảnh chụp thẻ CCCD/CMND nghiêm trọng hơn rất nhiều so với việc lộ thông tin cá nhân dưới dạng văn bản:

  • Dữ liệu Sinh trắc học (Biometric data): Hình ảnh chứa khuôn mặt của chủ thẻ, thứ có thể bị sử dụng cho các cuộc tấn công nhận diện khuôn mặt.
  • Sao chép Thẻ (Physical card replication): Hình ảnh chất lượng cao của cả mặt trước và mặt sau cung cấp toàn bộ thông tin cần thiết để tạo ra thẻ căn cước giả.
  • Qua mặt KYC (KYC bypass): Nhiều dịch vụ tài chính tại Việt Nam chấp nhận ảnh chụp thẻ CCCD cho quy trình xác minh KYC (Know Your Customer) - những bức ảnh này có thể bị lợi dụng để mở tài khoản ngân hàng hoặc ví điện tử lừa đảo.
  • Sự không thể hoàn tác (Irreversibility): Khác với mật khẩu hoặc số điện thoại, một số thẻ CCCD và hình ảnh trên thẻ khi đã bị lộ thì không thể nào “đổi” được - hậu quả của nó là vĩnh viễn.

9.3. Các Kịch bản Rủi ro

  1. Trộm cắp Danh tính Quy mô Lớn: Số thẻ CCCD + Hình ảnh + Tên đầy đủ + Ngày sinh = một bộ hồ sơ danh tính hoàn chỉnh cho 896 cá nhân.
  2. Gian lận Tài chính: Ảnh thẻ CCCD có thể qua mặt hệ thống KYC tại các ngân hàng, ví điện tử (MoMo, ZaloPay, VNPay) và các sàn giao dịch tiền mã hóa.
  3. Tấn công Tráo SIM (SIM Swap): Số điện thoại + Ảnh thẻ CCCD cho phép kẻ xấu thực hiện tấn công SIM swap với các nhà mạng, dẫn đến việc chiếm quyền điều khiển tài khoản (account takeovers).
  4. Tạo Deepfake: Hình ảnh khuôn mặt trích xuất từ CCCD, kết hợp với họ tên và thông tin tiểu sử, cho phép tạo ra các nội dung deepfake bằng AI phục vụ cho kỹ thuật phi kỹ thuật (social engineering).
  5. Lừa đảo Nhắm mục tiêu (Targeted Phishing): Một bộ hồ sơ trọn vẹn (Tên, Email, Điện thoại, Nơi công tác, Lịch sử thi) cho phép tạo ra các chiến dịch lừa đảo spear-phishing cực kỳ tinh vi và thuyết phục.
  6. Vi phạm Pháp luật & Chế tài: Chiếu theo Nghị định 13/2023/NĐ-CP về Bảo vệ dữ liệu cá nhân của Việt Nam, việc làm lộ thông tin căn cước công dân và hình ảnh sinh trắc học cấu thành vi phạm nghiêm trọng và có khả năng bị xử phạt.

9.4. Xếp hạng Mức độ Nghiêm trọng

Yếu tố Đánh giá
Độ Phức tạp của Tấn công Thấp (Console trình duyệt + Script Python cơ bản)
Yêu cầu Xác thực Không có
Độ Nhạy cảm của Dữ liệu Cực kỳ Nghiêm trọng (ID quốc gia + ảnh)
Số lượng Người dùng bị ảnh hưởng Hơn 896 người đã xác nhận, tiềm năng lên tới hàng nghìn
Khả năng Hoàn tác Dữ liệu Không thể đảo ngược (Không thể thay CCCD)
Mức độ Khai thác Dễ dàng (Không cần các công cụ chuyên dụng)
Phạm vi Nhà cung cấp Toàn bộ khách hàng dùng chung nền tảng Connections
Đánh giá Tổng thể Mức Critical - Cực kỳ Nghiêm trọng (CVSS 9.1+)

10. Các Thách thức Kỹ thuật và Giải pháp

10.1. Render Nội dung Động

Trang web render tất cả dữ liệu phía client bằng JavaScript. Các request HTTP chuẩn (như curl hoặc requests trong Python) chỉ lấy về được bộ khung HTML trống.

Giải pháp: Sử dụng Playwright với trình duyệt Chromium headless để thực thi framework JavaScript, cho phép thực hiện cả việc gọi API và trích xuất DOM.

10.2. Mã nguồn Tiếng Việt

Framework sử dụng các định danh tiếng Việt có dấu: xửLý, dữLiệu, thuộcTính, đốiTượng. Mặc dù đây không phải là một cách che giấu mã (obfuscation) có chủ ý, nó đòi hỏi các công cụ hỗ trợ Unicode và khiến việc pattern-matching (khớp chuỗi) khó khăn hơn đáng kể so với việc phân tích JavaScript thông thường.

10.3. Giải quyết Trường Tham chiếu

Các trường Dân tộc và Nơi sinh lưu trữ các ID tham chiếu ẩn (VD: {"ậ":["146992"]}) thay vì văn bản. Những tham chiếu này chỉ được giải quyết trong quá trình render trang bởi logic nội bộ của framework nếu gọi trực tiếp các API (CĂN.db, config, thuộcTính.tải), kết quả trả về cho các ID này luôn là null.

Giải pháp: Render toàn bộ trang của từng thí sinh và trích xuất các văn bản đã được giải quyết từ DOM (VD: “4. Dân tộc: Kinh”). Tôi đã cache lại các giá trị này để tránh phải render lại trang nhiều lần.

10.4. Mã hóa URL Ảnh

Ảnh chụp CCCD được phân phối từ Image CDN với các đường dẫn URL đã được mã hóa, không thể tự xây dựng chỉ từ ID file – framework sinh ra chúng lúc runtime.

Giải pháp: Render trang của mỗi thí sinh, trích xuất URL từ thuộc tính background-image trong CSS từ các thẻ <div> đang trỏ về connections.vn, sau đó tải ảnh xuống qua HTTP GET.

10.5. Xử lý Song song và An toàn Luồng

API đồng bộ của Playwright không đảm bảo an toàn luồng (thread-safe) trên các instance trình duyệt dùng chung.

Giải pháp: Mỗi worker thread sẽ tự khởi chạy instance trình duyệt Playwright riêng của nó, với 2 trang (page) riêng biệt cho mỗi trình duyệt (một trang gọi API, một trang để render). Các worker được khởi động cách nhau 3 giây (staggered) để tránh hiện tượng “thundering herd” khi thiết lập session.

10.6. Khả năng Phục hồi Mạng

Server của Trường Đại học X thường xuyên gặp tình trạng tải trang rất chậm (có khi mất hơn 30 giây).

Giải pháp: Sử dụng thuật toán chờ thông minh (smart wait polling text trên DOM thay vì chờ timeout cố định), tự động thiết lập lại session khi thất bại, liên tục lưu CSV định kỳ sau mỗi 10 thí sinh, và tích hợp xử lý Ctrl+C để lưu toàn bộ dữ liệu đang thu thập trước khi ngắt ứng dụng.

11. Khuyến nghị

11.1. Dành cho Trường Đại học X (Khắc phục Ngay lập tức)

  1. Kiểm toán bảo mật phía Nhà cung cấp: Yêu cầu Công ty Y tiến hành đánh giá bảo mật tổng thể nền tảng Connections.
  2. Gỡ bỏ ảnh chụp thẻ CCCD: Xóa toàn bộ hình ảnh thẻ CCCD đã lưu trữ khỏi nền tảng hoặc chuyển chúng sang hệ thống lưu trữ có kiểm soát truy cập nghiêm ngặt.
  3. Bổ sung robots.txt / noindex: Ngăn chặn các bộ máy tìm kiếm (search engine) lập chỉ mục các trang chi tiết của thí sinh; yêu cầu Google xóa bỏ (remove) các trang hiện đã bị lưu cache.
  4. Hạn chế quyền truy cập file PDF: Ẩn các danh sách thí sinh sau bước xác thực hoặc che mờ (redact) các cột chứa thông tin nhạy cảm.
  5. Đánh giá các giải pháp nền tảng thay thế: Cân nhắc chuyển đổi sang một nền tảng khác có đầy đủ các biện pháp kiểm soát truy cập (Access control).

11.2. Dành cho Công ty Y / Nền tảng Connections (Khắc phục Cấp thiết)

  1. Triển khai xác thực API: Mọi điểm cuối XHR đều phải yêu cầu một token phiên (session token) hợp lệ kết hợp với phân quyền kiểm soát truy cập theo vai trò (Role-based access).
  2. Thêm Kiểm soát Truy cập Cấp trường: Các trường dữ liệu nhạy cảm (CCCD, Số điện thoại, tham chiếu File) phải bị giới hạn, chỉ các phiên đăng nhập quyền quản trị (admin) mới được truy cập.
  3. Bảo mật Image CDN: Các URL hình ảnh phải yêu cầu kèm theo token xác thực và phải được xác thực ở phía máy chủ (server-side), không thể chỉ dựa vào việc mã hóa đường dẫn.
  4. Render Server-side cho dữ liệu nhạy cảm: Dịch chuyển logic hiển thị PII lên xử lý phía server; tuyệt đối không gửi dữ liệu nhạy cảm thô ra ngoài ngữ cảnh các trang web công cộng.
  5. Giới hạn tốc độ và Phát hiện Hành vi bất thường: Triển khai giới hạn truy vấn (Rate Limit) dựa trên IP và hệ thống cảnh báo khi phát hiện các mẫu tải hàng loạt.
  6. Kiểm toán Bảo mật toàn bộ khách hàng: Những lỗ hổng tương tự khả năng rất cao đang ảnh hưởng tới toàn bộ các tổ chức sử dụng nền tảng Connections.

11.3. Kế hoạch Dài hạn

  1. Rà soát tính tuân thủ quy định (Compliance): Đánh giá khả năng tuân thủ của hệ thống theo Nghị định 13/2023/NĐ-CP về Bảo vệ dữ liệu cá nhân của Việt Nam.
  2. Chương trình Kiểm thử Xâm nhập (Pentest): Thiết lập kế hoạch kiểm thử bảo mật định kỳ cho hệ thống.
  3. Tối thiểu hóa Dữ liệu (Data Minimization): Xem xét lại việc có cần thiết phải lưu giữ ảnh thẻ CCCD của công dân sau khi quy trình đối chiếu danh tính ban đầu đã hoàn tất hay không.
  4. Phản ứng Sự cố (Incident Response): Thông báo cho các thí sinh bị ảnh hưởng về vụ việc lộ lọt dữ liệu đúng theo các yêu cầu của pháp luật.

12. Kết luận

Điều bắt đầu từ một cú tìm kiếm Google bình thường đã dẫn đến một phát hiện đáng lo ngại: toàn bộ thí sinh dự thi của một trường đại học đã bị phơi bày những dữ liệu cá nhân nhạy cảm nhất – bao gồm cả ảnh chụp căn cước công dân – ra trên internet mở. 896 người đăng ký thi năng lực ngoại ngữ với niềm tin rằng thông tin của họ sẽ được bảo quản an toàn. Thay vào đó, toàn bộ hồ sơ danh tính của họ có thể bị truy cập bởi bất kỳ ai có trình duyệt web.

Nguyên nhân gốc rễ không phải là một lỗi code đơn lẻ hay một sai sót cấu hình. Đây là một thất bại kiến trúc cơ bản: nhà cung cấp phần mềm đã xây dựng một hệ thống mà cơ sở dữ liệu không có ổ khóa trên cánh cửa. Nền tảng Connections đối xử với mọi người truy cập dù là sinh viên kiểm tra kết quả thi hay một người lạ trên internet đều như có quyền truy cập đầy đủ vào mọi bản ghi, mọi trường dữ liệu, và mọi tập tin đã tải lên. Không có tầng xác thực, không có kiểm soát truy cập, không có sự phân biệt giữa dữ liệu công khai và dữ liệu riêng tư.

Các phát hiện này mang đến 3 bài học sống còn:

  1. Rủi ro từ nhà cung cấp bên thứ ba là hoàn toàn có thật: Thuê ngoài phần mềm không có nghĩa là thuê ngoài trách nhiệm. Mọi tổ chức giao phó dữ liệu nhạy cảm cho một nền tảng SaaS phải kiểm toán kiến trúc bảo mật của nền tảng đó, chứ không chỉ đánh giá tính năng phần mềm.
  2. Bảo mật phía client không phải là bảo mật: Nếu thứ duy nhất đứng giữa kẻ tấn công và cơ sở dữ liệu là JavaScript chạy trên chính trình duyệt của họ, thì bạn không có bảo mật gì cả. Kiểm soát truy cập bắt buộc phải được thực thi ở phía máy chủ.
  3. Bảo mật bằng sự che đậy luôn thất bại: Các URL mã hóa, code bị làm rối (minified), và chuỗi ID dạng hash có thể làm chậm kẻ tấn công vài phút, nhưng không bao giờ thay thế được cơ chế xác thực thực sự.

Đối với 896 thí sinh, thiệt hại đã xảy ra. Số CCCD, ảnh chụp căn cước, thông tin cá nhân của họ – đó là những dữ liệu không bao giờ có thể thu hồi lại được.

13. Cập nhật kiểm tra lại – Ngày 23 tháng 6, 2026

Ngày 23 tháng 6 năm 2026, tôi quay lại kiểm tra toàn bộ các vector tấn công trên tec.universityx.vn. Công ty Y đã cập nhật mã nguồn ngay trong ngày đó (phiên bản 14484523062026). Kết quả cho thấy tiến bộ thực sự, nhưng chưa hoàn chỉnh.

Những gì đã thay đổi

Bản sửa quan trọng nhất nằm ở tầng cổng API: các endpoint XHR giờ đã thực thi xác thực phía server. Cả connections.universityx.vn/xhr/ lẫn xhr.companyy.com/xhr/ đều trả về HTTP 403 với {"error":403,"code":"access_denied"} cho các yêu cầu POST không xác thực. Đây là lần đầu tiên tôi thấy kiểm soát truy cập phía server xuất hiện trên nền tảng này.

Ngoài ra:

  • Truy cập bảng tài khoản (taiKhoan) đã bị chặn. Lỗ hổng IDOR cấp tài khoản được ghi nhận trong báo cáo này không còn hoạt động; toàn bộ ID tài khoản được kiểm tra đều trả về null.
  • Mật mã b6x đã bị gỡ bỏ. Lớp mật mã thay thế đơn bảng được thêm vào như một “bản vá” sau lần công bố đầu tiên đã biến mất hoàn toàn. Dữ liệu còn lại được trả về dạng văn bản thuần thay vì bọc trong một lớp mã hóa hỏng.

Những gì vẫn còn lỗ hổng

Khác với nền tảng mạng nội bộ được ghi nhận trong Phần 2, hệ thống thi vẫn còn nhiều lỗ hổng:

Dữ liệu thí sinh vẫn bị lộ một phần. Ít nhất một bản ghi thí sinh (#1662402) vẫn trả về dữ liệu qua API. Lớp b6x đã biến mất, nhưng bốn trường vẫn còn trong phản hồi thô:

Trường Giá trị Trạng thái
Ngày sinh 10/12/1998 VẪN BỊ LỘ
Giới tính 2 VẪN BỊ LỘ
Tham chiếu ảnh CCCD mặt trước {"i":["4296"]} VẪN BỊ LỘ
Tham chiếu ảnh CCCD mặt sau {"i":["243"]} VẪN BỊ LỘ
Họ tên – ĐÃ XÓA
Số điện thoại – ĐÃ XÓA
Email – ĐÃ XÓA
Số CCCD – ĐÃ XÓA

Các trường văn bản nhạy cảm nhất (họ tên, số điện thoại, email, số CCCD) đã được xóa sạch. Nhưng ngày sinh và ID tham chiếu ảnh vẫn còn.

Liệt kê ID hàng loạt vẫn hoạt động. Endpoint tải hàng loạt trả về 50.403 ID thí sinh. Dù hầu hết bản ghi có vẻ đã trống hoặc bị xóa, bản thân việc liệt kê này không nên khả thi với người dùng không xác thực.

Truy cập ảnh CDN đã bị hồi quy. Các node CDN ảnh tại i0.connections.vn và i3.connections.vn đang phản hồi HTTP 200 trở lại. Chúng đã được đánh dấu là “đã sửa” trong lần kiểm tra ngày 10 tháng 3, nghĩa là đây là hồi quy chứ không phải lỗ hổng tồn đọng. Nếu các ID tham chiếu ảnh từ bản ghi thí sinh vẫn có thể được phân giải thành URL trên CDN, thì ảnh chụp thẻ căn cước được ghi nhận trong báo cáo này có thể vẫn tải xuống được.

Bảng điểm

Nền tảng Kiểm tra Đã sửa Còn lỗ hổng Điểm
tec.universityx.vn (báo cáo này) 13 6 5 46% đã sửa
connections.universityx.vn (Phần 2) 13 11 2 85% đã sửa
Trước đó (10 tháng 3, cả hai) 10 3 7 30% đã sửa

Đánh giá

Nhà cung cấp đã có tiến bộ thực sự. Cổng xác thực XHR là bản sửa kiến trúc đúng hướng, và việc gỡ bỏ mật mã b6x để thay bằng xóa sạch các trường nhạy cảm là cách tiếp cận tốt hơn nhiều so với che giấu. Hướng đi đang đúng.

Nhưng với nền tảng thi cụ thể này, công việc chưa xong. Sự hồi quy của CDN ảnh đáng lo ngại vì nó đảo ngược một bản sửa đã được xác nhận trước đó. Dữ liệu thí sinh còn sót lại, dù chỉ một phần, kết hợp với ID tham chiếu ảnh, có nghĩa là phát hiện cốt lõi của báo cáo này (lộ ảnh thẻ căn cước) có thể chưa được giải quyết triệt để. Và 50.403 ID thí sinh có thể liệt kê là một tập dữ liệu lớn hơn nhiều so với 896 thí sinh tôi ghi nhận ở đây, cho thấy phạm vi phơi bày có thể rộng hơn đánh giá ban đầu.

Bước tiếp theo cần xác minh là liệu các ID tham chiếu ảnh bị lộ có thể phân giải thành ảnh tải xuống được trên CDN hay không. Nếu có, phát hiện nghiêm trọng nhất trong báo cáo này vẫn còn khai thác được dù đã qua bốn tháng khắc phục.

Phụ lục

A. Các Công cụ Sử dụng

Công cụ Phiên bản Mục đích sử dụng
Python 3.12 Môi trường chạy script chính
requests Mới nhất Giao thức HTTP để tải ảnh và PDF
pdfplumber Mới nhất Trích xuất các bảng dữ liệu từ PDF
Playwright Mới nhất Trình duyệt headless (Thực thi JS + Quét DOM)
Chromium (Tích hợp) Engine trình duyệt dùng để render các trang

B. Mốc thời gian Công bố

Ngày / Giờ Sự kiện
25/02/2026 13:00 Phát hiện lỗ hổng qua hệ thống lập chỉ mục tìm kiếm Google
25/02/2026 15:30 Dịch ngược hoàn thành Framework; Lập bản đồ Schema CSDL
25/02/2026 17:00 Xác nhận khai thác API thành công; Truy cập được dữ liệu CCCD
25/02/2026 19:30 Phân tích thành công CDN hình ảnh; Tải xuống được các ảnh thẻ CCCD
25/02/2026 20:00 Bắt đầu phát triển công cụ tự động hóa
25/02/2026 21:00 Giai đoạn 1 hoàn tất: Trích xuất 896 SBD từ 32 tập PDF
26/02/2026 01:30 Giai đoạn 2 bắt đầu: Chạy song song API crawl (3 workers)
26/02/2026 04:30 Giai đoạn 2 hoàn tất: Xử lý thành công 896/896 hồ sơ
26/02/2026 09:00 Hoàn tất gộp dữ liệu: 2.449 hình ảnh, tổng dung lượng 223 MB
26/02/2026 13:00 Hoàn thiện báo cáo kỹ thuật
24/03/2026 Công bố báo cáo
13/06/2026 Phần 2 được công bố
23/06/2026 Kiểm tra lại: 46% đã sửa trên tec.universityx.vn, 85% trên connections.universityx.vn

C. Thuật ngữ (Glossary)

Thuật ngữ Định nghĩa
CCCD Căn cước công dân - Thẻ Căn cước mới
CMND Chứng minh nhân dân - Thẻ Chứng minh thư (mẫu cũ)
Trường Đại học X Tên giả cho trường đại học bị ảnh hưởng
SBD Số báo danh - Số thứ tự làm bài thi
VSTEP Vietnamese Standardized Test of English Proficiency
IDOR Insecure Direct Object Reference - Tham chiếu đối tượng trực tiếp không an toàn
SaaS Software as a Service - Phần mềm dạng dịch vụ
CDN Content Delivery Network - Mạng phân phối nội dung (Tệp tin tĩnh, hình ảnh)
PII Personally Identifiable Information - Thông tin định danh cá nhân
KYC Know Your Customer - Quy trình xác minh khách hàng (Của các ngân hàng/Ví)
Công ty Y Tên giả cho công ty cung cấp và vận hành nền tảng Connections

D. Mẫu Bản ghi Dữ liệu

Dưới đây là hai bản ghi tiêu biểu được trích xuất từ tập dữ liệu, trong đó các thông tin nhận dạng cá nhân thực tế đã được che mờ (redacted):

// Ban ghi Mau 1 (Da che mo)
{
  "sbd": "AN1***",
  "ho_ten": "[REDACTED]",
  "ngay_sinh": "28/09/2000",
  "gioi_tinh": "Nu",
  "cccd": "022XXXXXXXXX",
  "sdt": "037XXXXXXX",
  "email": "[redacted]@gmail.com",
  "don_vi": "",
  "dan_toc": "Kinh",
  "noi_sinh": "Tinh Bac Ninh",
  "img_front": "output/images/AN1***_front.jpg",
  "img_back": "output/images/AN1***_back.jpg"
}

// Ban ghi Mau 2 (Da che mo)
{
  "sbd": "TQ1***",
  "ho_ten": "[REDACTED]",
  "ngay_sinh": "03/07/2000",
  "gioi_tinh": "Nu",
  "cccd": "180XXXXXXXXX",
  "sdt": "036XXXXXXX",
  "email": "180XXXXXXXX@s.universityx.edu.vn",
  "don_vi": "",
  "dan_toc": "Kinh",
  "noi_sinh": "",
  "img_front": "output/images/TQ1***_front.jpg",
  "img_back": "output/images/TQ1***_back.jpg"
}

Các điểm đáng chú ý:

  • Số CCCD được lưu trữ dưới dạng văn bản thuần túy (có dấu nháy đơn phía trước chỉ để định dạng cho tệp CSV).
  • Các tệp hình ảnh là những bức ảnh chụp thẻ căn cước vật lý ở định dạng JPEG tiêu chuẩn.
  • Trường don_vi (nơi công tác) có tỷ lệ điền rất thấp (15.1%), cho thấy phần lớn thí sinh là sinh viên chưa đi làm.

E. Các bước Tái tạo

  1. Bước 1 Tải xuống các file PDF danh sách thí sinh được công bố công khai từ CDN file tĩnh và phân tích bảng thí sinh để trích xuất số báo danh (SBD).
  2. Bước 2 Với mỗi SBD, truy vấn các điểm cuối API JavaScript không yêu cầu xác thực để lấy toàn bộ hồ sơ thí sinh bao gồm số CCCD và thông tin cá nhân.
  3. Bước 3 Giải mã các trường tham chiếu ảnh từ phản hồi API thành URL ảnh trên CDN, sau đó tải xuống ảnh CCCD tương ứng.
  4. Bước 4 Gộp dữ liệu trích xuất từ PDF và dữ liệu trích xuất từ API thông qua SBD làm khóa chính để tạo bộ dữ liệu hoàn chỉnh.

Phần 2 sẽ đi sâu vào việc vì sao từ lỗ hổng nhỏ của Trung tâm Khảo thí lại có thể gây ảnh hưởng đến cả hệ thống lớn của Trường.

Lưu ý: Mã nguồn và công cụ tái tạo chi tiết đã được giữ lại và không công bố trong báo cáo này để tránh bị lạm dụng. Toàn bộ chi tiết kỹ thuật đã được chia sẻ với các bên liên quan trong quá trình tiết lộ có trách nhiệm.