Update (June 23, 2026): Core vulnerability remediated

Company Y has deployed server-side authentication on the XHR API gateway. Account IDOR and password exposure on this platform are no longer exploitable. See revalidation details below.

CVSS 3.1: 9.8 (CRITICAL)

Mass credential exposure + account takeover via unauthenticated API.

Summary

Part 1 ended with 896 exam candidates’ personal data and national ID card photos exposed through University X’s Testing Center – all built on Company Y’s “Connections” platform. I closed that report with a question I could not shake: if the exam system had zero access controls, what about the university’s main platform running on the exact same infrastructure?

I went looking. The answer was far worse than I imagined.

University X operates connections.universityx.vn – its central in-house network, also built on Company Y’s Connections SaaS. This is not a side portal. It is the platform that holds every student, every alumnus, every staff member, every faculty – the university’s entire digital population in one place. Using the same techniques from Part 1 – unauthenticated API calls and sequential ID enumeration – I extracted 80,053 user accounts. Each one contained up to 40 fields of personal data.

But the number was not what kept me up that night. It was the password field. The API returned staff credentials – some in plaintext, others masked with a trivial algorithm that could be reversed using data from the same API response. Of 554 accounts with exposed passwords, I obtained 208 usable credentials – 50 read directly in plaintext, 158 recovered offline – without a single login attempt.

To prove the severity, I logged into a Vice Rector’s account. No bruteforce. No exploit. I read a field and typed it into the login form. That was it.

1. Introduction

1.1. Recap: Part 1

If you haven’t read Part 1, here’s the short version. I investigated tec.universityx.vn, the Testing Center’s exam registration system, and found:

• 896 candidates’ PII extracted via unauthenticated API
• CCCD numbers and ID card photos accessible to any visitor
• Root cause: Company Y’s Connections platform enforces zero server-side authentication

The platform’s architecture was the problem – not a single misconfigured endpoint. Every table, every field, every uploaded file was accessible to anyone who knew (or guessed) the right object ID.

1.2. The Natural Next Question

The Testing Center was a relatively small deployment: a few hundred candidates per exam cycle. But University X’s presence on the Connections platform extended far beyond exams.

The university also operates connections.universityx.vn – its central in-house network, holding accounts for every student, staff member, and faculty across the entire institution. Same vendor. Same JavaScript framework. Same cdn.companyy.com scripts. Same architecture.

If the exam system leaked data for 896 people, what would the main university network expose?

I had to find out.

1.3. Scope and Ethics

The same ethical principles from Part 1 apply:

• All data access used publicly available, unauthenticated endpoints.
• No authentication was bypassed – because none existed.
• No data was modified, deleted, or shared with third parties.
• No brute-force attacks were performed. Password recovery was done offline using data already exposed by the same API.
• Account takeover was performed once, solely to confirm the vulnerability’s severity, and the session was immediately terminated.

2. A Bigger Target: The University Network

2.1. Platform Discovery

I opened connections.universityx.vn in my browser and looked at the source. There it was – the identical JavaScript framework loading from the same CDN:

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

The same internal API functions were available: CAN.db() for database queries, config() for reading cached responses, and xửLý() for search operations. The only difference was the data – instead of exam candidates, this platform manages the university’s entire user base.

I already knew this architecture had no locks on the door. Now I just needed to see how much was behind it.

2.2. Mapping the Account Space

I used the same enumeration technique from Part 1 – iterating through sequential account IDs via CAN.db(). An initial probe estimated the active range at 7,787–97,744 (89,958 potential IDs). But as the crawl ran, accounts kept appearing well beyond that estimate:

Over 200,000 potential IDs probed. 80,053 returned complete user records. Every single one – accessible without authentication.

That number hit differently than 896. This was not a corner of the university. This was the entire university.

3. The Crawl: 80,053 Accounts

3.1. Extraction Method

The technique was identical to Part 1. For each account ID in the range, a single API call retrieved the full record:

CAN.db("taiKhoan.{id}", function() {
    var d = config("taiKhoan.{id}");
    // d now contains all fields for this account
});

No tokens. No cookies. No authentication headers. The platform auto-creates an anonymous session (I received session ID kID=186xxxxx) and serves the data. Just like Part 1 – the database simply answers anyone who asks.

3.2. Two Directions of Exposure

The 80,053 accounts were not a single uniform dataset. They split into two very different exposure stories – each with its own severity:

The first story is about 78,981 students and alumni – the sheer mass of personal data exposed. The second is about 562 staff and faculty – a smaller group, but with a far more dangerous payload: their passwords were in the API response.

Let me walk through each.

4. Direction 1: Student and Alumni Exposure – 78,981 Accounts

4.1. The Scale

The vast majority of exposed accounts – 21,393 current students and 57,588 alumni – belonged to people who had studied at University X going back nearly two decades. These were standard accounts (type 0), each containing up to 40 fields of personal data.

Figure 1: Sample student account record as returned by the unauthenticated API – showing personal data fields including name, date of birth, student ID, and contact information.

4.2. What Was Exposed for Each Student

Every student record was a personal dossier. Here is how completely the data was filled in:

80,037 full names. 78,637 dates of birth. 23,970 phone numbers. 2,750 national ID numbers. And for 333 accounts – even their parents’ names. This was not a list of usernames. It was a complete personal dossier for nearly the entire university population.

4.3. A Portrait of the Student Body

The data painted a detailed picture of University X. The 4:1 female-to-male ratio (54,815 female, 13,522 male) reflected the university’s specialization in foreign languages. Enrollment records spanned from K2008 to K2025 – nearly two decades of students, all in one exposed database.

Of the 29,640 email addresses, 20,793 were personal Gmail accounts, while 5,329 used the university’s Microsoft 365 domain. The 68 accounts with gmai.com and 48 with gmail.con confirmed this was real, human-entered data – typos and all.

50,042 accounts listed a hometown, heavily concentrated in northern Vietnam – 35.5% from Ha Noi alone. The top faculties were Business Administration & Tourism (5,579), English (5,510), and Chinese (4,422), across 42 unique faculty names and 56 programs.

The full statistical breakdowns – faculties, majors, geographic distribution, demographics – are available in the Appendix.

4.4. Why This Matters

Student exposure was about volume and depth. Any attacker with a browser could build a dossier on nearly 80,000 people: their name, birthday, phone number, home province, what they study, and when they enrolled. For 2,750 people, their national ID number was exposed too – a piece of data that cannot be changed, ever.

But the students did not have login credentials exposed. That distinction belongs to the second group.

5. Direction 2: Staff and Faculty Exposure – 562 Accounts (with Passwords)

5.1. A Smaller Group, a Bigger Problem

The staff and faculty accounts were a fraction of the total – just 562 out of 80,053. But what made them uniquely dangerous was four extra fields that student accounts did not have: username, password, password_unmasked, and password_type.

The API was returning credentials. Not just personal data – actual login credentials for university staff.

5.2. The Password Field

While mapping the fields returned for staff accounts, one field stopped me cold: ợ.

For student accounts, this field was empty. For staff and administrative accounts, it contained what appeared to be credentials. I stared at the screen for a moment, not quite believing what I was seeing. The platform was returning passwords in its API response.

Credential data was exposed for 561 accounts across three account types:

The 554 accounts with non-empty passwords fell into two categories:

Fifty passwords in cleartext. Just sitting there in the API response. And the other 504? They were “masked” – but as I would soon discover, the masking was barely an obstacle at all.

Figure 2: A staff account record from the API response – note the credential fields including username and password data, served to an unauthenticated anonymous session.

5.3. The Masking Algorithm

The masked passwords followed a consistent pattern:

first 2 characters + "**" + last 2 characters + "[" + total length + "]"

For example, a masked password like xx**xx[13] reveals:

• Starts with: first 2 characters
• Ends with: last 2 characters
• Total length: 13 characters
• Unknown: only 9 middle characters

This is not encryption. It is not hashing. It is a display mask that preserves information about the original password – information that dramatically reduces the search space for recovery.

And that is when I realized something worse.

5.4. Offline Password Recovery

The data needed to guess these passwords was in the same API response.

Think about it. Vietnamese users commonly construct passwords from personal information: date of birth, name components, phone numbers. And the API response for each staff account included all of these fields – name, date of birth, phone number, email – right alongside the masked password.

The platform was not just handing out the locked door. It was handing out the key and pointing to which lock it fit.

I wrote an offline dictionary generator that combined:

• Date of birth (various formats: ddmmyyyy, dmyyyy, dd/mm/yyyy)
• First name, last name (with Vietnamese diacritics removed)
• Phone number (full and last 4–6 digits)
• Common patterns: name + dob, dob + name, phone + name

The masked format acted as a validator: a candidate password could be instantly verified if its first 2 characters, last 2 characters, and length matched the mask – no login attempt required. No contact with the server. Entirely offline.

Against 554 exposed passwords, the results:

Recovery method breakdown for the 208 usable credentials:

208 credentials obtained without ever touching the login page. The passwords were not “cracked” in the traditional sense – they were either read in plaintext or reconstructed from biographical data served by the same unauthenticated endpoint.

5.5. Who Were These Staff Members?

These were not test accounts or abandoned profiles. The 562 staff accounts in the staff roster included individuals across 35 distinct positions – from academic advisors to department heads:

The PII completeness for staff accounts was striking – 99.6% had usernames, 98.6% had passwords in some form, and 92.9% had email addresses:

5.6. The Irony

Let me spell out the absurdity of this situation:

1. The API serves staff passwords (masked or plaintext) to anonymous users.
2. The same API serves the personal data needed to recover masked passwords.
3. No authentication is required for any of it.

The platform hands an attacker both the locked door and the key, then points to the correct door.

At this point, I had 208 working credentials for university staff. I had not logged into anything. I had not interacted with any login form. But I needed to prove that these credentials actually worked – that the theoretical risk was real.

6. Account Takeover – Proof of Concept

6.1. Choosing a Target

To demonstrate the real-world impact, I selected the highest-privilege account I could identify: a Vice Rector of University X. This was account #xxxx, retrieved via the same unauthenticated API call as every other account:

CAN.db("taiKhoan.xxxx", function() {
    var d = config("taiKhoan.xxxx");
    console.log(d["a"]);   // username
    console.log(d["ợ"]);   // password
});

The API returned the username and a password. For this particular account, the password was recoverable.

6.2. The Login

The process was absurdly straightforward:

1. Read the credentials from the API response.
2. Navigate to the login page.
3. Enter the username and password.
4. Press “Login.”

That was it. No bruteforce. No password cracking tool. No session hijacking. No exploit. I read a field from an unauthenticated API and typed it into a form.

The login succeeded.

I was now authenticated as a Vice Rector of University X with full administrative access to the platform.

Figure 3: The in-house platform’s administrative interface – accessed using a Vice Rector’s credentials read directly from the unauthenticated API response.

6.3. What Was Accessible

With administrative credentials, the scope of access expanded dramatically:

• Full user management capabilities
• Access to internal announcements and communications
• Ability to modify user records
• Access to administrative functions and settings

I took a screenshot to document the access, then immediately terminated the session. No actions were taken, no data was modified, and no further exploration was performed under the compromised account. One screenshot was enough. The point was proven.

7. The “Fix” That Wasn’t

7.1. Vendor Response: tec.universityx.vn

After responsible disclosure in February 2026, Company Y implemented changes to tec.universityx.vn (the exam system from Part 1). I was cautiously optimistic. The “fix” had two components:

Data-level cleanup: Some PII fields were emptied for candidate records. Full names, phone numbers, emails, and CCCD numbers were removed from API responses.

Obfuscation layer: Remaining data was wrapped in a custom Base64 encoding scheme called “b6x.”

The first part was a step in the right direction. The second part was not.

7.2. The b6x Encoding: A 9th-Century Cipher

Before the patch, the API returned plaintext fields:

{
    "16xxxxx": "Tran Thi Hxxx",       // First name
    "16xxxxx": "23xxxxxxxx",           // CCCD number
    "16xxxxx": "09xxxxxxxx",           // Phone
    "16xxxxx": "hoaixxxx@gmail.com"    // Email
}

After the patch, fields were encoded into a single blob:

{
    "i": "16xxxxx",
    "_5a9fxxxxxxxxxxxxxxxxxxxxxxxxxxxx": "wqD2xxxxxxxxxxxxxxxxxxxx..."
}

This looks encrypted at first glance. It is not. The encoding uses a monoalphabetic substitution cipher – a technique broken since the 9th century (Al-Kindi, Manuscript on Deciphering Cryptographic Messages, circa 850 CE).

The “encryption” is a simple character substitution between two alphabets:

Custom (b6x):  OsCmIBxZDQxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxtz0dV:e5vFb
Standard B64:  ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/=

And the decryption function? It ships in the same JavaScript bundle that every browser downloads:

d64 = function(v, k) {
    switch(k) {
        case "x":
            if (!v) return "";
            v = strtr(v,
                "OsCmIBxZDQxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxtz0dV:e5vFb",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/="
            );
            return decodeURIComponent(
                atob(v).split("").map(function(c) {
                    return "%" + c.charCodeAt(0).toString(16);
                }).join("")
            );
    }
};

A five-line function to undo the entire “security” measure. The key, the algorithm, and the implementation are all delivered to the attacker’s browser as part of normal page load. Security through obscurity – and not even good obscurity.

7.3. connections.universityx.vn: Completely Untouched

While Company Y applied their cosmetic fix to the exam system, the in-house platform at connections.universityx.vn received no changes whatsoever. All 80,053 accounts remained fully accessible. Staff passwords were still in the API response.

They patched the window and left the front door wide open.

7.4. Revalidation Results

On March 10, 2026, I went back and systematically re-tested every attack vector across both platforms:

Score: 7 out of 10 tests still vulnerable. The registration search and image CDN were restricted, and one XHR endpoint added a token check. But the core vulnerability – unauthenticated database access via IDOR – remained fully exploitable on both platforms.

The vendor treated symptoms while leaving the disease untouched.

8. Impact Assessment

8.1. Scale of Exposure

8.2. Attack Complexity

This is not a sophisticated attack. The entire exploitation chain requires:

1. Open a browser.
2. Open the developer console.
3. Type a single API call.
4. Read the response.

CVSS 3.1 Vector: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N – 9.8 Critical.

No special tools. No technical expertise beyond basic JavaScript. No interaction from the victim. Fully automatable. Executable at scale. A motivated attacker could extract all 80,053 accounts in a matter of hours.

8.3. Real-World Risk Scenarios

Identity theft and fraud: 2,750 national ID numbers combined with full names, dates of birth, and addresses – everything needed for identity fraud, unauthorized financial account creation, or SIM-swapping attacks.

