Home / Knowledge hub / State machine abuse
Knowledge hub
State machine abuse
Moving an order or account into a state the normal flow would never reach.
What it means
Many things in an application move through stages: an order goes from basket to paid to shipped, an account from invited to verified to active. Each stage is a state, and the allowed moves between them form a state machine. Abuse is forcing a move the design never allows.
That might be marking an order as paid without paying, shipping before approval, reopening a closed claim or activating an account that was never verified. The user interface offers only the legal steps, but the server may accept others.
Why it matters
If a state can be forced, the business rule attached to it is gone. A skipped payment step means free goods. A skipped approval step means unapproved spending. A skipped verification step means unverified accounts using features that were meant for checked ones.
It is hard for scanners to find, because every request is well formed and every step is valid by itself. The flaw is in the order and context, which only a person or a tool that understands the workflow will notice.
How it shows up
It shows up in checkout, onboarding, approvals, subscription changes, document review and any process with a status field. The usual mistakes are trusting a status sent by the client, not checking the current state before allowing the next, and exposing step endpoints that can be called directly. See workflow bypass and parameter tampering.
Make the server the only owner of state. Define the allowed moves, check the current state on every step, and reject anything else. Test by calling later steps directly, repeating steps, going back, and changing a status value in the request.
Questions people ask
State machine abuse, answered
Is this the same as workflow bypass?
They overlap. Workflow bypass is the broad idea of skipping steps. State machine abuse describes it as moving into a state that should not be reachable from where you are.
Why can't scanners find it?
They look for known patterns in single requests. These flaws only appear when the requests are put in a certain order and judged against the business rule, which needs an understanding of the workflow.
Where does the status live?
It should live on the server only. If the client sends the status, or the server trusts a hidden field, anyone can change it.
How do we prevent it?
Write the allowed transitions down, enforce them in one place on the server, check the current state before each step and log every change.
How do we test it?
List the states and the moves, then try each forbidden move: jump ahead, repeat, go back, and set the status directly. Each should be refused with no change made.
Sources
Where this comes from
Related
Terms that sit next to this one
Workflow bypass
Skipping a required step, such as payment or approval, by calling a later one directly.
Business logic flaw
Nothing is technically broken, but your own rules turn against you.
Parameter tampering
Changing values in a request, such as a price or an id, to alter what happens.
Price manipulation
Changing a price, quantity or discount in a request so you pay less than you should.
Time of check to time of use
A gap between checking a condition and acting on it that an attacker can use.
Can a step be skipped?
Workflows are part of what we test. We try the moves a normal user never makes and report only the ones the server accepted, with the request and response. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.