HUST Giving

Program overview

giving.hust.edu.vn is the donation and fundraising portal for Hanoi University of Science and Technology. It takes money from the public and holds donor records, so the two things that matter most here are the integrity of the payment path and the confidentiality of donor data.

This page exists because the university granted written authorisation for security testing of this specific host. It is not an open, public bug bounty: the authorisation is held by a named researcher, it covers one hostname, and it can be withdrawn. If you are reading this and you are not covered by that letter, you do not have permission to test this site.

The program pays for valid findings on a four-tier priority scale, from $50 at P4 to $10,000 at P1. The scale and how a report is placed on it are described under Reward decisions.

Authorisation and scope of this engagement

The authorisation covers giving.hust.edu.vn and nothing else. In particular it does not extend to any other hust.edu.vn host, to the payment provider, or to any university system that happens to share infrastructure with the portal.

Before testing, confirm in writing with the university contact:

• the exact hostnames and environments covered,
• the testing window and the hours within it,
• the named individuals the authorisation applies to,
• the emergency contact to call if something breaks,
• whether a staging environment exists and should be used instead of production.

Keep the authorisation available for the duration of the engagement. Record the source IP addresses you will test from and give them to the contact in advance, so that defenders can distinguish your traffic from a real attack.

What is in scope to find

These are the vulnerability classes this engagement is most interested in. All of them are in scope to discover and report:

• SQL injection and other database access, including injection that demonstrably reaches donor records, payment records or administrative tables.
• Remote code execution: deserialisation, template injection, command injection, unrestricted file upload leading to execution.
• Content and template injection: stored cross-site scripting, HTML injection, or any flaw that lets attacker-controlled content render for other visitors. This is the class that would allow a site defacement, and finding it is exactly what this engagement wants.
• Authentication and authorisation flaws: admin authentication bypass, privilege escalation, session fixation, IDOR across donor records.
• Payment integrity: amount, currency or campaign tampering; replay or forgery of the provider's callback; race conditions in pledge handling.
• Information disclosure: exposed backups, configuration, .git directories, debug endpoints, or donor data reachable without authentication.

Testing rules and expectations

Finding a flaw and exercising it are different acts. The authorisation covers finding. It does not cover the following, and none of these are permitted at any severity, in any circumstance:

• Do not modify, delete or corrupt data. Read access proves a database flaw. A single benign row you created yourself proves write access if you truly need to demonstrate it. Never touch a record you did not create.
• Do not deface. Proving that stored content renders for other users is done with an inert, self-identifying payload on a page only you can reach, not by changing what a visitor to the site sees.
• Do not exfiltrate in bulk. For a data exposure, the proof is the shape of the data: a row count, a column list, one record that is unmistakably yours, or a redacted screenshot. Pulling donor records is not a proof of concept, it is the breach.
• Do not persist. No web shells, no added accounts, no scheduled tasks, no backdoors. If you achieve code execution, capture the minimum evidence (id, hostname, a file listing) and stop.
• Do not disrupt. No denial of service, no load testing, no mass scanning. Throttle everything. This portal takes real donations and downtime costs the university money it was given by donors.
• Do not pivot. The moment you can reach another host, stop and report it. Reachability is the finding; exploring further is not authorised.
• Do not touch real money. Use the smallest possible amount and your own payment instrument. Never test against another person's transaction.

Test with your own accounts. Identify your traffic with a recognisable user agent where you can. Work inside the agreed window.

If you encounter personal data, stop reading it immediately, do not save it, do not screenshot it unredacted, do not paste it into any third-party service or AI assistant, and tell the contact the same day. Delete any copy you made once the university confirms receipt, and say in writing that you have done so.

Proving write access

If you find a way to write, do not prove it by causing damage. Prove it with the smallest change that can be attributed to you and undone in the same minute.