Targeted phishing: 29,640 email addresses and 23,970 phone numbers, combined with detailed personal context (faculty, major, enrollment year) – the ingredients for highly targeted social engineering campaigns that would be almost impossible to distinguish from legitimate university communications.

Account takeover cascade: 208 usable staff credentials that may be reused across other systems – university email, internal portals, government services. A Vice Rector’s compromised account could be leveraged for further lateral movement into more sensitive systems.

Institutional damage: Unauthorized administrative access could allow modification of student records, academic results, or official communications. Imagine a compromised account changing grades or sending fake announcements to the entire university.

Family members at risk: 677 accounts exposed parents’ names and birth years – data that can be used in social engineering or identity verification bypass. The exposure reaches beyond the individuals who signed up.

8.4. Legal Context: Vietnam’s Personal Data Protection Framework

Vietnam protects personal data through two layers of legislation: Decree 13/2023/NĐ-CP (effective July 1, 2023) and the newer Law on Personal Data Protection – Law 91/2025/QH15 (passed June 26, 2025, effective January 1, 2026). Together, they form a legal framework that requires organizations to protect personal data, grants citizens control over their own information, and imposes serious penalties for violations.

Both University X and Company Y are in direct, documented violation of this framework. This is not a matter of interpretation. The violations are architectural, systematic, and ongoing.

What the law defines as protected data

Decree 13, Article 2, Clause 3 classifies the following as basic personal data: full name, date of birth, gender, place of birth, place of residence, nationality, personal image, phone number, CMND/CCCD number, and family relationship information. Every single one of these categories was exposed in this investigation – for over 80,000 individuals – with zero access controls.

Decree 13, Article 2, Clause 4 defines sensitive personal data as data that, when violated, directly affects the rights and legitimate interests of the individual – including political and religious views, ethnicity data, and data about criminal records. This investigation exposed ethnicity for 7,845 accounts and religion for 5,476 accounts.

Law 91/2025, Article 2 reinforces these definitions and adds that sensitive personal data is determined by a Government-issued list, and that even de-identified data – once re-identified – is still personal data (Article 2, Clause 1).

Who is responsible?

Both laws draw the same clear line between two roles:

• Data Controller (Bên Kiểm soát dữ liệu cá nhân): the organization that determines the purpose and means of processing personal data (Decree 13, Art. 2 Cl. 9; Law 91, Art. 2 Cl. 7). University X is the Data Controller. The university decided to collect student and staff data, determined what data to store, and chose to deploy the Connections platform. The data belongs to University X’s students and staff. The responsibility starts here.

• Data Processor (Bên Xử lý dữ liệu cá nhân): the organization that processes data on behalf of the Data Controller, through a contract or agreement (Decree 13, Art. 2 Cl. 10; Law 91, Art. 2 Cl. 8). Company Y is the Data Processor. They built, hosted, and operated the Connections platform that stored and served University X’s data. They are the ones who decided the platform needed no authentication.

What they were required to do – and did not

Decree 13, Article 26 requires that data protection measures be applied from the very beginning and throughout the entire processing lifecycle. These measures must include both organizational and technical safeguards (Clause 2). Company Y’s platform had no technical safeguards. No authentication. No access control. No encryption. The API served raw personal data to anonymous visitors.

Decree 13, Article 27 requires controllers and processors to check network security of systems and devices used for processing personal data, and to erase or destroy data on unrecoverable devices (Clause 4). The platform had no network security checks – any browser could query the database directly.

Law 91/2025, Article 3 establishes the core principles: personal data may only be collected and processed within a defined scope, for a clear and lawful purpose (Clause 2); effective institutional, technical, and human measures must be implemented to protect personal data (Clause 4); and organizations must proactively prevent, detect, block, and handle all violations in a timely manner (Clause 5). Company Y violated every single one of these principles. University X failed to verify that any of them were being followed.

Law 91/2025, Article 12 explicitly requires the encryption of personal data – converting it into a form that cannot be recognized without decryption (Clause 1). Company Y did the opposite: they stored passwords in plaintext and personal data in raw, unencrypted API responses accessible to anyone.

Decree 13, Article 38 defines the Data Controller’s obligations: implement organizational and technical measures to demonstrate compliance (Clause 1), maintain processing logs (Clause 2), report violations per Article 23 (Clause 3), choose only Data Processors with adequate protection measures (Clause 4), and bear responsibility to data subjects for damages caused by processing (Clause 6). University X chose Company Y as its Data Processor without verifying – or despite – the complete absence of security measures.

Decree 13, Article 39 defines the Data Processor’s obligations: only accept data after a contract or agreement (Clause 1), process data according to that agreement (Clause 2), fully implement all protection measures required by the decree (Clause 3), and bear responsibility to data subjects for damages caused during processing (Clause 4). Company Y failed on every count.

What the law demands after a violation is discovered

Decree 13, Article 23 mandates that upon discovering a data protection violation, the Data Controller must notify the Ministry of Public Security (Department of Cybersecurity and High-Tech Crime Prevention) within 72 hours using the prescribed Form No. 03 (Clause 1). The Data Processor must notify the Data Controller as soon as possible (Clause 2). The notification must include: the nature of the violation, the time and location, the types of personal data affected, the number of data subjects involved, and the measures taken to address the harm (Clause 3).

Law 91/2025, Article 23 strengthens this requirement: when a violation that could harm national security, social order, life, health, reputation, dignity, or property of data subjects is discovered, notification to the data protection authority must happen within 72 hours (Clause 1). The Data Controller must prepare an official incident report and cooperate with authorities to handle the violation (Clause 2).

Law 91/2025, Article 21 requires Data Controllers and Processors to prepare and maintain a Data Processing Impact Assessment – filed with the data protection authority within 60 days of starting data processing (Clause 1). This assessment must be updated annually (Clause 2) and must always be available for inspection by the Ministry of Public Security (Decree 13, Article 24, Clause 4). There is no evidence that University X or Company Y ever filed such an assessment.

What are the consequences?

The penalties are no longer vague. Law 91/2025, Article 8 spells them out:

• Violations may result in disciplinary action, administrative penalties, or criminal prosecution depending on the nature and severity (Clause 1).
• For individuals who buy, sell, or illegally trade personal data: fines of up to 10 times the revenue derived from the violation (Clause 3).
• For organizations violating cross-border data transfer rules: fines of up to 5% of the organization’s annual revenue in Vietnam (Clause 4).
• For all other data protection violations: maximum administrative fines of 3 billion VND (~$120,000 USD) for organizations (Clause 5).
• Individuals committing the same violations face fines of up to half the organizational maximum (Clause 6).
• If violations cause damages, compensation is mandatory under the law (Clause 1).

Decree 13, Article 4 adds that violations may be handled through disciplinary measures, administrative sanctions, or criminal prosecution depending on severity.

What 80,053 data subjects can demand

The rights of data subjects are not theoretical. They are enforceable:

• Right to know about data processing activities (Law 91, Art. 4 Cl. 1a; Decree 13, Art. 9 Cl. 1)
• Right to withdraw consent (Law 91, Art. 4 Cl. 1b; Decree 13, Art. 9 Cl. 2)
• Right to access and correct their data (Law 91, Art. 4 Cl. 1c; Decree 13, Art. 9 Cl. 3)
• Right to request deletion and restriction of processing (Law 91, Art. 4 Cl. 1d; Decree 13, Art. 9 Cl. 5–6)
• Right to file complaints, lawsuits, and demand compensation for damages (Law 91, Art. 4 Cl. 1đ; Decree 13, Art. 9 Cl. 9–10)
• Right to request that competent authorities and related organizations implement data protection measures (Law 91, Art. 4 Cl. 1e)

Every one of the 80,053 exposed individuals has these rights. Every one of them can demand answers from University X and Company Y. Every one of them can demand that their data be secured, that they be notified of the breach, and that they be compensated for the violation.

The bottom line

University X cannot hide behind Company Y. The law makes the Data Controller explicitly responsible for choosing a Data Processor with adequate protection measures (Decree 13, Art. 38 Cl. 4) and liable for damages (Decree 13, Art. 38 Cl. 6). By outsourcing their platform to a vendor with zero security architecture, University X did not outsource their responsibility – they amplified their liability.

Company Y cannot claim ignorance. They built the platform. They decided that client-side JavaScript was sufficient security. They chose to return passwords in API responses. They failed to encrypt personal data as required by Law 91 Article 12. Every architectural decision that led to this exposure was theirs.

The law requires them to act. Not eventually. Not when convenient. Now.

• Notify the Ministry of Public Security within 72 hours of discovering the violation.
• Prepare and file Data Processing Impact Assessments.
• Implement real authentication, access control, and encryption.
• Notify all 80,053 affected individuals.
• Remove exposed credentials from the API immediately.
• Conduct a full security audit of the Connections platform – not just the University X deployment, but every client running on the same architecture.

80,053 people trusted University X with their personal data. That trust was delegated to Company Y. Both failed. The law says that failure has consequences. It is time those consequences are enforced.

9. Conclusion

In Part 1, I found 896 people’s identity cards exposed through a university exam portal. The natural follow-up question – “what about the bigger platform?” – led to an answer that was orders of magnitude worse: 80,053 accounts, staff passwords in the API, and administrative account takeover.

The root cause has not changed since Part 1. It is the same architectural failure: Company Y’s Connections platform enforces no server-side authentication or authorization. The JavaScript framework running in the user’s browser is the only thing between a visitor and the database. That is not a security boundary. It is the absence of one.

What makes this finding particularly troubling is the password exposure. Storing credentials in a client-accessible API response – even masked – is not a design oversight. It is a fundamental misunderstanding of how authentication systems should work. Passwords should never leave the server, in any form, under any circumstances. The fact that the masking algorithm could be reversed using data from the same response elevates this from a data leak to a complete authentication compromise.

The vendor’s initial response – removing some field values and adding a client-side substitution cipher – demonstrated a pattern of treating visible symptoms rather than addressing root causes. As of the March 10 revalidation, 7 of 10 attack vectors remained exploitable, and the in-house platform had received no security changes at all. (See Section 10 for the June 23 update, where the vendor deployed server-side authentication and remediated the core vulnerability.)

These are not abstract risks. Behind the 80,053 account IDs are real people: students who trusted their university with personal information, alumni who expected their data to remain private, and staff whose credentials were exposed to anyone who cared to look. A Vice Rector’s account was compromised not through a clever exploit, but by reading a field in an API response and typing it into a login form.

The fix this platform needs is not another layer of client-side obfuscation. It is the implementation of what should have existed from day one: server-side authentication, role-based access control, and the basic principle that a database should not answer questions from strangers.

10. Revalidation Update – June 23, 2026

On June 23, 2026, ten days after this report was published, I retested all attack vectors on both platforms. Company Y had updated the codebase that same day (version 14484523062026), and the results were substantially different from the March 10 revalidation.

What changed

The most significant fix is architectural: the XHR API gateway now enforces server-side authentication. Both connections.universityx.vn/xhr/ and the secondary endpoint at xhr.companyy.com/xhr/ return HTTP 403 with {"error":403,"code":"access_denied"} for unauthenticated POST requests. This is the first time server-side access control has been observed on this platform.

With the API gateway locked, the downstream effects are immediate:

• Account IDOR is dead. All tested account IDs (including the original range of 7,787–215,212) return null. The database no longer answers questions from strangers.
• Password exposure is eliminated. With account records blocked, the password field (ợ) is no longer accessible. The 208 usable staff credentials documented in this report are no longer retrievable.
• Bulk enumeration is blocked on connections.universityx.vn. The mass-load endpoint returns an empty array.
• The b6x cipher has been removed from tec.universityx.vn. The monoalphabetic substitution layer documented in Section 7.2 is gone entirely.

What remains vulnerable

The JS framework and auto-session creation are still exposed on both platforms. Anonymous visitors still receive session IDs and access to the full client-side API surface. These are low-severity on their own, as they only become dangerous when combined with data access, which is now blocked.

On tec.universityx.vn (the Part 1 exam system), the fix is less complete:

Scorecard

Is this safe enough?

For connections.universityx.vn, the platform documented in this report: yes, the critical vulnerability is remediated. The 80,053 accounts and staff passwords are no longer accessible to unauthenticated users. The vendor has moved from “no security” to “server-side enforcement at the API gateway,” which is the correct architectural fix rather than another layer of client-side obfuscation.

That said, the fix is an authentication gate bolted onto an existing architecture, not a redesign. The client-side framework still loads, sessions are still auto-created, and the underlying data model presumably still returns all fields to authenticated users without role-based filtering. A compromised or low-privilege authenticated session might still access more data than it should. A full security audit would need to verify that the post-authentication access controls are equally robust.

For tec.universityx.vn, the picture is mixed. The exam system still leaks partial candidate data and has regressed on CDN image access. The Part 1 findings are not fully resolved.

The vendor has made real progress. Whether it is sufficient depends on whether they continue: the pattern so far has been incremental patches in response to published reports rather than a comprehensive security review of the platform. The next step should be a professional penetration test of the authenticated attack surface, something that is outside the scope of this research.

Appendix

A. Responsible Disclosure Timeline

B. Technical Attack Classification

C. Data Source Summary

All statistics in this report are derived from the following extracted datasets:

Sub-CSV totals: 21,393 + 57,588 + 562 + 166 + 344 = 80,053 (matches main dataset exactly).

D. Glossary

E. Sample Account Record (Redacted)

{
  "account_id": "[REDACTED]",
  "ho_ten": "[REDACTED]",
  "ngay_sinh": "xx/xx/1999",
  "gioi_tinh": "Nữ",
  "sdt": "098XXXXXXX",
  "email": "[redacted]@gmail.com",
  "cmnd_cccd": "001XXXXXXXXX",
  "que_quan": "[Province]",
  "ma_sinh_vien": "19XXXXXX",
  "khoa": "Faculty of [REDACTED]",
  "nganh": "[REDACTED]",
  "khoa_hoc": "20xx-20xx",
  "loai_tk": "0"
}

F. Detailed Statistical Tables

This appendix contains the full statistical breakdowns referenced in Section 3.5.

Email Domain Distribution (29,640 email addresses):

Gender Distribution:

Geographic Distribution – top 15 hometowns (of 50,042 with data):

Top 10 Faculties:

41,340 accounts had faculty data, across 42 unique faculty names.

Top 10 Majors:

41,226 accounts had major data, across 56 unique programs.

Program Types:

Enrollment Year – Top 10:

39,768 accounts had enrollment year data, spanning from K2008 to K2025.

Student Status:

Ethnicity – 7,845 accounts:

Nationality – 5,655 accounts: 5,621 Vietnamese, plus 34 foreign nationals from China, Japan, Indonesia, South Korea, Thailand, Philippines, Taiwan, New Zealand, and others.

Religion – 5,476 accounts: 5,134 none, 215 Buddhist, 104 Catholic, 14 Christian, 8 other, 1 Protestant.

