You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This problem is famous when using the ORM pattern as Active Record and Data Mapper.
We get a record for changes and change it outside the transaction, which means that we can execute precisely the same query in parallel.
Consider a simple attack in transferring $5 from Alice to Bob:
Get balance Alice -> $5 -> transfer to Bob -$5 -> get balance Bob -> $0 -> received from Alice +$5
And now, if two queries were running at the same time:
Query 1:Get balance Alice -> $5 (race condition!) -> transfer to Bob -$5 -> get balance Bob -> $0 -> received from Alice +$5
Query 2:Get balance Alice -> $5 (race condition!) -> transfer to Bob -$5 -> get balance Bob -> $5 -> recieved from Alice +$5
Bob has a balance of $10, and Alice has $5.
It is elementary to check this behaviour by calling the Promise.all() method, we generate ten requests and, depending on the network, and the processing speed of the database, from 2 to 10 requests will pass simultaneously.
In SQL, the first statement must be with SELECT FOR UPDATE to block against concurrent updates, or both wrapped in a SERIALIZABLE transaction isolation level.
How can we protect ourselves now?
We must wrap the updateEntity method in a transaction with isolation level SERIALIZABLE.
Or use moleculer-channels to update items in strong FIFO in Kafka.
The text was updated successfully, but these errors were encountered:
Do you think this issue should be solved in this module, or only in knex adapter, or outside of the lib in the application layer? How it solved in other ORMs like sequelize, Mongoose or others on other language ORMs?
There is such a problem as the race condition attack.
This problem is famous when using the ORM pattern as Active Record and Data Mapper.
We get a record for changes and change it outside the transaction, which means that we can execute precisely the same query in parallel.
database/src/methods.js
Lines 592 to 595 in 3729bf9
database/src/methods.js
Line 618 in 3729bf9
Consider a simple attack in transferring $5 from Alice to Bob:
Get balance Alice -> $5 -> transfer to Bob -$5 -> get balance Bob -> $0 -> received from Alice +$5
And now, if two queries were running at the same time:
Query 1:
Get balance Alice -> $5 (race condition!) -> transfer to Bob -$5 -> get balance Bob -> $0 -> received from Alice +$5
Query 2:
Get balance Alice -> $5 (race condition!) -> transfer to Bob -$5 -> get balance Bob -> $5 -> recieved from Alice +$5
Bob has a balance of $10, and Alice has $5.
It is elementary to check this behaviour by calling the
Promise.all()
method, we generate ten requests and, depending on the network, and the processing speed of the database, from 2 to 10 requests will pass simultaneously.In SQL, the first statement must be with
SELECT FOR UPDATE
to block against concurrent updates, or both wrapped in aSERIALIZABLE
transaction isolation level.How can we protect ourselves now?
We must wrap the
updateEntity
method in a transaction with isolation levelSERIALIZABLE
.Or use moleculer-channels to update items in strong FIFO in Kafka.
The text was updated successfully, but these errors were encountered: