As you can see on wooyun, is there a thread concurrency vulnerability? Is someone willing to explain the principles and solutions?

As you can see on wooyun, is there a thread concurrency vulnerability? Is someone willing to explain the principles and solutions? Www. wooyun. orgbugswooyun-2010-0102881, but in the request sent to read the data is not timely lock data information, resulting in multi-thread concurrency multiple use discount. How can this BUG be solved? Can someone tell me the principle and solution of a thread concurrency vulnerability on wooyun?

Http://www.wooyun.org/bugs/wooyun-2010-0102881

Instead, the data information is not locked in time when the request is read, which leads to the multi-thread concurrent use of the discount coupon for multiple times.
How can this BUG be understood? Does it mean that coupons can be used in multiple browsers at the same time? How can we block bugs?

Reply content:

As you can see on wooyun, is there a thread concurrency vulnerability? Is someone willing to explain the principles and solutions?

Http://www.wooyun.org/bugs/wooyun-2010-0102881

Instead, the data information is not locked in time when the request is read, which leads to the multi-thread concurrent use of the discount coupon for multiple times.
How can this BUG be understood? Does it mean that coupons can be used in multiple browsers at the same time? How can we block bugs?

This bug is caused by the failure to promptly modify the coupon status.
In the second request, the coupon status has not been changed to "used" before the first request. As a result, the coupon can be used for the second request.

This is a bug caused by poor logic. It has nothing to do with thread mutual exclusion.

To prevent this bug, you must promptly modify the coupon status.

There are many ways to create this bug. Many languages have the multi-thread/multi-process function, and you just need to open it and request it at the same time.
Even the subject said that it is okay to use multiple browser requests.

To put it simply, you are going to buy things now and opening the door for you only by paying for it. You have paid for it and opened the door. Suddenly your things have fallen (don't ask why ), you bowed your head to pick up things (the store was not closed, and the thread was not locked). At this time, B Junjin came and took what you wanted. At this time, you looked up and asked about your things, the store gave it to you... in addition, multiple threads may seize the open time. Only one thread triggers the Transaction completion and the store knows that the transaction has been completed. At this time, the rest of the threads won't be able to get in (the specific thread trigger this close operation is random, and it is related to the current state of the computer, because thread execution is constantly switching, during this period of time, ABCDE may get free items.

The general payment process is as follows:

1. Read Balance

2. Judge whether it is greater than 0

3. Balance minus 1

4. Write back balance

When two threads run simultaneously, assume that the balance is 1 and the two threads run concurrently (assuming that the second thread lags behind the first thread ), the second thread reads the balance before the first thread writes back the balance. Then thread 2 determines that the purchase is successful and the purchase is successful.
The better design is that the result in the result database is-1, and the worse case is that the result in the database is 0 (because the second thread reads 1, after a value is reduced, the value is written back to 0 ).

The solution is to lock and lock before thread 1 reads the balance, so that thread 2 that wants to read the balance suspends and waits for the thread to write back the balance and then read it.
All databases may have such a situation where someone uses it for withdrawal. Http://www.wooyun.org/bugs/wooyun-2015-099622