Note: Detailed reproduction code, staff credentials, and unredacted data have been withheld from this publication. Full technical details were shared with the affected parties during responsible disclosure.

Cập nhật (23 tháng 6, 2026): Lỗ hổng cốt lõi đã được khắc phục

Công ty Y đã triển khai xác thực phía server trên cổng API XHR. Lỗ hổng IDOR tài khoản và lộ mật khẩu trên nền tảng này không còn khai thác được. Xem chi tiết kiểm tra lại bên dưới.

CVSS 3.1: 9.8 (CRITICAL)

Lộ thông tin đăng nhập hàng loạt + chiếm quyền tài khoản qua API không xác thực.

Tóm tắt

Phần 1 kết thúc với 896 thí sinh bị lộ dữ liệu cá nhân và ảnh chụp CCCD qua hệ thống Trung tâm Khảo thí của Trường Đại học X, toàn bộ được xây dựng trên nền tảng “Connections” của Công ty Y. Tôi khép lại báo cáo đó với một câu hỏi cứ lởn vởn trong đầu không chịu biến mất: nếu hệ thống thi cử không có bất kỳ kiểm soát truy cập nào, thì nền tảng chính của trường, chạy trên cùng một hạ tầng, sẽ ra sao?

Câu hỏi đó khiến tôi không yên. Và câu trả lời thì tệ hơn rất nhiều so với kịch bản xấu nhất mà tôi đã hình dung.

Trường Đại học X vận hành connections.universityx.vn như mạng nội bộ trung tâm của trường, cũng được xây dựng trên cùng nền tảng Connections SaaS của Công ty Y. Đây không phải cổng phụ hay hệ thống thí điểm nào đó, mà là nơi chứa mọi sinh viên, mọi cựu sinh viên, mọi cán bộ, mọi giảng viên, toàn bộ dân số kỹ thuật số của trường đại học tập trung tại một chỗ. Sử dụng cùng các kỹ thuật từ Phần 1 (gọi API không xác thực và liệt kê ID tuần tự), tôi đã trích xuất 80.053 tài khoản người dùng, mỗi tài khoản chứa tới 40 trường dữ liệu cá nhân.

Nhưng con số không phải thứ khiến tôi mất ngủ đêm đó. Mà là trường mật khẩu. API trả về thông tin đăng nhập cho cả tài khoản cán bộ lẫn sinh viên: một số ở dạng văn bản thuần (plaintext), số khác được che bằng một thuật toán đơn giản đến mức có thể dịch ngược bằng dữ liệu nằm ngay trong chính phản hồi API đó. Riêng với 554 tài khoản cán bộ có mật khẩu bị lộ, tôi thu được 208 bộ thông tin đăng nhập sử dụng được: 50 đọc trực tiếp ở dạng plaintext, 158 phục hồi offline, mà không cần thực hiện một lần đăng nhập nào.

Và để xác nhận rằng đây không phải rủi ro lý thuyết, tôi đã đăng nhập vào hai tài khoản: một Phó Hiệu trưởng và một sinh viên. Không bruteforce, không exploit, tôi chỉ đọc trường mật khẩu từ API rồi gõ vào form đăng nhập. Cả hai đều vào được ngay lần đầu.

1. Giới thiệu

1.1. Tóm tắt Phần 1

Nếu bạn chưa đọc Phần 1, đây là phiên bản ngắn gọn. Tôi đã điều tra tec.universityx.vn, hệ thống đăng ký thi của Trung tâm Khảo thí, và phát hiện:

• 896 thí sinh bị lộ dữ liệu cá nhân qua API không xác thực
• Số CCCD và ảnh chụp thẻ căn cước ai cũng có thể truy cập
• Nguyên nhân gốc: Nền tảng Connections của Công ty Y không có bất kỳ cơ chế xác thực phía server nào

Vấn đề nằm ở kiến trúc nền tảng, không phải một endpoint bị cấu hình sai. Mọi bảng, mọi trường, mọi tập tin tải lên đều có thể truy cập bởi bất kỳ ai biết (hoặc đoán được) ID đối tượng đúng.

1.2. Câu hỏi tự nhiên tiếp theo

Trung tâm Khảo thí chỉ là một triển khai nhỏ: vài trăm thí sinh mỗi đợt thi. Nhưng tôi biết sự hiện diện của Trường Đại học X trên nền tảng Connections không dừng lại ở đó.

Trường còn vận hành connections.universityx.vn, mạng nội bộ trung tâm, chứa tài khoản của mọi sinh viên, cán bộ, và giảng viên trên toàn trường. Cùng nhà cung cấp, cùng framework JavaScript, cùng các script từ cdn.companyy.com, cùng kiến trúc. Và nếu hệ thống thi cử đã để lộ dữ liệu của 896 người, thì mạng lưới chính của trường đại học, nơi chứa toàn bộ dân số của trường, sẽ phơi bày những gì?

Tôi không thể không đi tiếp.

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

Các nguyên tắc đạo đức từ Phần 1 được áp dụng xuyên suốt:

• Mọi truy cập dữ liệu đều sử dụng các endpoint công khai, không xác thực.
• 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 chia sẻ cho bên thứ ba.
• Không thực hiện tấn công brute-force. Việc phục hồi mật khẩu được thực hiện offline bằng dữ liệu đã bị lộ từ chính API đó.
• Chiếm quyền tài khoản chỉ thực hiện một lần duy nhất, nhằm xác nhận mức độ nghiêm trọng của lỗ hổng, và phiên đăng nhập được kết thúc ngay lập tức.

2. Mục tiêu lớn hơn: Mạng lưới Đại học

2.1. Khám phá nền tảng

Tôi mở connections.universityx.vn trong trình duyệt, bật mã nguồn lên, và cảm giác đầu tiên là déjà vu. Cùng framework JavaScript quen thuộc, tải từ cùng CDN:

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

Các hàm API nội bộ y hệt vẫn có sẵn: CAN.db() để truy vấn cơ sở dữ liệu, config() để đọc phản hồi đã cache, và xửLý() để thực hiện tìm kiếm. Điểm khác biệt duy nhất là dữ liệu: thay vì thí sinh dự thi, nền tảng này quản lý toàn bộ người dùng của trường đại học.

Tôi đã biết kiến trúc này không có ổ khóa trên cửa. Giờ câu hỏi duy nhất là: có bao nhiêu thứ đằng sau cánh cửa đó?

2.2. Lập bản đồ không gian tài khoản

Tôi bắt đầu duyệt qua các ID tài khoản tuần tự qua CAN.db(), cùng kỹ thuật liệt kê như Phần 1. Ước tính ban đầu cho dải hoạt động là 7.787–97.744, khoảng 89.958 ID tiềm năng, con số đã đủ lớn rồi. Nhưng khi quá trình thu thập chạy, các tài khoản cứ liên tục xuất hiện vượt xa giới hạn đó, và tôi bắt đầu nhận ra quy mô thực sự lớn hơn nhiều so với tôi nghĩ:

Hơn 200.000 ID tiềm năng được dò quét, và 80.053 trong số đó trả về bản ghi người dùng đầy đủ, từng cái một, đều truy cập được mà không cần xác thực. Lúc con số vượt qua 50.000 rồi cứ tiếp tục tăng, tôi mới thực sự cảm nhận được sự khác biệt. 896 ở Phần 1 là một góc khuất nhỏ của trường đại học. 80.053 là toàn bộ trường đại học.

3. Thu thập dữ liệu: 80.053 tài khoản

3.1. Phương pháp trích xuất

Kỹ thuật hoàn toàn giống Phần 1. Với mỗi ID tài khoản trong dải, một lệnh gọi API duy nhất trả về toàn bộ bản ghi:

CAN.db("taiKhoan.{id}", function() {
    var d = config("taiKhoan.{id}");
    // d giờ chứa tất cả các trường của tài khoản này
});

Không có token, không cookie, không header xác thực, không gì cả. Nền tảng tự động tạo một phiên ẩn danh (tôi nhận được session ID kID=186xxxxx) và phục vụ dữ liệu như thể tôi là người dùng hợp lệ. Giống hệt Phần 1: cơ sở dữ liệu đơn giản trả lời bất kỳ ai hỏi, không cần biết người hỏi là ai.

3.2. Hai hướng phơi bày

80.053 tài khoản không phải một tập dữ liệu đồng nhất mà chia thành hai câu chuyện phơi bày rất khác nhau, mỗi câu chuyện mang mức độ nghiêm trọng riêng:

Câu chuyện thứ nhất là về 78.981 sinh viên và cựu sinh viên: khối lượng dữ liệu cá nhân bị phơi bày lớn đến mức nào. Câu chuyện thứ hai là về 562 cán bộ và giảng viên, một nhóm nhỏ hơn nhiều, nhưng với dữ liệu đăng nhập bị phơi bày chi tiết hơn. Mật khẩu bị lộ ở cả hai nhóm, nhưng tài khoản cán bộ là nơi tôi tập trung phân tích vì mức độ đặc quyền và tác động của chúng.

4. Hướng 1: Lộ dữ liệu Sinh viên và Cựu sinh viên – 78.981 tài khoản

4.1. Quy mô

Đại đa số tài khoản bị lộ, 21.393 sinh viên đang học và 57.588 cựu sinh viên, thuộc về những người đã theo học tại Trường Đại học X trong gần hai thập kỷ qua. Đây là các tài khoản chuẩn (loại 0), mỗi tài khoản chứa tới 40 trường dữ liệu cá nhân.

Hình 1: Bản ghi tài khoản sinh viên mẫu được trả về bởi API không xác thực, hiển thị các trường dữ liệu cá nhân bao gồm họ tên, ngày sinh, mã sinh viên, và thông tin liên hệ.

4.2. Những gì bị lộ cho mỗi sinh viên

Mỗi bản ghi sinh viên là một hồ sơ cá nhân hoàn chỉnh. Bảng dưới đây cho thấy mức độ đầy đủ của dữ liệu:

80.037 họ tên đầy đủ, 78.637 ngày sinh, 23.970 số điện thoại, 2.750 số căn cước công dân, và thậm chí 333 tài khoản lộ cả tên bố mẹ. Đây không phải danh sách tên đăng nhập hay bảng dữ liệu khô khan nào đó, mà là hồ sơ cá nhân hoàn chỉnh của gần như toàn bộ dân số trường đại học, từ sinh viên năm nhất đến cựu sinh viên gần hai thập kỷ trước, tất cả nằm trơ ra cho ai muốn xem thì xem.

4.3. Bức chân dung của sinh viên toàn trường

Dữ liệu vẽ nên một bức tranh chi tiết đến đáng lo ngại về Trường Đại học X. Tỷ lệ nữ-nam 4:1 (54.815 nữ, 13.522 nam) phản ánh định hướng chuyên ngành ngoại ngữ của trường. Dữ liệu khóa tuyển sinh trải dài từ K2008 đến K2025, gần hai thập kỷ sinh viên, tất cả nằm trong một cơ sở dữ liệu mở toang.

Trong 29.640 địa chỉ email, 20.793 là tài khoản Gmail cá nhân, trong khi 5.329 sử dụng tên miền Microsoft 365 của trường. 68 tài khoản có email gmai.com và 48 có gmail.con, những lỗi đánh máy xác nhận đây là dữ liệu thực do con người nhập, không phải dữ liệu test.

50.042 tài khoản có quê quán, tập trung nhiều ở miền Bắc Việt Nam, riêng Hà Nội chiếm 35,5%. Các khoa đông nhất là Quản trị Kinh doanh & Du lịch (5.579), tiếng Anh (5.510), và tiếng Trung (4.422), trải rộng trên 42 tên khoa và 56 chương trình đào tạo.

Bảng thống kê chi tiết đầy đủ (khoa, ngành, phân bố địa lý, nhân khẩu học) có trong Phụ lục.

4.4. Tại sao điều này quan trọng

Việc lộ dữ liệu sinh viên đáng lo ở cả quy mô lẫn chiều sâu. Bất kỳ ai có trình duyệt đều có thể xây dựng hồ sơ về gần 80.000 người: tên, ngày sinh, số điện thoại, quê quán, ngành học, và năm nhập học. Với 2.750 người, số căn cước công dân cũng bị lộ, một thứ không bao giờ có thể thay đổi được.

Và không chỉ dữ liệu cá nhân, mật khẩu của sinh viên cũng bị lộ qua API. Nhưng phân tích chi tiết về thông tin đăng nhập, tôi tập trung vào nhóm thứ hai, nơi mức độ đặc quyền khiến hậu quả nghiêm trọng hơn nhiều.

5. Hướng 2: Lộ dữ liệu Cán bộ và Giảng viên – 562 tài khoản (kèm mật khẩu)

5.1. Nhóm nhỏ hơn, vấn đề lớn hơn

Tài khoản cán bộ và giảng viên chỉ chiếm một phần nhỏ: 562 trên 80.053. Mật khẩu bị lộ ở cả tài khoản sinh viên lẫn cán bộ, nhưng tài khoản cán bộ đặc biệt nguy hiểm vì bốn trường dữ liệu đăng nhập rõ ràng: username, password, password_unmasked, và password_type, kết hợp với quyền quản trị mà các tài khoản này nắm giữ.

API đang trả về thông tin đăng nhập thật, không chỉ dữ liệu cá nhân, mà là credential thực sự của cán bộ trường đại học.

5.2. Trường mật khẩu

Trong lúc ánh xạ các trường được trả về cho tài khoản cán bộ, tôi nhìn thấy trường ợ và phải dừng lại một lúc.

Trường này có dữ liệu ở cả tài khoản sinh viên lẫn cán bộ, nhưng với tài khoản cán bộ và quản trị, nó chứa thứ trông rõ ràng là thông tin đăng nhập có đặc quyền cao. Tôi ngồi nhìn chằm chằm vào màn hình, đọc đi đọc lại mấy lần vì không tin vào mắt mình. Nền tảng này, cái nền tảng mà hàng chục nghìn người đang dùng, đang trả về mật khẩu trong phản hồi API cho bất kỳ ai hỏi.

Tôi kiểm tra kỹ hơn, và dữ liệu đăng nhập bị lộ cho 561 tài khoản, chia thành ba loại:

554 tài khoản có mật khẩu không rỗng chia thành hai nhóm:

Năm mươi mật khẩu ở dạng văn bản thuần, nằm ngay đó trong phản hồi API, đọc được bằng mắt thường. Còn 504 cái còn lại thì được “che”, nhưng như tôi sắp phát hiện ra, cái lớp che đó mỏng đến mức gần như vô nghĩa.

Hình 2: Bản ghi tài khoản cán bộ từ phản hồi API, lưu ý các trường thông tin đăng nhập bao gồm username và dữ liệu mật khẩu, được phục vụ cho một phiên ẩn danh không xác thực.

