YanoSecA maintainer needs to know what failed, why it matters and what change addresses it. A concise report links those jobs: title and summary identify the issue; evidence supports the claim; impact states the harm; remediation describes the correction; retest checks the correction.
A short page still needs limits. Do not turn a configuration concern into a claim of successful exploitation, or a read-only disclosure into a claim of modification. This lesson supplies a worked application finding and a separate service-permission packet to practise transferring the reporting method.
Before you begin
- Recommended first
- The rule for every tool from here on, Notes: scope, command, result, time, Passwords, hashes, and dumps, Access control and IDOR, What a finding is
- Estimated time
- 16 min reading, 16 min activity. Setup and optional practice may take longer.
- Where you work
- Use only the supplied North Desk fictional cards and source in a desktop or mobile browser. Keep predictions in private notes. No login attempt, recovery tool, framework module, permission change, domain setup or target connection is required. Optional later lab setup has a separate budget.
- Without a lab
- All evidence needed for the activity appears on this page. Copy it into notes if downloads are unavailable. Read the labeled model and predict each result; a paper trace practises the reasoning while tool operation waits for a lab. Reading needs no JavaScript. Answer checking needs JavaScript and a secure context; saving progress also needs usable browser storage.
After this lesson you can:
- Separate a worked report about a note id from the activity packet about a service file.
- Write a repair line that names lea and the write right on run.bat.
- Keep the retest to a new read of the rows, without starting the service.
01Example
Authored worked report, separate from the NightIndex activity. No request is sent.
Title: Reader lea received rina’s note
Evidence: card A-3 returns note 18 to lea; its stated owner is rina.
Impact: another account’s note is disclosed; modification is not shown.
Correction: enforce server-side owner/permission checks before returning the note.
Retest: repeat the same authorized cross-account case and expect denial.
Limit: one original fictional card, no wider testing.02Claim, then the rows
The worked card’s failed boundary is server-side authorization. Hiding a link in the browser would not address a server returning data to the wrong reader. A corrective proposal should name the mechanism that prevents the evidenced failure.
Packet P-6 instead describes NightIndex. lea can write run.bat, the program the model says a LocalSystem service starts. The packet supports a risky code-control path. It does not record a restart or an elevated session. The fitting paper proposal narrows unnecessary write access while retaining intended maintenance.
Retest the property you propose to change. A permission review should show the ordinary account no longer has effective write/replace rights. Broader execution checks would require their own scope and cannot be claimed from rereading a CSV.
Write an actionable one-page report whose claim, corrective step and retest all follow from the same evidence.Model. A teaching model drawn by hand. It shows the idea, not real tool output.
Read the full explanation below.
Card A-3
Evidence: card A-3 returns note 18 to lea; its stated owner is rina.Correction and retest
Correction: enforce server-side owner/permission checks before returning the note.
Retest: repeat the same authorized cross-account case and expect denial.Reader lea received rina’s note
A-3 supplies another account’s note to lea.
Disclosure is shown; modification is not.
Original fictional teaching evidence
A-3 supplies another account’s note to lea. Disclosure is shown; modification is not.
Follow the explanation
- A-3 supplies another account’s note to lea. Disclosure is shown; modification is not.
- Enforce the permission check and expect denial on the same authorized cross-account case. One fictional card; no retest was performed.
Read every state and value
1. A-3 supplies another account’s note to lea. Disclosure is shown; modification is not.
- Evidence selected
- Card A-3
- Current claim
- disclosure
- Source origins
- Original fictional teaching evidence
2. Enforce the permission check and expect denial on the same authorized cross-account case. One fictional card; no retest was performed.
- Evidence selected
- Card A-3 · Correction and retest
- Current claim
- retest
- Source origins
- Original fictional teaching evidence
03Fill the page from P-6
Use P-6 and the blank report template rather than copying the application finding’s nouns.
Worked one-page finding
Label: original fictional report. Not the activity packet. No request was sent.
Title: Reader lea received rina's note
Status: verified finding
Asset: notes app on http://127.0.0.1:8000, not started for this page
Evidence: saved card A-3. Account lea requested note 18. The card's response body is rina's note. The app did not compare the note's owner with lea.
Impact: a reader can see another account's note. The card does not show that lea can change the note.
Remediation: on the server, load note 18 only when its owner is the signed-in account. Return the existing not-allowed result otherwise.
Retest: repeat card A-3 as lea and expect the not-allowed result. Do not request a new note id.
Limit: one saved card. No guess about other note ids. No password is included.
One-page report
Label: original template. Fill it from the activity packet. The prose is not graded.
Title:
Status:
Asset:
Evidence:
Impact:
Remediation:
Retest:
Limit:
A title names the issue. Remediation says what to change.
Reproduction belongs in Evidence. It is not the repair.
Redact synthetic labels if they are not needed to check the claim.
Activity evidence packet P-6
Label: original fictional packet. No file was changed.
Asset: files-3.lab.invalid, NightIndex service
Checked: service-permissions.csv
Observation: NightIndex is recorded as LocalSystem. lea has write on run.bat. The service program is run.bat.
Not observed: the service was not restarted, and the file was not edited.
Impact supported by this packet: lea could change the program a LocalSystem service is configured to start.
Impact not supported: no proof of what would happen after a restart, because the restart was not done.
Repair that fits the observation: remove lea's write on run.bat, then read the permission rows again.
Retest that fits the repair: the new read should show no write for lea. Do not start the service.
Scope: this packet only.
- Write a title naming NightIndex’s writable program path and cite the supplied permission and identity rows.
- Keep the impact conditional: an ordinary account could alter code configured for privileged execution. Mark restart and elevation as unperformed.
- Propose removing unnecessary write/replace access and preserving intended administrator maintenance. State the corresponding rights-review retest.
- Stop after a self-review: every claim has a packet source, no secret is included and no unperformed operation is described as successful.
04Optional challenge
Spend about fifteen optional minutes rereading your page as a maintainer. Underline the change they should make and the evidence supporting it. If either is vague, replace it with the specific right/object and relevant source; keep the note private.
05Fresh cases for the checks
Use these fictional cases for the checks below. They have different inputs from the worked examples. Read them here or make notes; no installation or external service is needed.
Report card A: independent fictional service packetOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.
P1: DawnSort runs as LocalSystem and is configured to start sort.bat.
P2: ordinary account hana can write sort.bat; Administrators have full rights.
P3: administrators must retain program maintenance; hana only needs public status reading.
P4: no edit, restart or elevated session is recorded.
No other write or replacement paths exist in this simplified model.
Retest card B: independent repair reviewOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.
Proposed repair: ordinary account rui loses write/replace access to pack.bat; intended administrators retain maintenance.
Scope of retest: read new effective-rights rows only. No service start or program edit.
06Explain the evidence and its limit
Optional self-check: draft a one-page report with claim, row citations, conditional impact, narrow remedy, retest and limit.
Review it: a maintainer can identify the right and object to change; the retest checks that property; no edit or restart appears as an observed success.
07Common mistakes
If the activity still describes note 18, replace the worked application evidence with P-6’s service facts.
If a service restart is claimed, remove it unless the packet contains that observation; it does not.
If the correction only renames the report, identify the actual permission or authorization change that addresses the failure.
References
- NIST ITL Bulletin, December 2008
Assessment background on supported findings, analysis, mitigation and reporting.
- NIST SP 800-115 publication page
Assessment background on supported findings, analysis, mitigation and reporting.