CWE-471, Modification of Assumed-Immutable Data (MAID), is a mistake in thinking before it is a mistake in code. A value matters so much to the application that it should never change, and the developer behaves as if it never will. But it travels through a place the attacker can reach.
MITRE gives common examples: hidden form fields, cookies and reverse DNS lookups. It also points to environment variables, web application parameters and HTTP headers as the data types most often attacked. The platforms listed are not language specific and not technology specific, and web applications are the usual home.
How it happens
The developer hands a value to an untrusted party and later reads it back as if it were still theirs. A price in a hidden field. A role in a cookie. A server variable that the request can overwrite.
Two observed examples from the record show the range. CVE-2002-1757 describes a product that relies on the PHP_SELF variable for authentication. CVE-2005-1905 describes gaining privileges by modifying assumed-immutable code addresses that a driver accesses. One is web, one is low level, the mistake is the same.
CWE-471 is the parent idea. The web version, CWE-472, and the PHP version, CWE-473, are its children.
What an attacker gains
MITRE lists two consequences: the attacker can modify application data, and the application can be pushed into an unexpected state. What follows depends on what the value controlled. Change a price and you get cheap goods. Change a role and you get access.
How to find it
The record names no detection methods for this entry, so the practical approach is a review habit. List every value the server receives back from a client, a file, an environment or a lower trust component. For each one, ask whether the server could still trust it if an attacker had written it. Where the answer is no, the value needs protection or must be recomputed on the server.
How to fix it
MITRE's guidance is to add integrity checks when the data passes through untrusted places, or to keep it somewhere trusted that outside parties cannot influence.
- Keep authoritative state on the server, in a session store or database, and give the client only an opaque identifier.
- If the value must travel through the client, sign it or use a keyed message authentication code, and verify on return.
- Recompute anything derived, such as totals and permissions, from server held data instead of reading it back.
Quick check
Is a hidden form field safer than a visible one?
No. Hidden only means not displayed. Anyone can edit it with browser tools or send the request by hand.