5.3. Thuật toán che mật khẩu

Các mật khẩu bị che tuân theo một mẫu nhất quán:

2 ký tự đầu + "**" + 2 ký tự cuối + "[" + tổng độ dài + "]"

Ví dụ, một mật khẩu bị che như xx**xx[13] tiết lộ:

• Bắt đầu bằng: 2 ký tự đầu
• Kết thúc bằng: 2 ký tự cuối
• Tổng độ dài: 13 ký tự
• Chưa biết: chỉ 9 ký tự ở giữa

Đây không phải mã hóa (encryption), cũng không phải hàm băm (hashing). Đây là một mặt nạ hiển thị giữ lại thông tin về mật khẩu gốc, và những thông tin đó thu hẹp đáng kể không gian tìm kiếm để phục hồi.

Rồi tôi nhận ra một điều còn tệ hơn.

5.4. Phục hồi mật khẩu offline

Dữ liệu cần thiết để đoán các mật khẩu này nằm ngay trong cùng phản hồi API.

Lúc đó tôi mới thấy cái nghịch lý: người dùng Việt Nam thường xây dựng mật khẩu từ thông tin cá nhân như ngày sinh, thành phần tên, hay số điện thoại, và phản hồi API cho mỗi tài khoản cán bộ bao gồm tất cả các trường này ngay cạnh mật khẩu bị che. Nền tảng không chỉ đưa ra cánh cửa đã khóa, mà còn đặt luôn chìa khóa ngay bên cạnh kèm hướng dẫn sử dụng.

Tôi viết một bộ sinh từ điển offline kết hợp:

• Ngày sinh (nhiều định dạng: ddmmyyyy, dmyyyy, dd/mm/yyyy)
• Tên, họ (đã bỏ dấu tiếng Việt)
• Số điện thoại (đầy đủ và 4–6 chữ số cuối)
• Các mẫu phổ biến: tên + ngày sinh, ngày sinh + tên, sdt + tên

Định dạng mật khẩu bị che đóng vai trò bộ xác thực: một mật khẩu ứng viên có thể được xác minh ngay lập tức nếu 2 ký tự đầu, 2 ký tự cuối, và độ dài khớp với mặt nạ, không cần đăng nhập. Không liên hệ với server. Hoàn toàn offline.

Kết quả trên 554 mật khẩu bị lộ:

Phân tích phương pháp phục hồi cho 208 bộ thông tin đăng nhập sử dụng được:

208 bộ thông tin đăng nhập thu được mà không hề chạm vào trang đăng nhập. Các mật khẩu không bị “bẻ khóa” theo nghĩa truyền thống, chúng hoặc được đọc thẳng ở dạng plaintext, hoặc được tái tạo từ dữ liệu tiểu sử do chính endpoint không xác thực cung cấp.

5.5. Những cán bộ này là ai?

Đây không phải tài khoản thử nghiệm hay hồ sơ bị bỏ hoang. 562 tài khoản cán bộ bao gồm cá nhân thuộc 35 chức vụ khác nhau, từ cố vấn học tập đến trưởng phòng:

Mức độ đầy đủ dữ liệu cá nhân của tài khoản cán bộ rất đáng chú ý: 99,6% có username, 98,6% có mật khẩu dưới một dạng nào đó, và 92,9% có địa chỉ email:

5.6. Sự phi lý

Tôi cần nói thẳng, vì càng viết tôi càng thấy tình huống này vô lý đến khó tin:

API phục vụ mật khẩu cho người dùng ẩn danh, cả sinh viên lẫn cán bộ, dù ở dạng che hay plaintext. Cùng API đó phục vụ luôn dữ liệu cá nhân cần thiết để phục hồi mật khẩu bị che. Và không cần xác thực cho bất kỳ bước nào trong quy trình này. Nền tảng vừa đưa ra cánh cửa đã khóa, vừa đặt chìa khóa ngay bên cạnh, vừa chỉ cho biết cửa nào cần mở.

Tại thời điểm này, tôi có 208 bộ thông tin đăng nhập hoạt động được của cán bộ trường đại học, mà chưa hề đăng nhập vào bất cứ đâu, chưa tương tác với bất kỳ form đăng nhập nào. Nhưng tôi cần chứng minh rằng những thông tin đăng nhập này thực sự hoạt động, rằng đây không chỉ là rủi ro trên giấy.

6. Chiếm quyền tài khoản – Proof of Concept

6.1. Chọn mục tiêu

Để chứng minh tác động thực tế, tôi chọn hai tài khoản: một sinh viên bình thường và một Phó Hiệu trưởng của Trường Đại học X, tài khoản có đặc quyền cao nhất mà tôi có thể xác định. Cả hai đều được truy xuất qua cùng lệnh gọi API không xác thực:

CAN.db("taiKhoan.xxxx", function() {
    var d = config("taiKhoan.xxxx");
    console.log(d["a"]);   // username
    console.log(d["ợ"]);   // password
});

API trả về tên đăng nhập và mật khẩu cho cả hai. Với cả hai tài khoản, mật khẩu có thể phục hồi được. Tôi nín thở và mở trang đăng nhập.

6.2. Đăng nhập

Tôi đọc thông tin đăng nhập từ phản hồi API, truy cập trang đăng nhập, nhập tên đăng nhập và mật khẩu, rồi nhấn “Đăng nhập.” Toàn bộ quá trình không kịch tính như tôi tưởng, không bruteforce, không công cụ bẻ khóa, không chiếm phiên, không exploit, chỉ là đọc một trường từ API rồi gõ nó vào form.

Cả hai tài khoản đều đăng nhập thành công ngay lần đầu, sinh viên lẫn Phó Hiệu trưởng.

Với tài khoản sinh viên, tôi truy cập được giao diện nền tảng mạng nội bộ của trường. Với tài khoản Phó Hiệu trưởng, tôi có toàn quyền truy cập quản trị. Cảm giác lúc đó không phải hào hứng mà là lo lắng thật sự, vì nếu tôi làm được, bất kỳ ai cũng làm được.

Hình 3: Giao diện nền tảng mạng nội bộ, được truy cập bằng thông tin đăng nhập của một sinh viên, đọc trực tiếp từ phản hồi API không xác thực.

6.3. Những gì có thể truy cập

Với tài khoản sinh viên, nền tảng mở ra giao diện mạng nội bộ đầy đủ. Với thông tin đăng nhập quản trị của Phó Hiệu trưởng, phạm vi truy cập mở rộng đáng kể hơn:

• Toàn quyền quản lý người dùng
• Truy cập thông báo nội bộ và truyền thông
• Khả năng chỉnh sửa hồ sơ người dùng
• Truy cập các chức năng và cài đặt quản trị

Tôi chụp ảnh màn hình để ghi nhận việc truy cập, rồi kết thúc cả hai phiên ngay lập tức. Không thực hiện hành động nào, không sửa đổi dữ liệu nào, và không khám phá thêm gì dưới các tài khoản bị chiếm quyền. Điều cần chứng minh đã được chứng minh.

7. Bản “vá” không thực sự vá

7.1. Phản hồi của nhà cung cấp: tec.universityx.vn

Sau khi thực hiện công bố có trách nhiệm (responsible disclosure) vào tháng 2 năm 2026, Công ty Y đã triển khai các thay đổi trên tec.universityx.vn (hệ thống thi từ Phần 1). Tôi thận trọng lạc quan khi nghe tin. Bản “vá” gồm hai phần:

Làm sạch dữ liệu: Một số trường PII đã được xóa nội dung cho bản ghi thí sinh. Họ tên, số điện thoại, email, và số CCCD đã được loại bỏ khỏi phản hồi API.

Lớp che giấu (obfuscation): Dữ liệu còn lại được bọc trong một sơ đồ mã hóa Base64 tùy chỉnh gọi là “b6x.”

Phần thứ nhất là một bước đi đúng hướng. Phần thứ hai thì không.

7.2. Mã hóa b6x: Mật mã từ thế kỷ thứ 9

Trước bản vá, API trả về các trường ở dạng văn bản thuần:

{
    "16xxxxx": "Tran Thi Hxxx",       // Họ tên
    "16xxxxx": "23xxxxxxxx",           // Số CCCD
    "16xxxxx": "09xxxxxxxx",           // Số điện thoại
    "16xxxxx": "hoaixxxx@gmail.com"    // Email
}

Sau bản vá, các trường được mã hóa thành một khối duy nhất:

{
    "i": "16xxxxx",
    "_5a9fxxxxxxxxxxxxxxxxxxxxxxxxxxxx": "wqD2xxxxxxxxxxxxxxxxxxxx..."
}

Thoạt nhìn, điều này trông như đã được mã hóa đàng hoàng. Nhưng khi tôi bắt đầu đọc kỹ JavaScript mà trình duyệt tải về, tôi nhận ra đây chỉ là mật mã thay thế đơn bảng (monoalphabetic substitution cipher), một kỹ thuật mà nhà toán học Al-Kindi đã phá giải từ thế kỷ thứ 9 trong Bản thảo về Giải mã Thông điệp Mật mã (khoảng năm 850 SCN). Hơn một nghìn năm trước.

Toàn bộ “mã hóa” chỉ là phép thay thế ký tự đơn giản giữa hai bảng chữ cái:

Tùy chỉnh (b6x):  OsCmIBxZDQxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxtz0dV:e5vFb
Chuẩn B64:         ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/=

Và hàm giải mã? Nó được giao cùng trong gói JavaScript mà mọi trình duyệt đều tải về:

d64 = function(v, k) {
    switch(k) {
        case "x":
            if (!v) return "";
            v = strtr(v,
                "OsCmIBxZDQxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxtz0dV:e5vFb",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/="
            );
            return decodeURIComponent(
                atob(v).split("").map(function(c) {
                    return "%" + c.charCodeAt(0).toString(16);
                }).join("")
            );
    }
};

Năm dòng code để vô hiệu hóa toàn bộ biện pháp “bảo mật.” Khóa, thuật toán, và cách triển khai đều được giao thẳng cho trình duyệt của kẻ tấn công như một phần của quá trình tải trang bình thường. Bảo mật bằng che giấu (security through obscurity), và còn không phải kiểu che giấu tốt.

7.3. connections.universityx.vn: Hoàn toàn không thay đổi

Và đây mới là điều khiến tôi thực sự bực bội. Trong khi Công ty Y bỏ công áp dụng bản vá mỹ phẩm cho hệ thống thi, nền tảng mạng nội bộ tại connections.universityx.vn, nơi chứa 80.053 tài khoản và mật khẩu cán bộ, không nhận được bất kỳ thay đổi nào. Toàn bộ 80.053 tài khoản vẫn có thể truy cập đầy đủ, mật khẩu cán bộ vẫn nằm trong phản hồi API.

Họ vá cửa sổ và để ngỏ cửa chính.

7.4. Kết quả kiểm tra lại

Vào ngày 10 tháng 3 năm 2026, tôi quay lại và kiểm tra lại một cách có hệ thống mọi vector tấn công trên cả hai nền tảng:

Kết quả: 7 trên 10 kiểm tra vẫn còn lỗ hổng. Tìm kiếm đăng ký và CDN ảnh đã bị hạn chế, và một endpoint XHR đã thêm kiểm tra token. Nhưng lỗ hổng cốt lõi, truy cập cơ sở dữ liệu không xác thực qua IDOR, vẫn có thể khai thác hoàn toàn trên cả hai nền tảng.

Nhà cung cấp chữa triệu chứng mà bỏ mặc căn bệnh.

8. Đánh giá tác động

8.1. Quy mô phơi bày

8.2. Độ phức tạp tấn công

Đây không phải một cuộc tấn công tinh vi. Toàn bộ chuỗi khai thác chỉ cần:

1. Mở trình duyệt.
2. Mở developer console.
3. Gõ một lệnh gọi API.
4. Đọc phản hồi.

CVSS 3.1 Vector: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N – 9.8 Critical.

Không cần công cụ đặc biệt, không cần chuyên môn kỹ thuật ngoài JavaScript cơ bản, không cần tương tác từ nạn nhân. Hoàn toàn có thể tự động hóa và thực hiện được ở quy mô lớn. Một kẻ tấn công có động cơ có thể trích xuất toàn bộ 80.053 tài khoản trong vài giờ.

8.3. Các kịch bản rủi ro thực tế

Đánh cắp danh tính và lừa đảo: 2.750 số CCCD kết hợp với họ tên đầy đủ, ngày sinh, và địa chỉ. Chỉ cần bấy nhiêu thông tin là đủ để mở tài khoản ngân hàng giả, vay tín dụng đen, hoặc thực hiện SIM-swap. Những người này sẽ chỉ biết khi đã quá muộn, khi có ai đó gọi đến đòi nợ cho khoản vay họ chưa từng đăng ký.

Phishing có mục tiêu: 29.640 địa chỉ email và 23.970 số điện thoại kết hợp với ngữ cảnh cá nhân chi tiết, khoa nào, ngành gì, năm nào nhập học, tạo nên nguyên liệu cho những chiến dịch social engineering mà người nhận gần như không thể phân biệt với thông tin liên lạc hợp pháp từ trường. Một email giả từ “phòng đào tạo” gửi đúng tên, đúng khoa, đúng khóa học sẽ có tỷ lệ thành công rất cao.

Chiếm quyền tài khoản dây chuyền: 208 bộ thông tin đăng nhập cán bộ có thể được thử trên các hệ thống khác: email trường, cổng nội bộ, dịch vụ công. Tài khoản Phó Hiệu trưởng bị chiếm quyền có thể bị lợi dụng để di chuyển ngang (lateral movement) vào các hệ thống nhạy cảm hơn, và với quyền quản trị, khả năng gây thiệt hại là rất lớn.

Tổn hại tổ chức: Truy cập quản trị trái phép có thể cho phép sửa đổi hồ sơ sinh viên, kết quả học tập, hoặc thông báo chính thức. Một tài khoản bị chiếm quyền có thể thay đổi điểm số hoặc gửi thông báo giả cho toàn trường, và không ai biết đó không phải Phó Hiệu trưởng thật.

Người thân gặp rủi ro: 677 tài khoản lộ tên bố mẹ và năm sinh, dữ liệu có thể được sử dụng trong social engineering hoặc vượt qua xác minh danh tính. Sự phơi bày không dừng lại ở những người đã đăng ký mà lan ra cả gia đình họ.

8.4. Khung pháp lý: Luật Bảo vệ dữ liệu cá nhân Việt Nam

Việt Nam bảo vệ dữ liệu cá nhân thông qua hai tầng pháp luật: Nghị định 13/2023/NĐ-CP (có hiệu lực từ ngày 1 tháng 7 năm 2023) và Luật Bảo vệ dữ liệu cá nhân – Luật số 91/2025/QH15 (được thông qua ngày 26 tháng 6 năm 2025, có hiệu lực từ ngày 1 tháng 1 năm 2026). Kết hợp lại, chúng tạo thành khung pháp lý yêu cầu các tổ chức bảo vệ dữ liệu cá nhân, trao quyền kiểm soát thông tin cho công dân, và áp đặt chế tài nghiêm khắc đối với vi phạm.

Cả Trường Đại học X và Công ty Y đều đang vi phạm trực tiếp, có bằng chứng rõ ràng khung pháp lý này. Không cần phải diễn giải hay suy đoán gì cả, các vi phạm mang tính kiến trúc, có hệ thống, và đang diễn ra ngay lúc này.

Luật định nghĩa gì là dữ liệu được bảo vệ

Nghị định 13, Điều 2, Khoản 3 phân loại các thông tin sau là dữ liệu cá nhân cơ bản: họ tên, ngày sinh, giới tính, nơi sinh, nơi cư trú, quốc tịch, hình ảnh cá nhân, số điện thoại, số CMND/CCCD, và thông tin quan hệ gia đình. Từng loại một trong số này đã bị phơi bày trong cuộc điều tra, với hơn 80.000 cá nhân, mà không có bất kỳ kiểm soát truy cập nào.

Nghị định 13, Điều 2, Khoản 4 định nghĩa dữ liệu cá nhân nhạy cảm là dữ liệu mà khi bị vi phạm sẽ ảnh hưởng trực tiếp đến quyền và lợi ích hợp pháp của cá nhân, bao gồm quan điểm chính trị và tôn giáo, dữ liệu dân tộc, và dữ liệu về tiền án tiền sự. Cuộc điều tra này đã phơi bày dân tộc của 7.845 tài khoản và tôn giáo của 5.476 tài khoản.

Luật 91/2025, Điều 2 củng cố các định nghĩa này và bổ sung rằng dữ liệu cá nhân nhạy cảm được xác định theo danh mục do Chính phủ ban hành, và rằng ngay cả dữ liệu đã được định danh lại (de-identified), một khi được tái định danh, vẫn là dữ liệu cá nhân (Điều 2, Khoản 1).

Ai chịu trách nhiệm?

Cả hai văn bản pháp luật đều vạch ra cùng một ranh giới rõ ràng giữa hai vai trò:

• Bên Kiểm soát dữ liệu cá nhân: tổ chức quyết định mục đích và phương tiện xử lý dữ liệu cá nhân (Nghị định 13, Điều 2, Khoản 9; Luật 91, Điều 2, Khoản 7). Trường Đại học X là Bên Kiểm soát dữ liệu cá nhân. Trường quyết định thu thập dữ liệu sinh viên và cán bộ, quyết định lưu trữ những dữ liệu gì, và chọn triển khai nền tảng Connections. Dữ liệu thuộc về sinh viên và cán bộ của Trường Đại học X. Trách nhiệm bắt đầu từ đây.

• Bên Xử lý dữ liệu cá nhân: tổ chức xử lý dữ liệu thay mặt Bên Kiểm soát, thông qua hợp đồng hoặc thỏa thuận (Nghị định 13, Điều 2, Khoản 10; Luật 91, Điều 2, Khoản 8). Công ty Y là Bên Xử lý dữ liệu cá nhân. Họ xây dựng, lưu trữ, và vận hành nền tảng Connections chứa và phục vụ dữ liệu của Trường Đại học X. Họ là người quyết định rằng nền tảng không cần xác thực.

Những gì được yêu cầu – và không được thực hiện

Nghị định 13, Điều 26 yêu cầu các biện pháp bảo vệ dữ liệu phải được áp dụng ngay từ đầu và xuyên suốt toàn bộ vòng đời xử lý. Các biện pháp này phải bao gồm cả biện pháp tổ chức và kỹ thuật (Khoản 2). Nền tảng của Công ty Y không có biện pháp kỹ thuật nào: không xác thực, không kiểm soát truy cập, không mã hóa, API phục vụ dữ liệu cá nhân thô cho bất kỳ ai truy cập.

Nghị định 13, Điều 27 yêu cầu bên kiểm soát và bên xử lý phải kiểm tra an ninh mạng của hệ thống và thiết bị được sử dụng để xử lý dữ liệu cá nhân, và phải xóa hoặc tiêu hủy dữ liệu trên thiết bị không thể khôi phục (Khoản 4). Nền tảng không có kiểm tra an ninh mạng nào: bất kỳ trình duyệt nào cũng có thể truy vấn cơ sở dữ liệu trực tiếp.

Luật 91/2025, Điều 3 thiết lập các nguyên tắc cốt lõi: dữ liệu cá nhân chỉ được thu thập và xử lý trong phạm vi xác định, cho mục đích rõ ràng và hợp pháp (Khoản 2); phải triển khai các biện pháp thể chế, kỹ thuật, và nhân lực hiệu quả để bảo vệ dữ liệu cá nhân (Khoản 4); và tổ chức phải chủ động phòng ngừa, phát hiện, ngăn chặn, và xử lý kịp thời mọi vi phạm (Khoản 5). Công ty Y vi phạm từng nguyên tắc một, và Trường Đại học X không xác minh rằng bất kỳ nguyên tắc nào đang được tuân thủ.

Luật 91/2025, Điều 12 yêu cầu rõ ràng việc mã hóa dữ liệu cá nhân, tức chuyển đổi sang dạng không thể nhận diện mà không có giải mã (Khoản 1). Công ty Y làm điều ngược lại: họ lưu mật khẩu ở dạng plaintext và dữ liệu cá nhân trong phản hồi API thô, không mã hóa, ai cũng có thể truy cập.

Nghị định 13, Điều 38 quy định nghĩa vụ của Bên Kiểm soát dữ liệu: triển khai biện pháp tổ chức và kỹ thuật để chứng minh tuân thủ (Khoản 1), duy trì nhật ký xử lý (Khoản 2), báo cáo vi phạm theo Điều 23 (Khoản 3), chỉ chọn Bên Xử lý có biện pháp bảo vệ phù hợp (Khoản 4), và chịu trách nhiệm với chủ thể dữ liệu về thiệt hại do xử lý gây ra (Khoản 6). Trường Đại học X chọn Công ty Y làm Bên Xử lý mà không xác minh (hoặc bất chấp) sự vắng mặt hoàn toàn của các biện pháp bảo mật.

Nghị định 13, Điều 39 quy định nghĩa vụ của Bên Xử lý dữ liệu: chỉ nhận dữ liệu sau khi có hợp đồng hoặc thỏa thuận (Khoản 1), xử lý dữ liệu theo thỏa thuận đó (Khoản 2), triển khai đầy đủ mọi biện pháp bảo vệ theo quy định của nghị định (Khoản 3), và chịu trách nhiệm với chủ thể dữ liệu về thiệt hại gây ra trong quá trình xử lý (Khoản 4). Công ty Y thất bại ở mọi điểm.

Luật yêu cầu gì khi phát hiện vi phạm

Nghị định 13, Điều 23 quy định rằng khi phát hiện vi phạm bảo vệ dữ liệu, Bên Kiểm soát phải thông báo cho Bộ Công an (Cục An ninh mạng và Phòng, chống tội phạm sử dụng công nghệ cao) trong vòng 72 giờ theo Mẫu số 03 (Khoản 1). Bên Xử lý phải thông báo cho Bên Kiểm soát sớm nhất có thể (Khoản 2). Thông báo phải bao gồm: bản chất vi phạm, thời gian và địa điểm, các loại dữ liệu cá nhân bị ảnh hưởng, số lượng chủ thể dữ liệu liên quan, và các biện pháp đã thực hiện để khắc phục thiệt hại (Khoản 3).

Luật 91/2025, Điều 23 tăng cường yêu cầu này: khi phát hiện vi phạm có thể gây hại cho an ninh quốc gia, trật tự xã hội, tính mạng, sức khỏe, danh dự, nhân phẩm, hoặc tài sản của chủ thể dữ liệu, việc thông báo cho cơ quan bảo vệ dữ liệu phải diễn ra trong vòng 72 giờ (Khoản 1). Bên Kiểm soát phải lập báo cáo sự cố chính thức và hợp tác với cơ quan chức năng để xử lý vi phạm (Khoản 2).

Luật 91/2025, Điều 21 yêu cầu Bên Kiểm soát và Bên Xử lý phải chuẩn bị và duy trì Đánh giá tác động xử lý dữ liệu, nộp cho cơ quan bảo vệ dữ liệu trong vòng 60 ngày kể từ khi bắt đầu xử lý dữ liệu (Khoản 1). Đánh giá này phải được cập nhật hàng năm (Khoản 2) và phải luôn sẵn sàng cho Bộ Công an kiểm tra (Nghị định 13, Điều 24, Khoản 4). Không có bằng chứng rằng Trường Đại học X hoặc Công ty Y đã nộp đánh giá như vậy.

Hậu quả là gì?

Luật 91/2025 không để lại chỗ cho sự mơ hồ về chế tài. Điều 8 quy định rõ:

• Vi phạm có thể bị xử lý kỷ luật, xử phạt hành chính, hoặc truy cứu trách nhiệm hình sự tùy theo tính chất và mức độ nghiêm trọng (Khoản 1).
• Đối với cá nhân mua bán hoặc buôn bán dữ liệu cá nhân trái phép: phạt tới 10 lần doanh thu thu được từ vi phạm (Khoản 3).
• Đối với tổ chức vi phạm quy định chuyển dữ liệu xuyên biên giới: phạt tới 5% doanh thu hàng năm tại Việt Nam (Khoản 4).
• Đối với các vi phạm bảo vệ dữ liệu khác: mức phạt hành chính tối đa 3 tỷ đồng (~120.000 USD) cho tổ chức (Khoản 5).
• Cá nhân vi phạm tương tự chịu mức phạt tối đa bằng một nửa mức phạt tổ chức (Khoản 6).
• Nếu vi phạm gây thiệt hại, bồi thường là bắt buộc theo quy định pháp luật (Khoản 1).

Nghị định 13, Điều 4 bổ sung rằng vi phạm có thể bị xử lý qua biện pháp kỷ luật, chế tài hành chính, hoặc truy cứu hình sự tùy theo mức độ nghiêm trọng.

80.053 chủ thể dữ liệu có quyền đòi hỏi gì

Quyền của chủ thể dữ liệu không phải lý thuyết suông. Chúng có thể thi hành:

• Quyền được biết về các hoạt động xử lý dữ liệu (Luật 91, Điều 4, Khoản 1a; Nghị định 13, Điều 9, Khoản 1)
• Quyền rút lại sự đồng ý (Luật 91, Điều 4, Khoản 1b; Nghị định 13, Điều 9, Khoản 2)
• Quyền truy cập và chỉnh sửa dữ liệu (Luật 91, Điều 4, Khoản 1c; Nghị định 13, Điều 9, Khoản 3)
• Quyền yêu cầu xóa và hạn chế xử lý (Luật 91, Điều 4, Khoản 1d; Nghị định 13, Điều 9, Khoản 5–6)
• Quyền khiếu nại, khởi kiện, và yêu cầu bồi thường thiệt hại (Luật 91, Điều 4, Khoản 1đ; Nghị định 13, Điều 9, Khoản 9–10)
• Quyền yêu cầu cơ quan có thẩm quyền và tổ chức liên quan triển khai biện pháp bảo vệ dữ liệu (Luật 91, Điều 4, Khoản 1e)

Mỗi người trong 80.053 cá nhân bị phơi bày đều có các quyền này. Mỗi người đều có thể yêu cầu Trường Đại học X và Công ty Y trả lời. Mỗi người đều có thể yêu cầu dữ liệu của mình được bảo mật, được thông báo về sự cố vi phạm, và được bồi thường thiệt hại.

Kết luận pháp lý

Trường Đại học X không thể núp sau Công ty Y. Pháp luật quy định rõ ràng Bên Kiểm soát phải chịu trách nhiệm trong việc lựa chọn Bên Xử lý có biện pháp bảo vệ phù hợp (Nghị định 13, Điều 38, Khoản 4) và chịu trách nhiệm bồi thường thiệt hại (Nghị định 13, Điều 38, Khoản 6). Bằng việc thuê ngoài nền tảng cho một nhà cung cấp hoàn toàn không có kiến trúc bảo mật, Trường Đại học X không thuê ngoài trách nhiệm, mà khuếch đại trách nhiệm pháp lý của mình.

Công ty Y không thể viện cớ không biết. Họ xây dựng nền tảng, họ quyết định rằng JavaScript phía client là đủ để bảo mật, họ chọn trả về mật khẩu trong phản hồi API, và họ không mã hóa dữ liệu cá nhân như Luật 91, Điều 12 yêu cầu. Mọi quyết định kiến trúc dẫn đến sự phơi bày này đều là của họ.

Pháp luật yêu cầu họ hành động, không phải lúc nào thuận tiện, không phải khi nào muốn, mà ngay bây giờ:

• Thông báo cho Bộ Công an trong vòng 72 giờ kể từ khi phát hiện vi phạm.
• Chuẩn bị và nộp Đánh giá tác động xử lý dữ liệu.
• Triển khai xác thực, kiểm soát truy cập, và mã hóa thực sự.
• Thông báo cho toàn bộ 80.053 cá nhân bị ảnh hưởng.
• Loại bỏ ngay lập tức thông tin đăng nhập bị lộ khỏi API.
• Thực hiện kiểm toán bảo mật toàn diện nền tảng Connections, không chỉ triển khai tại Trường Đại học X, mà toàn bộ khách hàng đang chạy trên cùng kiến trúc.

80.053 người đã tin tưởng Trường Đại học X với dữ liệu cá nhân của họ. Sự tin tưởng đó được ủy thác cho Công ty Y. Cả hai đều thất bại. Pháp luật nói rằng sự thất bại đó có hậu quả. Đã đến lúc những hậu quả đó được thực thi.

9. Kết luận

Ở Phần 1, tôi phát hiện 896 thẻ căn cước bị lộ qua cổng thi của một trường đại học. Câu hỏi tiếp theo, “còn nền tảng lớn hơn thì sao?”, dẫn đến câu trả lời mà tôi ước mình đã không tìm thấy: 80.053 tài khoản, mật khẩu nằm trong API cho cả sinh viên lẫn cán bộ, và cả hai loại tài khoản đều bị chiếm quyền chỉ bằng cách đọc một trường dữ liệu.

Nguyên nhân gốc không thay đổi từ Phần 1, vẫn là cùng lỗi kiến trúc: nền tảng Connections của Công ty Y không triển khai bất kỳ cơ chế xác thực hay phân quyền phía server nào. Framework JavaScript chạy trong trình duyệt người dùng là thứ duy nhất đứng giữa khách truy cập và cơ sở dữ liệu, và đó không phải ranh giới bảo mật, đó là sự vắng mặt của ranh giới.

