N
N
nezzard2013-11-15 14:34:31
PHP
nezzard, 2013-11-15 14:34:31

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

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 the question

In order to leave comments, you need to log in

5 answer(s)
A
Andrey Unger, 2013-11-15
@Cobalt

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.

A
Alexey Skahin, 2013-11-15
@pihel

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.

K
Kane, 2013-11-15
@Kane

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?

K
ksusha, 2013-11-17
@ksusha

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.

A
afiskon, 2013-11-15
@afiskon

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).

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question