The seller watches and verifies that there is indeed $100 on the table.
The seller then turns around to write a receipt.
You pick up one of the $20.
This is a time of check vs time of use problem.
The amount of the transaction was verified
Then later the transaction actually occurred.
Consider the following transaction
A user requests authorization to change a specific file.
They submit the request to a the authentication manager.
The authentication manager copies the file name and authenticate permission to perform the change, and returns approval for the request.
In the meantime, the user changes the request to something malicious.
And match the authorization with the modified ticket.
Mediation depends on the mechanism
But most likely it is to have the authentication mechanism take the request and pass it on to the service provider.
Or possibly digitally sign the request after it is authorized
In general, don't allow the requester to modify the request after it is authorized..
Undocumented access point
Remember we are in the section of unintentional errors
Most likely is the programmer has written in "quick debugging" shortcut for the program.
You build a bypass for validation while you are testing.
You build a shortcut to a section that doesn't involve all the data input. (Like hop to a room in a game somewhat far along the path, or give infinite gold, total armor, ...)
You build a joke component into your project.
These are called backdoors or trapdoors.
As you probably know, someone eventually finds these and exploits these.
Code reviews are a defense against these.
But they say that engineers are really good at hiding them.
Which makes them hard to find.
Often someone who has compromised the system will build a backdoor for later use.
Off By One
Equivalent to buffer overflow.
But just valid data overflow.
You have an array of 100 items (capacity)
But only use items 0-9.
Your code needs to only access 0-9.
But what if you use item 10?
Off by one is not detectable
Bugs caused by this can appear very random, and infrequently.
They are much more likely to cause errors and loss of availability than be a vector of attack. (Integrity, Availability)
And are very hard to catch.
And are hard to mitigate.
Overflow in general
This is hard to check for.
And is often hard to code for.
Most likely will cause inaccurate data. (Availability, Integrity)
Unterminated strings
This is a problem with c strings.
But the real problem is how widely c is used.
Very likely to cause buffer overflow.
Mitigation: strncpy, not strcpy, strndup, not strdup, ...
Or use c++ strings.
Unsafe library/utility functions
Stringdup and such.
Race Conditions
Two or more processes are running at the same time.
The race is which process gets to some critical point.
Consider a race for memory allocation
time
| Process 1 asks if memory is available
v Process 1 gets a yes back
Process 2 asks for memory
Process 2 gets a yes back
Process 2 requests memory
Process 1 requests memory
In this case, process 2 wins the race.
Could you rearrange this so process 1 wins?
This happes all over the place when there are multiple process running.
And at times you are not even aware of the competition.