Nhưng điều khiến tôi trăn trở nhất không phải con số hay kỹ thuật, mà là trường mật khẩu. Lưu trữ thông tin đăng nhập trong phản hồi API mà client có thể truy cập, dù đã che, không phải lỗi thiết kế đơn thuần. Đó là sự hiểu lầm căn bản về cách hệ thống xác thực nên hoạt động. Mật khẩu không bao giờ được rời khỏi server, dưới bất kỳ dạng nào, trong bất kỳ hoàn cảnh nào. Và việc thuật toán che có thể bị dịch ngược bằng dữ liệu từ chính phản hồi đó nâng mức độ từ rò rỉ dữ liệu lên thành xâm phạm toàn bộ hệ thống xác thực.

Phản hồi ban đầu của nhà cung cấp, xóa một số giá trị trường và thêm mật mã thay thế phía client, cho thấy một khuôn mẫu đáng lo ngại: chữa triệu chứng nhìn thấy mà bỏ qua nguyên nhân gốc. Tại lần kiểm tra lại ngày 10 tháng 3, 7 trên 10 vector tấn công vẫn có thể khai thác, và nền tảng mạng nội bộ không nhận được bất kỳ thay đổi bảo mật nào. (Xem Mục 10 cho bản cập nhật ngày 23 tháng 6, khi nhà cung cấp đã triển khai xác thực phía server và khắc phục lỗ hổng cốt lõi.)

Tôi biết rằng đằng sau 80.053 ID tài khoản là con người thật. Sinh viên đã tin tưởng trường đại học với thông tin cá nhân của mình, cựu sinh viên mong đợi dữ liệu của mình được bảo mật sau khi rời trường, và cả sinh viên lẫn cán bộ đều có thông tin đăng nhập bị phơi bày cho bất kỳ ai muốn xem. Tài khoản của một sinh viên và một Phó Hiệu trưởng đều bị chiếm quyền không bằng exploit tinh vi mà bằng cách đọc một trường trong phản hồi API rồi gõ nó vào form đăng nhập. Nếu tôi, một người nghiên cứu bảo mật với ý định tốt, có thể làm được điều này, thì bất kỳ ai cũng có thể.

Bản vá mà nền tảng này cần không phải thêm một lớp che giấu phía client, mà là triển khai những gì đáng lẽ phải tồn tại từ ngày đầu: xác thực phía server, kiểm soát truy cập dựa trên vai trò, và nguyên tắc cơ bản rằng cơ sở dữ liệu không nên trả lời câu hỏi từ người lạ.

10. 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, mười ngày sau khi báo cáo này được công bố, tôi kiểm tra lại toàn bộ các vector tấn công trên cả hai nền tảng. Công ty Y đã cập nhật mã nguồn ngay trong ngày đó (phiên bản 14484523062026), và kết quả khác biệt đáng kể so với lần kiểm tra ngày 10 tháng 3.

Những gì đã thay đổi

Bản sửa quan trọng nhất mang tính kiến trúc: cổng API XHR giờ đã thực thi xác thực phía server. Cả connections.universityx.vn/xhr/ lẫn endpoint phụ tại 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 quan sát thấy kiểm soát truy cập phía server trên nền tảng này.

Với cổng API bị khóa, các hệ quả kéo theo là tức thì:

• IDOR tài khoản không còn hoạt động. Toàn bộ các ID tài khoản được kiểm tra (bao gồm dải gốc 7.787–215.212) đều trả về null. Cơ sở dữ liệu không còn trả lời câu hỏi từ người lạ.
• Lộ mật khẩu đã được loại bỏ. Với bản ghi tài khoản bị chặn, trường mật khẩu (ợ) không còn truy cập được. 208 bộ thông tin đăng nhập cán bộ được ghi nhận trong báo cáo này không còn truy xuất được nữa.
• Liệt kê hàng loạt bị chặn trên connections.universityx.vn. Endpoint tải hàng loạt trả về mảng rỗng.
• Mật mã b6x đã bị gỡ bỏ khỏi tec.universityx.vn. Lớp mật mã thay thế đơn bảng được ghi nhận trong Mục 7.2 đã biến mất hoàn toàn.

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

Framework JavaScript và việc tự tạo phiên vẫn bị lộ trên cả hai nền tảng. Khách truy cập ẩn danh vẫn nhận được session ID và truy cập vào toàn bộ bề mặt API phía client. Tuy nhiên, đây là lỗ hổng mức độ thấp khi đứng riêng, vì chúng chỉ trở nên nguy hiểm khi kết hợp với truy cập dữ liệu, thứ giờ đã bị chặn.

Trên tec.universityx.vn (hệ thống thi từ Phần 1), bản sửa chưa hoàn chỉnh:

Bảng điểm

Vậy đã đủ an toàn chưa?

Với connections.universityx.vn, nền tảng được ghi nhận trong báo cáo này: có, lỗ hổng nghiêm trọng đã được khắc phục. 80.053 tài khoản và mật khẩu cán bộ không còn truy cập được bởi người dùng không xác thực. Nhà cung cấp đã chuyển từ “không có bảo mật” sang “thực thi xác thực phía server tại cổng API,” đây là bản sửa kiến trúc đúng hướng thay vì thêm một lớp che giấu phía client.

Tuy nhiên, bản sửa là một cổng xác thực được gắn thêm vào kiến trúc hiện có, không phải thiết kế lại từ đầu. Framework phía client vẫn tải, phiên vẫn được tự tạo, và mô hình dữ liệu bên dưới có lẽ vẫn trả về tất cả các trường cho người dùng đã xác thực mà không phân quyền theo vai trò. Một phiên đã xác thực bị xâm phạm hoặc có đặc quyền thấp vẫn có thể truy cập nhiều dữ liệu hơn mức cần thiết. Một cuộc kiểm toán bảo mật đầy đủ cần xác minh rằng kiểm soát truy cập sau xác thực cũng chặt chẽ tương đương.

Với tec.universityx.vn, bức tranh còn lẫn lộn. Hệ thống thi vẫn rò rỉ dữ liệu thí sinh một phần và đã bị hồi quy về truy cập ảnh CDN. Các phát hiện từ Phần 1 chưa được giải quyết hoàn toàn.

Nhà cung cấp đã có tiến bộ thực sự. Nhưng liệu tiến bộ đó đã đủ hay chưa phụ thuộc vào việc họ có tiếp tục hay không: khuôn mẫu cho đến nay là vá lỗi từng bước để phản ứng với các báo cáo được công bố, thay vì rà soát bảo mật toàn diện nền tảng. Bước tiếp theo nên là một cuộc kiểm thử xâm nhập chuyên nghiệp trên bề mặt tấn công sau xác thực, điều nằm ngoài phạm vi của nghiên cứu này.

Phụ lục

A. Dòng thời gian Công bố có Trách nhiệm

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

C. Tóm tắt Nguồn Dữ liệu

Tất cả thống kê trong báo cáo này được trích xuất từ các tập dữ liệu sau:

Tổng các tập con: 21.393 + 57.588 + 562 + 166 + 344 = 80.053 (khớp chính xác tập dữ liệu chính).

D. Thuật ngữ

E. Bản ghi Tài khoản Mẫu (Đã biên tập)

{
  "account_id": "[REDACTED]",
  "ho_ten": "[REDACTED]",
  "ngay_sinh": "xx/xx/1999",
  "gioi_tinh": "Nữ",
  "sdt": "098XXXXXXX",
  "email": "[redacted]@gmail.com",
  "cmnd_cccd": "001XXXXXXXXX",
  "que_quan": "[Tỉnh]",
  "ma_sinh_vien": "19XXXXXX",
  "khoa": "Khoa [REDACTED]",
  "nganh": "[REDACTED]",
  "khoa_hoc": "20xx-20xx",
  "loai_tk": "0"
}

F. Bảng Thống kê Chi tiết

Phụ lục này chứa các bảng thống kê chi tiết được tham chiếu trong Mục 3.5.

Phân bố Tên miền Email (29.640 địa chỉ email):

Phân bố Giới tính:

Phân bố Địa lý – 15 quê quán nhiều nhất (trong 50.042 có dữ liệu):

10 Khoa lớn nhất:

41.340 tài khoản có dữ liệu khoa, trải rộng trên 42 tên khoa.

10 Ngành lớn nhất:

41.226 tài khoản có dữ liệu ngành, trải rộng trên 56 chương trình.

Loại hình đào tạo:

Năm nhập học – Top 10:

39.768 tài khoản có dữ liệu năm nhập học, trải dài từ K2008 đến K2025.

Tình trạng Sinh viên:

Dân tộc – 7.845 tài khoản:

Quốc tịch – 5.655 tài khoản: 5.621 Việt Nam, cùng 34 công dân nước ngoài từ Trung Quốc, Nhật Bản, Indonesia, Hàn Quốc, Thái Lan, Philippines, Đài Loan, New Zealand, và các nước khác.

Tôn giáo – 5.476 tài khoản: 5.134 không, 215 Phật giáo, 104 Công giáo, 14 Tin lành, 8 khác, 1 Cơ đốc giáo.

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

Update (June 23, 2026): Partially remediated

Company Y has added server-side authentication on the XHR API gateway and blocked account-level IDOR. However, partial candidate data remains accessible, bulk ID enumeration still works, and CDN image access has regressed. See revalidation details below.

CVSS 3.1: 9.1 (CRITICAL)

Vulnerability allows unauthenticated extraction of identity and biometric data.

Summary

University X is one of Vietnam’s well-known public universities, with roughly 40,000 students across multiple faculties. Its Testing Center administers standardized language proficiency exams for hundreds of candidates each cycle. To register, candidates must submit deeply personal information: full legal name, date of birth, phone number, email, national ID (CCCD) number, and critically, high-resolution photos of the front and back of their government-issued identity cards. This data, if exposed, represents a complete identity dossier that cannot be “reset” like a password.

The discovery began with a routine Google search. A query for exam-related keywords returned a direct link to the Testing Center’s website, and clicking through revealed a candidate’s complete registration profile including their CCCD number and photos of their physical identity card publicly displayed on an open webpage. No login was required. No special tools. Just a Google search and a click.

Through reverse engineering the platform’s JavaScript framework, I confirmed that this was not an isolated incident. The entire system, built by a third-party vendor called Company Y on their “Connections” SaaS platform, had zero access controls separating public visitors from the database. All 896 candidates’ personal data including CCCD/CMND numbers, ethnicity, place of birth, and front and back photos of their national ID cards could be systematically extracted by anyone with a web browser.

1. Introduction

1.1. Background

University X is one of Vietnam’s well-known public universities, home to roughly 40,000 students across multiple faculties. It is particularly recognized for its foreign language and international studies programs. The university’s Testing Center operates a web system at tec.universityx.vn to administer standardized language proficiency exams such as VSTEP (Vietnamese Standardized Test of English Proficiency) for hundreds of candidates each cycle. The system handles the entire exam lifecycle: registration, room assignment, candidate list publication, and result announcements.

During registration, candidates must submit deeply personal information: full legal name, date of birth, phone number, email address, national ID (CCCD) number, ethnicity, and critically, high-resolution photos of the front and back of their government-issued identity cards. This data, if exposed, represents a complete identity dossier for each individual – one that, unlike a compromised password, can never be changed or revoked.

1.2. Third-Party Platform: Company Y

Like many Vietnamese institutions, University X does not build or maintain its own software. Instead, the entire exam management system including the database, API (Application Programming Interface) layer, file storage, and CDN (Content Delivery Network) runs on a SaaS platform called “Connections,” developed and operated by Company Y (companyy.com).

This means University X handed over complete control of their candidates’ most sensitive data to an external vendor. The university likely trusts that this platform has proper security measures in place. The question this report answers: does it?

The answer is no. The Connections platform provides no access control boundary whatsoever between a random internet visitor and the personal data stored in its database.

1.3. Motivation: Discovery via Google Search

It started with a simple Google search. Searching for exam-related keywords returned a direct link to the Testing Center’s website. Clicking through revealed a candidate’s complete registration form: full name, date of birth, CCCD number, and even photos of their physical identity card – all displayed on a public webpage.

No login was required. No special tools. Just a Google search and a click.

This raised the critical question: was this one candidate’s data accidentally exposed, or was every single candidate’s personal information wide open?

The answer, as this report demonstrates, is the latter.

Figure 1: Google search results revealing candidate registration data including full name, date of birth, and CCCD number – publicly indexed and accessible to anyone.

1.4. Scope and Ethics

The research was conducted strictly for security assessment purposes:

• All data access used publicly available endpoints.
• No authentication was bypassed - because none existed to bypass.
• No data was modified, deleted, or exfiltrated to third parties.
• No brute-force attacks were performed against protected resources.
• The techniques described replicate what any internet user with basic technical knowledge could perform through a web browser’s developer console.

1.5. Technical Attack Classification

The following MITRE ATT&CK techniques and OWASP categories are relevant to the methods used in this research:

2. Infrastructure Mapping: University X, Company Y, and Connections

Before diving into the vulnerability, it is important to understand who actually runs this system and how the pieces fit together. The Testing Center’s website is not what it appears to be on the surface.

2.1. Discovering the Vendor Relationship

The first step in the analysis was understanding who actually operates the infrastructure behind tec.universityx.vn. Inspecting the HTML source revealed that the web application loads its core JavaScript framework from external domains:

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

The domain companyy.com belongs to Company Y, a technology company in Vietnam. Further analysis revealed a sprawling multi-domain infrastructure:

2.2. “Connections” Platform Architecture

The “Connections” platform appears to be a general-purpose SaaS framework similar to Salesforce or Airtable – providing:

• A database layer where tables are identified by 32-character hexadecimal hashes
• A client-side JavaScript framework with Vietnamese API functions (xửLý, CĂN.db, config)
• A file storage CDN at local.{org}.connections.vn
• An image CDN at i{N}.connections.vn with encoded URL parameters
• A multi-tenant architecture where multiple organizations (University X, and potentially others) share the same infrastructure

The critical security implication: University X’s candidate data including ID card photos is stored on and served by Company Y’s shared infrastructure, not on servers controlled by University X.

2.3. Subdomain Structure and Data Flow