• One or two punctuation characters. Delete a full stop, add a comma. Nothing longer, nothing visible, no payload, no changed number or amount.
• Only on a record you created yourself. Your own test donation note, your own profile field. Never another donor's record, never site content, never a page the public can see.
• Revert within sixty seconds, in the same run, without being asked.
• Capture four states: before, after the change, after the revert, and an independent re-read confirming the revert held.
• If it cannot be reverted, do not change it. Report the write primitive and stop. For a database flaw, a row count and a column list already prove access.

Every request must carry headers that let the university separate your traffic from a real attack in its logs:

X-Bug-Bounty:        giving-hust
X-Research-Account:  <the account you submit the report under>
X-Authorisation-Ref: <reference of the engagement letter>
X-Request-Id:        <unique per request>
User-Agent:          sentinel-research/<handle> (+<this page>)

scripts/proof_of_write.py in this repository performs exactly this sequence, refuses any host outside the scope above, refuses a diff longer than two characters, always attempts the revert, and writes a timestamped evidence file. Run it with --execute omitted first. Attach the evidence file to the report and quote the request ids in the body.

Send the source IP addresses you will test from to the security contact before you begin.

Safe harbour

The university's written authorisation, not this page, is what protects you. A web page cannot grant legal permission; treat the engagement letter as the controlling document and this page as a summary of it.

Within that authorisation, good-faith testing that stays inside these rules is authorised access. You are expected to stay within scope, minimise impact, avoid privacy violations, and give the university reasonable time to fix what you find before telling anyone else.

Authorisation ends the moment you step outside it. Modifying data, defacing, exfiltrating donor records in bulk, testing an out-of-scope host, causing an outage, or using a finding for any purpose other than this report takes you outside the letter and outside any protection it offers.

Reward decisions

Rewards use a four-tier priority scale. Priority is not the same thing as CVSS: the score is where triage starts, and the tier is where it lands after the impact on donors and on the university's ability to take donations is weighed.

P1 is a flat amount. P2 to P4 are ranges, and where a report falls inside its range is decided by how much of the work the report did: a clear reproduction, an accurate impact statement and a suggested fix land at the top of the band; a finding the triager had to reconstruct lands at the bottom.

What moves a report between tiers. Demonstrated reach into donor or payment data moves a report up. A precondition the attacker cannot arrange in practice moves it down. A chain is rewarded at the tier of the final impact, not the highest tier any single link would have earned alone, and it is paid once.

Duplicates. The first report with enough detail to reproduce is the one that is paid, judged by the timestamp the report arrives at triage. A later report that materially raises the severity of an open issue is paid the difference between the two tiers.

Informative. Reports matching the exclusions list, or describing a vulnerability class without a working reproduction on this asset, are closed without a reward. That is not a judgement on the researcher, only on whether the report is actionable.

Payment. Made after the fix is confirmed, through the platform. Tax and any sanctions screening are handled at that point; a researcher the university cannot lawfully pay will be offered recognition instead.

Appeals. Reply in the report thread with the specific fact you think was missed, within 14 days of the decision. Tier decisions are reviewed by someone other than the original triager.

Disclosure policy

This is a coordinated disclosure, and the university sets the timeline. In the absence of a timeline in the engagement letter, use 90 days from the date the report is acknowledged, extended by agreement if a fix is genuinely in progress.

Do not publish anything (not a write-up, not a screenshot, not a redacted hostname, not a conference talk) before the university has confirmed the fix and agreed in writing to publication. Donor data, internal hostnames, credentials and staff names must be redacted from anything that is eventually published.

If you believe an issue is being actively exploited, say so in the first line of the report and contact the university by phone as well as in writing.

How to report

Send reports to admin@bugbounty-program.com. That is the triage address for this platform, not the university's own security contact: reports are validated here and forwarded to the university under the engagement. For anything you believe is being actively exploited, also use the emergency contact named in the engagement letter; do not wait for triage.

A usable report contains:

• one sentence stating the impact,
• the exact URL, method, parameter and account role needed,
• numbered steps a non-expert can follow to reproduce,
• the raw request and response, not a screenshot of them,
• what you did not do, so the university can scope its own investigation,
• the timestamps and source IPs of your testing, so it can be separated from real attack traffic in the logs,
• a suggested fix, if you have one.