I am trying to prevent something similar to this from happening:


Basically the financial exchange was using non-ACID transactions and multiple requests sent very near in time to each other could result in duplicate withdrawals, or something of this nature.

One preliminary question I have is, what is this vulnerability termed? A timing attack of some sort?

Here is my setup:

I am setting up two tables, one for a payments queue (ie pending payment to be withdrawn), the other for a payments history (ie a receipt after the payment queue item has been withdrawn).

My processing flow consists of finding the payments queue by id, doing a bunch of asynchronous stuff, processing a payment, then creating a payment history object and deleting the payment queue object.

What are some strategies in regards to the process flow I could implement to make sure that if a user attempted to access this flow twice in a row very quickly, there would not be duplicates, or any similar problems?

I have considered that before starting the process I could delete the payments queue object, therefore with ACID transactions that would guarantee that the process could not be duplicated in a timing attack, correct? Is this the best way to do it?

  • 1
    I think asking how to secure a multi-threaded app may be too general a question to answer on this site. Do you have a specific question? Jan 3, 2016 at 4:39
  • is there a way for me to prevent a user from accessing request, which initiates a database query, very quickly multiple times where afterwards I am doing an asynch operation before finally modifying the database, to make sure the payments are not duplicated by such requests. I considered sql locking, but the postgre docs said it does not apply for reading.
    – ROCK
    Jan 3, 2016 at 4:50
  • Basically: read queue-> do asynch stuff -> write payment balance and delete queue. How can I make sure that after the read, the user is blocked from doing the rest of the request until after this current request is finished, in case the user does it twice in a row and the asynch code has not finished so the document can still be read and the balance is modified twice. The only thing I can thing of besides have a special field in the document to check for when reading initially, and to modify it before doing the rest of the operation, would be to just delete the document at the beginning
    – ROCK
    Jan 3, 2016 at 4:53
  • I guess I have answered my own question, but I would be interested if there are other solutions or more information about this type of attack. I guess it is technically categorized as a timing attack probably.
    – ROCK
    Jan 3, 2016 at 4:54
  • 1
    I ended up using a postgre transaction to select a row where column "locked" is false and simultaneously update the column "locked" to true,
    – ROCK
    Jan 5, 2016 at 2:52