User's Browser
    |
    |-- (1) GET tec.universityx.vn/page
    |         |-- Loads HTML skeleton
    |
    |-- Loads JS from cdn.companyy.com
    |         |-- Loads CSS from thuctap.companyy.com
    |
    |-- (2) XHR to xhr.companyy.com/xhr/ (or connections.universityx.vn/xhr/)
    |
    |-- "doiTuong.tai.{table_hash}" = database query
    |         |-- Returns list of object IDs
    |
    |-- (3) XHR to xhr.companyy.com/xhr/
    |         |-- "CAN.db({table}.{id})" = load object
    |
    |-- Returns ALL fields including CCCD, phone number, etc.
    |
    |-- (4) GET local.universityx.connections.vn/upload/{cat}/{date}/{file}
    |
    |-- Downloads PDF files (candidate lists)
    |
    |-- (5) GET i0.connections.vn/{encoded_path}?q={encoded_token}
              |-- Downloads ID card photos (front/back)

None of these requests require authentication.

3. Reverse Engineering the Database Structure

The next step was understanding how the database is organized. This involved reading the website’s JavaScript code, which turned out to be written entirely in Vietnamese, and discovering that database table identifiers and record IDs are passed around without any security checks.

3.1. Phase 1: URL Structure Analysis

The initial URL indexed by Google provided the first clue about the database structure:

https://tec.universityx.vn/7fdc5fa41f345xxxx4bba6b0d3e449385/1518250/2368M35018
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^  ^^^^^^^  ^^^^^^^^^^
                    Table hash (Registration)         Obj ID   File number

This URL directly exposes:

1. Registration table hash: 7fdc5fa41f345xxxx4bba6b0d3e449385
2. Registration object ID: 1518250
3. Candidate’s file number: 2368M35018

3.2. Phase 2: Reverse Engineering the JavaScript Framework

The framework source at cdn.companyy.com/js/include.core.isj is heavily minified and uses Vietnamese identifiers. Through runtime analysis (executing functions in the browser console and observing XHR traffic), I identified the core API functions:

3.3. Phase 3: Discovering Database Schema via IDOR

The key discovery was that the API uses Insecure Direct Object References (IDOR): database table hashes and object IDs are passed directly from client to server with no authorization checks. This allowed me to:

1. Obtain the Registration table hash (visible in the URL)
2. Query the Registration table using xửLý("đốiTượng.tải.{hash}", ...) with arbitrary field filters
3. Load a Registration object and inspect all its fields – discovering field IDs, data types, and foreign key references
4. Discover the Candidate table hash by following the foreign key in field 1686869 (Candidate ID), which references objects in table 3576ff3533bb4xxxx8e394a0aa83a461f
5. Load Candidate objects to access the full set of personal data fields

3.4. Phase 4: Field-by-Field Mapping

Each database object is returned as a dictionary with numeric string keys (field IDs). I mapped them by:

1. Loading multiple candidate objects
2. Cross-referencing field values with rendered page content
3. Identifying field types (string, integer, date, reference, file)

Field Type System

The framework uses single Vietnamese characters to mark field types in stored values:

The "ậ" (reference) type stores a pointer to a lookup object for example, the ethnicity field 1626773 stores {"ậ":["146992"]}, which resolves to “Kinh” when the page renders. The "ị" (file) type stores a pointer to an uploaded file for example, field 1658487 stores {"ị":["4296"]}, which resolves to a CCCD photo on the image CDN.

Registration Table Field Map (Reverse Engineered)

Candidate Table Field Map (Reverse Engineered)

3.5. Phase 5: Foreign Key Traversal Diagram

The complete traversal path from a public URL to ID card photos:

+-------------------------------------------+
|           Public URL                      |
|  tec.universityx.vn/{hash}/{id}/{file}           |
+---------------------+---------------------+
                      |
          exposes table hash + object ID
                      |
                      v
+-------------------------------------------+
|        Registration Object                |
|  Table: 7fdc5fa4...                       |
|  Contains SBD, file number                |
+---------------------+---------------------+
                      |
           foreign key field 1686869
                      |
                      v
+-------------------------------------------+
|        Candidate Object                   |
|  Table: 3576ff35...                       |
|  Contains ALL PII                         |
+----------+----------------+---------------+
           |                |
           v                v
+-------------------+  +----------------------+
| Personal Data     |  | ID Card Photos       |
| CCCD, Phone,      |  | Front + Back         |
| Email, Ethnicity, |  | on i0.connections.vn  |
| Place of Birth    |  |                      |
+-------------------+  +----------------------+

4. CDN Discovery: Image and File Infrastructure

Identity card photos are stored on a separate image server, not in the database itself. Understanding how these image URLs are generated was key to proving that photos could be downloaded in bulk by anyone.

4.1. Static File CDN: local.universityx.connections.vn

All uploaded documents (PDFs, candidate lists) are stored on a static file server with a predictable URL structure:

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

File metadata including all URL components is embedded in the main page’s HTML as a cached JSON blob. The metadata uses minified Vietnamese field names:

I discovered 32 candidate list PDFs by parsing this metadata and filtering for filenames containing “danh sach” or “phong thi.” I encountered a critical bug: JSON-escaped forward slashes in the date path (2024\/09\/19) caused HTTP 404 errors until I added path unescaping logic to the code.

4.2. Image CDN: i{N}.connections.vn

The most sensitive discovery was the image CDN infrastructure. ID card photos are served from a load-balanced CDN with nodes i0.connections.vn, i3.connections.vn, etc.

Encoded Image URLs

Unlike the static file CDN (which uses human-readable paths), the image CDN uses encoded/obfuscated paths and query parameters:

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

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

# Portrait photo:
https://i0.connections.vn/kt3PG1hPTgTPG1MJ.u54.L8JKx-X.LDJ9Ei
  tREHdGaAN9ZWP6gM46Wbb?q=wqQ2KLBn6g3dDaf29mOnD7stDafo9aAo...

Key observations about URL structure:

• The URL path encodes the file reference - different images for the same candidate differ by a few characters in the path
• The q= query parameter appears to be a session or authentication token, but is identical across all images in a single page load, suggesting it is a page-level token rather than per-image
• These URLs cannot be guessed - they can only be obtained by rendering a candidate’s detail page in a browser (the JavaScript framework generates them at runtime)
• However, once the page is rendered, these URLs can be downloaded directly via simple HTTP GET without any additional cookies or headers

How Image URLs Are Generated

The JavaScript framework generates image CDN URLs during page rendering through the following process:

1. Reads the file reference field (e.g., {"ị":["4296"]})
2. Encodes the file ID, organization context, and a session token into the URL path and query string
3. Assigns the URL as a CSS background-image attribute on a <div> element

This means image URLs cannot be constructed programmatically from file IDs alone – the JavaScript framework’s encoding algorithm must be executed in a browser environment. My tool solves this by rendering each candidate’s page in a headless browser and extracting background-image URLs from the DOM.

Image Download Verification

Downloaded images were verified as actual ID card photos:

• File sizes ranged from 44KB to 228KB (consistent with phone camera photos of ID cards)
• Valid JPEG image files
• Three images per candidate (typically): portrait photo, CCCD front, CCCD back
• Images contain readable text including the candidate’s name, CCCD number, date of birth, and address printed on the physical card

Figure 3: File explorer showing 2,600+ downloaded national ID card photos (portrait, front, and back) of exam candidates.

5. Complete Attack Chain

Here is the complete chain of steps, from the initial Google discovery to downloading all 896 candidates’ identity card photos. Each step builds on the previous one, and none of them require any form of authentication.

5.1. Overview

The attack chain combines multiple techniques to escalate from a single Google result to full PII extraction including ID card photos:

1. Google Dorking (Reconnaissance)
2. Source Code Analysis (Framework Identification)
3. JavaScript API Reverse Engineering (Schema Discovery)
4. IDOR Exploitation (Database Traversal)
5. Foreign Key Traversal (Cross-Table Access)
6. PDF Metadata Extraction (Seed Data Collection)
7. Headless Browser API Injection (Bulk Extraction) – A headless browser is a web browser running in the background without a graphical interface, enabling automation (e.g., Playwright, Puppeteer)
8. DOM Scraping (Reference Resolution + Image Harvesting)
9. CDN Image Download (ID Card Photo Extraction)

5.2. Step 1: Google Dorking - Initial Discovery

A routine Google search containing a candidate’s name and University X-related keywords returned a direct link to the Testing Center website:

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

The rendered page displayed the full exam registration form including the CCCD number, date of birth, ethnicity, contact information, and ID card photos.

5.3. Step 2: Source Code Analysis - Identifying Company Y

Inspecting the page source revealed:

• JavaScript loaded from cdn.companyy.com (Company Y)
• CSS loaded from thuctap.companyy.com
• API calls to xhr.companyy.com and connections.universityx.vn
• Framework configuration at tts.companyy.vn/nguyendinhhuy
• Vietnamese function names (xửLý, CĂN.db, config)

5.4. Step 3: Reverse Engineering the JavaScript Framework API

Using the browser’s developer console, I probed the framework’s global scope:

> typeof xuLy       // "function" main API handler
> typeof CAN.db     // "function" database loader
> typeof config     // "function" config retriever
> typeof duLieu     // "object"   page data context
> CAN               // {fn, khoa, lib, js, db, _db}

By intercepting XHR traffic in the Network tab while loading a candidate page, I observed the request/response pattern:

POST https://xhr.companyy.com/xhr/
  Request:  {action: "doiTuong.tai.7fdc5fa4...", d: {thuocTinh: {...}}}
  Response: ["1518250", "1518251", ...]  // List of Object IDs

5.5. Step 4: IDOR + Foreign Key Traversal

With the API functions identified, I exploited IDOR to traverse the database:

// 1. Find Registration by SBD (exam seat number from PDF)
xuLy("doiTuong.tai.7fdc5fa41f345xxxx4bba6b0d3e449385",
  {d: {thuocTinh: {"1642331": "AN1001"}}}, {}, function(ids) {
    console.log(ids);
    // ["1518250"]
  });

// 2. Load Registration object -> discover Candidate table
CAN.db("7fdc5fa41f345xxxx4bba6b0d3e449385.1518250", function() {
  var reg = config("7fdc5fa41f345xxxx4bba6b0d3e449385.1518250");
  console.log(reg["1686869"]);  // "582319" (Candidate ID)
  // Candidate table hash discovered from foreign key relationship
});

// 3. Load Candidate object -> access ALL personal data
CAN.db("3576ff3533bb4xxxx8e394a0aa83a461f.582319", function() {
  var c = config("3576ff3533bb4xxxx8e394a0aa83a461f.582319");
  console.log(c["1646777"]);  // "0222xxxx2576" (CCCD number)
  console.log(c["1626788"]);  // "098xxxx321"   (Phone number)
  console.log(c["1626793"]);  // "email@example.com"
  console.log(c["1626773"]);  // {"ậ":["146992"]}  (Ethnicity reference)
  console.log(c["1658487"]);  // {"ị":["4296"]}     (CCCD front photo)
  console.log(c["1658488"]);  // {"ị":["243"]}      (CCCD back photo)
});

5.6. Step 5: Seed Data Extraction from PDFs

To enumerate all candidates, I extracted the list of SBD (exam seat numbers) from 32 publicly accessible PDF files. PDF metadata was embedded in the website’s HTML as a cached JSON object with abbreviated Vietnamese field names. After unescaping JSON-encoded paths, all PDFs were downloadable from the static file CDN at local.universityx.connections.vn. Result: 896 unique SBDs extracted from 32 PDFs.

5.7. Step 6: Automated Bulk Extraction

I developed a Python tool (crawl_xxxx.py) that automates the entire chain using Playwright (headless Chromium browser):

# Each worker runs 2 browser pages:
#   api_page:    stays on /dangkythi for fast JS API calls
#   render_page: navigates to each candidate's detail page

def lookup_sbd(api_page, render_page, sbd):
    # Fast API lookup (~2 seconds)
    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, phone, email, workplace now retrieved

    # Render page for references + images (~20 seconds)
    render_page.goto(f"tec.universityx.vn/{REG_TABLE}/{reg_id}/{file_num}")
    # Smart wait: wait until "Dan toc" text appears
    # -> Extract ethnicity, place of birth from DOM text
    # -> Extract image URLs from CSS background-image attributes
    # -> Download ID card photos from connections.vn CDN

Figure 2: Spreadsheet of extracted candidate data including names, registration numbers, CCCD numbers, dates of birth, emails, phone numbers, ethnicity, and place of birth demonstrating the scale of the data exposure.

5.8. Step 7: Parallel Execution with Adaptive Throttling

The tool supports 3 parallel workers by default, each with its own Playwright browser instance (for thread safety). If the server starts rejecting requests (3 consecutive failures), the tool automatically falls back to a single worker:

Workers: 3 (Default)
    |
    +-- Worker 1: Browser + 2 pages (api + render)
    +-- Worker 2: Browser + 2 pages (api + render)
    +-- Worker 3: Browser + 2 pages (api + render)
    |
[3 consecutive failures on any worker]
    |
    v
Workers: 1 (Fallback)
    +-- Worker 1: Browser + 2 pages (api + render)

5.9. Step 8: Graceful Error Handling

The tool implements multiple robust recovery mechanisms:

• Ctrl+C Handling: When interrupted, the tool immediately saves all collected data to CSV before exiting.
• Network Error Recovery: On timeout, the tool resets the browser session and continues.
• Periodic Saving: Flushes data to CSV every 10 candidates to minimize data loss.
• Resume Support: On restart, the tool reads the existing CSV file and skips already-processed SBDs.
• Reference Caching: Ethnicity and Place of Birth lookups are cached (there are only ~54 ethnic groups and ~63 provinces in Vietnam), so page rendering becomes unnecessary for previously encountered reference IDs.

6. Results: Extracted Data

6.1. Data Volume

6.2. Extracted Data Fields per Candidate

6.3. Output Directory Structure

output/
  candidates_phase1.csv     # 896 candidates (SBD, name, DOB, gender, scores)
  candidates_phase2.csv     # 896 candidates (+ CCCD, phone, email, ethnicity,
                            #   place of birth, image paths)
  candidates_full.csv       # Final merged complete dataset
  images/
    AN1001_front.jpg        # ID card front photo
    AN1001_back.jpg         # ID card back photo
    AN1001_extra.jpg        # Portrait/additional candidate photo
    AN1002_front.jpg
    ...                     # ~2,600 images total
  pdfs/                     # 32 original candidate list PDFs
  file_index.json           # PDF file index metadata

7. Detailed Data Analysis

This section presents statistical analysis of the 896 candidate records extracted from candidates_phase2.csv. All statistics were computed programmatically from the raw data.

7.1. Demographics

• Total candidates: 896 unique individuals
• Gender: 661 Female (73.8%), 235 Male (26.2%)
• Age range (birth years): 1969–2005 (37-year span)
• Median birth year: ≈ 2000 (most common: 2000 with 234 candidates, followed by 1998 with 117 and 1999 with 102)
• The 3:1 female-to-male ratio and concentration around 1998–2002 birth years are entirely consistent with the profile of foreign language proficiency exam candidates at a university specializing in foreign languages.

