How to properly organize and protect the table in which the user's balance will be stored?

Question

PHP

Hello everyone, guys, tell me how to properly organize and protect the table in which the user's balance will be stored?
WebMoney sends a response about a successful operation, I can enter the transaction code in the payment table so that an attacker who, if he gets into it, cannot generate this code, and the system, after checking the code for validity, activates the money.
The question is what needs to be done so that the attacker cannot confirm it himself in the payment table, let's say a payment is considered legal only when it has a status true. How to disable manual entry of this field? And only allow the script?

Answer 1

Initially not the right approach. If someone can write to a table, he will write to it. A paraphrase of one of Murphy's laws.
It would be correct not to allow unauthorized access to the database at all.

Answer 2

Create another database user or set the rights for an existing one.
Make it so that it does not have direct access to the table (select, update, insert, delete).
Make a view to receive data and a procedure to enter data (or a trigger on the view, if the DBMS allows).
This will provide a single sign-on to the data. In a trigger or procedure, you can also add logging or a more complex check of access rights to certain columns of the table.

Answer 3

It's not clear: are you afraid that someone will hack your server and, having gained access to the database, will start making changes there, or are you afraid that someone can "pretend" WebMoney and pull the script that updates the balance value?

Answer 4

Why would you want to store any status at all? When updating the balance legally through the application, sign all significant data in the balance table, passing some key to the procedure (or to the request). The signature is stored in a separate field of the table. Let's say you concatenate the balance and the secret key, take sha1 from them - this is the signature. When reducing the balance - the same procedure: verification of the signature, if everything is OK - decrease the balance and sign the changed data. If, when trying to change the balance, the signature does not converge, then the data is broken. Thus, without knowing the secret key, an attacker will not be able to make legal changes to the balance table.
True, in this case you need to ensure the safety of the key, it is not very secure to store it on the disk.
By the way, for some reason everyone here thought about evil hackers from the outside. Do not forget that the employees themselves, who have access to production, may turn out to be intruders. When it comes to real money, you can't rely on the fluffiness of sysadmins/developers.

Answer 5

Well, actually, when using normal frameworks / ORM, the probability of SQL Injection or, for example, attacks using XSS becomes very small. But if you want to play it safe, forbid direct access to the table and work with it exclusively through procedures, for example, it will partially help. (Security is a process, not a result).