How should web-attack evidence be reported?¶
The practical answer¶
Web-attack evidence should be reported by separating reconnaissance, attempted exploitation, successful effect, data access and attribution.
The key evidential caution¶
The dangerous assumption is that a malicious request and a compromised application are the same conclusion.
They are not.
A defensible report should identify:
Key points¶
- the targeted application and endpoint
- the exact request or action
- authentication and session context
- the response
- server-side process or database effect
- files or data accessed
- accounts or permissions changed
- persistence created
- source and infrastructure attribution
- remaining uncertainty
Use precise language.
“A traversal payload was requested” is different from “a protected file was returned.”
“An upload succeeded” is different from “the uploaded file executed.”
“SQL-like input was submitted” is different from “database records were extracted.”
Explain the role of gateways, proxies, cloud providers, content-delivery networks and shared infrastructure.
Evidential limits¶
Do not attribute the attack to a person solely from an IP address, account or domain.
Where logs are incomplete, state whether the conclusion is confirmed, supported or uncertain.
Practical interpretation¶
Where several alerts derive from the same web request, avoid presenting them as independent corroboration. A gateway alert, application alert and incident ticket may all repeat one event. The report should identify the underlying evidence and distinguish product interpretation from observed server-side effect.
State whether the conclusion rests on a request pattern, returned content, server process, database action or later account activity. Those foundations have different evidential strength and should not be collapsed into one compromise label.
Operational takeaway¶
Report web attacks in stages, distinguishing request, application response, server-side effect, data impact and offender attribution.