7.2. Data Completeness

The 7 core PII fields (name, date of birth, gender, CCCD, phone number, email, file number) all have a 100% fill rate. The low workplace fill rate (15.1%) suggests most candidates are students who left this non-required field blank.

7.3. Email Domain Analysis

The 3 instances of the gmail.con typo and the 87 students using their student ID as a prefix for University X email ({student_id}@s.universityx.edu.vn) are noteworthy: the typos confirm this is real user-entered data, while the latter pattern inadvertently creates a secondary channel exposing student ID numbers.

7.4. CCCD/CMND Format Analysis

Vietnam has issued identification documents in three formats, all of which appear in this dataset:

6 duplicate CCCD numbers were found (each appearing in 2 registrations), indicating candidates who registered for exams multiple times. This confirms these are real registration records spanning from September 2024 to February 2026.

7.5. Geographic Distribution

The first 3 digits of a 12-digit CCCD encode the province of issuance. Among the 474 new-format CCCDs:

The distribution is heavily concentrated in the Red River Delta region in northern Vietnam, consistent with University X’s location in Hanoi. Hanoi-based candidates alone account for 30.4% of new-format CCCD holders.

7.6. Image Repository Statistics

The approximately 76–80 candidates missing images most likely registered before the mandatory ID card photo upload requirement was implemented, or uploaded documents in non-standard formats that the DOM scraper could not extract.

7.7. PDF Source Analysis

8. Root Cause Analysis

8.1. Architectural Flaws in the Connections Platform

The data exposure stems from fundamental architectural design decisions in Company Y’s Connections platform:

1. No API Authentication Layer: The XHR API endpoints at xhr.companyy.com and connections.universityx.vn accept requests from any JavaScript execution context. There are no tokens, session cookies, or API key checks.

2. No Field-Level Access Control: The API returns all fields for any requested object. A user accessing a public page to view the exam schedule receives the exact same data as an administrator viewing CCCD numbers and ID card photos.

3. IDOR by Design: Database object IDs are used directly in URLs and API calls. Table hashes serve as identifiers that provide no security they are plainly visible in URLs and easily discoverable through foreign key traversal.

4. Client-Side-Only Security: All business logic and data filtering occurs in browser-side JavaScript. The server acts as a transparent data store, enforcing no access controls whatsoever.

5. No CDN Controls: Both the static file CDN and image CDN serve content without authentication. Once a URL is known (or extracted from a rendered page), any HTTP client can download the file.

6. No Rate Limiting: The API accepts hundreds of sequential queries from a single client without throttling, enabling easy bulk data extraction.

8.2. Third-Party Vendor Risk

University X has entrusted sensitive candidate data including photos of government-issued CCCD/CMND cards to Company Y’s Connections platform. This creates a supply chain vulnerability:

• University X may be entirely unaware that the platform has zero access controls.
• The same architectural flaws likely affect all organizations using the Connections platform, not just University X.
• University X is limited in its ability to implement security controls on infrastructure it does not operate.
• The vendor relationship means that remediating this vulnerability requires Company Y to redesign their platform architecture.

8.3. Why Image CDN Encoding Is Not Security

The image CDN uses encoded URL paths (e.g., kt3PG1hPTgTPG1MJ.u54.L8J...), which superficially appears to provide security. However:

• The encoding is performed by client-side JavaScript, which users fully control.
• Encoded URLs are embedded directly as CSS background-image attributes in the DOM, making them trivial to extract.
• Once extracted, these URLs require no cookies, tokens, or headers to download the images.
• Any headless browser can render a candidate’s page and automatically harvest all image URLs.

9. Impact Assessment

The data exposed in this vulnerability is not just abstract “PII.” For 896 real people, it represents everything needed to steal their identity. In Vietnam, CCCD photos are widely used for KYC (Know Your Customer) verification at banks, e-wallets like MoMo and ZaloPay, and telecom providers. A leaked CCCD photo is essentially a master key to someone’s financial life. What follows is an assessment of what this exposure means for the real students and professionals whose data was left wide open.

9.1. Affected Individuals

• 896 unique candidates confirmed from exams across 2024–2026.
• The database very likely contains candidates from all historical exam sessions, potentially numbering in the thousands.
• All candidates have their full PII profiles and ID card photos accessible without authentication.

9.2. Severity: ID Card Photo Exposure

The exposure of CCCD/CMND card photos is far more severe than text-based PII exposure:

• Biometric Data: Images contain the cardholder’s face, which can be used for facial recognition attacks.
• Physical Card Replication: High-quality images of both front and back provide all information needed to create counterfeit ID cards.
• KYC Bypass: Many financial services in Vietnam accept CCCD photos for KYC (Know Your Customer) verification - these images could be used to open fraudulent bank accounts or e-wallets.
• Irreversibility: Unlike passwords or phone numbers, a CCCD number and its card images cannot be “changed” once exposed - the consequences are permanent.

9.3. Risk Scenarios

1. Large-Scale Identity Theft: CCCD numbers + Images + Full names + Dates of birth = a complete identity dossier for 896 individuals.
2. Financial Fraud: ID card photos can bypass KYC systems at banks, e-wallets (MoMo, ZaloPay, VNPay), and cryptocurrency exchanges.
3. SIM Swap Attacks: Phone numbers + ID card photos enable SIM swap attacks with mobile carriers, leading to account takeovers.
4. Deepfake Creation: Facial images extracted from CCCDs, combined with names and biographical information, enable AI-generated deepfake content for social engineering.
5. Targeted Phishing: A complete dossier (Name, Email, Phone, Workplace, Exam history) enables highly sophisticated and convincing spear-phishing campaigns.
6. Legal Violations & Penalties: Under Vietnam’s Decree 13/2023/ND-CP on Personal Data Protection, the exposure of citizen identity information and biometric images constitutes a serious violation subject to sanctions.

9.4. Severity Rating

10. Technical Challenges and Solutions

10.1. Dynamic Content Rendering

The website renders all data client-side using JavaScript. Standard HTTP requests (such as curl or Python’s requests) only retrieve the empty HTML skeleton.

Solution: Used Playwright with a headless Chromium browser to execute the JavaScript framework, enabling both API calls and DOM extraction.

10.2. Vietnamese Source Code

The framework uses accented Vietnamese identifiers: xửLý, dữLiệu, thuộcTính, đốiTượng. While not intentional obfuscation, this requires Unicode-capable tools and makes pattern-matching significantly harder than standard JavaScript analysis.

10.3. Reference Field Resolution

The Ethnicity and Place of Birth fields store opaque reference IDs (e.g., {"ậ":["146992"]}) instead of text. These references are only resolved during page rendering by the framework’s internal logic calling the APIs directly (CĂN.db, config, thuộcTính.tải) always returns null for these IDs.

Solution: Render the full page for each candidate and extract the resolved text from the DOM (e.g., “4. Dân tộc: Kinh”). I cached these values to avoid redundant page renders.

10.4. Image URL Encoding

ID card photos are served from the image CDN with encoded URL paths that cannot be constructed from file IDs alone – the framework generates them at runtime.

Solution: Render each candidate’s page, extract URLs from CSS background-image attributes on <div> elements pointing to connections.vn, then download images via HTTP GET.

10.5. Parallel Processing and Thread Safety

Playwright’s synchronous API is not thread-safe across shared browser instances.

Solution: Each worker thread launches its own Playwright browser instance, with 2 separate pages per browser (one for API calls, one for rendering). Workers are staggered by 3 seconds to avoid thundering herd effects during session establishment.

10.6. Network Resilience

University X’s server frequently experiences very slow page loads (sometimes exceeding 30 seconds).

Solution: Used smart wait algorithms (polling DOM text instead of fixed timeouts), automatic session resets on failure, periodic CSV saving every 10 candidates, and Ctrl+C handling to save all collected data before interruption.

11. Recommendations

11.1. For University X (Immediate Remediation)

1. Vendor Security Audit: Require Company Y to conduct a comprehensive security assessment of the Connections platform.
2. Remove ID Card Photos: Delete all stored ID card images from the platform or migrate them to a storage system with strict access controls.
3. Add robots.txt / noindex: Prevent search engines from indexing candidate detail pages; request Google to remove currently cached pages.
4. Restrict PDF Access: Place candidate lists behind authentication or redact sensitive columns.
5. Evaluate Alternative Platforms: Consider migrating to a platform with proper access control capabilities.

11.2. For Company Y / Connections Platform (Urgent Remediation)

1. Implement API Authentication: All XHR endpoints must require a valid session token with role-based access control.
2. Add Field-Level Access Control: Sensitive fields (CCCD, Phone, File references) must be restricted to admin-level authenticated sessions only.
3. Secure Image CDN: Image URLs must require authentication tokens that are validated server-side, not relying solely on path encoding.
4. Server-Side Rendering for Sensitive Data: Move PII display logic to server-side processing; never send raw sensitive data to public-facing web page contexts.
5. Rate Limiting and Anomaly Detection: Implement IP-based query rate limits and alerting for bulk download patterns.
6. Platform-Wide Security Audit: The same vulnerabilities very likely affect all organizations using the Connections platform.

11.3. Long-Term Plan

1. Compliance Review: Assess system compliance with Vietnam’s Decree 13/2023/ND-CP on Personal Data Protection.
2. Penetration Testing Program: Establish a regular security testing schedule for the system.
3. Data Minimization: Reconsider whether it is necessary to retain citizen ID card photos after the initial identity verification process is complete.
4. Incident Response: Notify affected candidates about the data exposure in accordance with legal requirements.

12. Conclusion

What started as a routine Google search ended with a disturbing discovery: an entire university’s exam candidates had their most sensitive personal data – including photos of their government-issued identity cards – exposed to the open internet. 896 people registered for a language proficiency exam, trusting that their information would be handled responsibly. Instead, their complete identity dossiers were accessible to anyone with a web browser.

The root cause is not a single bug or misconfiguration. It is a fundamental architectural failure: the software vendor built a system where the database has no lock on the door. The Connections platform treats every visitor, whether a student checking exam results or a stranger on the internet, as having full access to every record, every field, and every uploaded file. There is no authentication layer, no access control, no distinction between public and private data.

These findings deliver 3 critical lessons:

1. Third-party vendor risk is real: Outsourcing your software does not outsource your responsibility. Any organization handing sensitive data to a SaaS platform must audit that platform’s security architecture, not just evaluate its features.
2. Client-side security is not security: If the only thing standing between an attacker and your database is JavaScript running in their own browser, you have no security at all. Access control must be enforced on the server.
3. Security through obscurity always fails: Encoded URLs, minified code, and hash-based IDs may slow down an attacker by minutes, but they can never substitute for real authentication.

For 896 candidates, the damage is done. Their CCCD numbers, their identity card photos, their personal information – it is data that can never be taken back.

13. Revalidation Update – June 23, 2026

On June 23, 2026, I retested all attack vectors on tec.universityx.vn. Company Y had updated the codebase that same day (version 14484523062026). The results show meaningful progress but incomplete remediation.

What changed

The most important fix is at the API gateway level: the XHR endpoints now enforce server-side authentication. Both connections.universityx.vn/xhr/ and xhr.companyy.com/xhr/ return HTTP 403 with {"error":403,"code":"access_denied"} for unauthenticated POST requests. This is the first time server-side access control has been observed on this platform.

Additionally:

• Account table (taiKhoan) access is blocked. The account-level IDOR documented in this report no longer works; all tested account IDs return null.
• The b6x cipher has been removed. The monoalphabetic substitution layer that was added as a “fix” after my initial disclosure is gone entirely. Remaining data is returned in plaintext rather than wrapped in a broken cipher.

What remains vulnerable

Unlike the alumni platform documented in Part 2, the exam system still has gaps:

Candidate data partially exposed. At least one candidate record (#1662402) still returns data via the API. The b6x wrapping is gone, but four fields remain in the raw response:

The most sensitive text fields (name, phone, email, CCCD number) have been scrubbed. But date of birth and image reference IDs persist.

Bulk ID enumeration still works. The mass-load endpoint returns 50,403 candidate IDs. While most individual records appear empty or deleted, the enumeration itself should not be possible for unauthenticated users.

CDN image access has regressed. The image CDN nodes at i0.connections.vn and i3.connections.vn are responding with HTTP 200 again. These were marked as fixed in the March 10 revalidation, meaning this is a regression, not a lingering issue. If image reference IDs from candidate records can still be resolved to CDN URLs, the ID card photos documented in this report may once again be downloadable.

Scorecard

Assessment

The vendor has made real progress. The XHR authentication gate is the correct architectural fix, and the removal of the b6x cipher in favor of actually scrubbing sensitive fields is a better approach than obfuscation. The pattern is moving in the right direction.

But for this platform specifically, the job is not done. The CDN regression is concerning because it reverses a previously confirmed fix. The persistent candidate data, even partial, combined with image reference IDs, means the core finding of this report (ID card photo exposure) may not be fully resolved. And 50,403 enumerable candidate IDs represent a larger dataset than the 896 candidates I documented here, suggesting the exposure may have been broader than initially assessed.

The next step should be verifying whether the exposed image reference IDs can still be resolved to downloadable photos on the CDN. If they can, the most critical finding in this report remains exploitable despite four months of remediation efforts.

Appendix

A. Tools Used

B. Disclosure Timeline

C. Glossary

D. Sample Data Records

Below are two representative records extracted from the dataset, with actual personally identifiable information redacted:

// Sample Record 1 (Redacted)
{
  "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"
}

// Sample Record 2 (Redacted)
{
  "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"
}

Notable observations:

• CCCD numbers are stored as plain text (with a leading apostrophe only for CSV formatting purposes).
• Image files are standard JPEG photographs of physical identity cards.
• The don_vi (workplace) field has a very low fill rate (15.1%), indicating most candidates are students who have not yet entered the workforce.

E. Reproduction Steps

1. Step 1 Download publicly listed candidate PDFs from the static file CDN and parse the candidate tables to extract exam registration numbers (SBDs).
2. Step 2 For each SBD, query the unauthenticated JavaScript API endpoints to retrieve full candidate records including CCCD numbers and personal details.
3. Step 3 Resolve image reference fields from API responses into CDN image URLs, then download the associated ID card photos.
4. Step 4 Merge PDF-extracted data and API-extracted data using SBD as the primary key to produce a complete dataset.

Note: Detailed reproduction code and tooling have been withheld from this public report to prevent misuse. Full technical details were shared with the affected parties during responsible disclosure.

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.

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.

1.3. Động lực: Phát hiện qua Google Search

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.

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:

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:

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:

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ữ:

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)

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

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):

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ý

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

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

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

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

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

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:

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:

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

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

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

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ô:

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

Đá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

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

C. Thuật ngữ (Glossary)

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.