您描述的漏洞是競賽條件。

有幾種處理方法，但是我會使用 SELECT ... FOR UPDATE SQL查詢，該查詢將鎖定選定的行，以防止在提交當前事務之前進行新的寫操作。

請務必檢查您的RDBMS文檔，以檢查如何正確實現它：

• PostgreSQL
• MySQL
• MariaDB

這裡的另一個解決方案是絕對正確的，並且對於不那麼容易的大型系統有意義。

使用相對簡單的數據，您可以使用非阻塞選項：

  UPDATE [FESTIVAL_TICKET] SET IS_SCANNED = TRUE TICKET_ID = @ScannedKey AND IS_SCANNED = FALSE  

現在，這是一個原子操作。數據庫中沒有兩個用戶可以發布此 並讓其更新行。返回的人“受影響的第一行”（顯然，有一種方法可以在代碼中查找出來，對此不進行語法分析）可以進入。其他人將受到該語句影響的零行。如果您希望變得用戶友好，現在可以檢查為什麼找不到它，它是錯誤的ID還是已經被掃描。

但是重要的細節是該語句是原子的。無論距零時差有多近，只有一個人會贏。因為您不再具有讀取功能，而又沒有 then 編寫功能。您具有一次原子操作的讀寫功能。

此的缺點似乎是一個人可能免費進入（帶有復制的票證）。

對於可能是正確的小事件。
但是，如果由於任何原因增加了過多的延遲，則冒險的風險將超過一個人。
如果他們的設備卡住或速度太慢，票掃描器只會讓一些額外的人通過...因為，大多數人可能都擁有有效的票，對嗎？

我在本日曆年度的一次大型活動中看到了這種情況，成千上萬的粉絲參加了許多聽過的音樂家。
票務公司是一家重要的公司（也許是您工作的公司？），並且該公司是在專門為取票而建的網站上。
我的聚會是未經掃描就通過的公司之一（是的...我有一張有效/合法的機票）。
我不得不站在那兒，看著售票員幾分鐘，然後才能弄清楚為什麼會這樣。

TL; DR;
在涉及人員參與時，不要為所有可能的情況進行編碼。
拍兩個或三個九（99％-99.9％），稱它為一天。
僅在涉及機器時保存划痕...那是您可以獲得9的一堆。

這個答案已經是一個好而便宜的答案，但是，我將從軟件工程和安全性的角度來添加自己的答案。

這可能對將來類似的有關不太可能的利用的問題很有幫助。雖然在理論上有可能……在實際情況下，這可能會失敗。

然後，與成本相比，潛在的損失是多少？我將證明花更多的心力和增加安全性的頭痛不值得冒險。

現在，已經提出並接受了該解決方案以通過SQL事務正確處理競爭條件，從而將責任/成本轉移到了數據庫，是最好的，行業標準的和便宜的解決方案。正如答案所指出的那樣，這可能是案件的結局，因為答案的確被接受了。

如前所述，兩名乘務員都在非常準確的時刻被掃描並觸發如果不是十億大小，則種族條件利用的估計值可能高達數百萬。為使您對億萬富翁賠率有一個定性的想法，請閱讀有關彩票的文章，並發現在第二個列表頂部的SuperEnalotto玩遊戲可能很容易與掃描兩張票相比，獎勵肯定是一致的。賠率表示漏洞的可利用性，通常被定為謹慎級別（[極不可能]，[極]可能）。我總是將不確定性與安全性相關的事件與彩票進行比較，以提供更熟悉的比較。

為進一步說明，賠率受以下因素影響：

• 兩者同步在隊列中的移動，並同時將票證交給警衛。這意味著這兩個人之間經常保持交流並訓練有素，更不用說運氣了（奇怪！），他們的線路以可預測的速度運動
• 警衛的身體運動。並非所有警衛都以毫秒為單位精確掃描票證，他們以不同的速度移動武器。一張票可能會掉落在警衛的手中，一名警衛可能會把票倒轉。一名警衛可能會轉身檢查線路是否在他們後面被堵塞。換句話說，沒有足夠的熵來計劃攻擊
  • 無人售票機可能不受此因素影響
• 掃描計算機票證所花費的時間，因此兩次掃描屬於同一時間段並利用了漏洞。

因此這是軟件工程方面的考慮。

門票有價格，所以值得X $。我估計X的大小可以在50-100之間。對於每個利用此漏洞並以欺詐方式進入該設施的人，將損失$ X。

實施更複雜的檢查（例如護照名稱控制）在以下方面都是很昂貴的：兩者軟件開發階段所需的代碼，以及人員進入工廠所需的時間。保安人員按小時付費。實施 Ben-Gurion風格的安全審查 *實在是昂貴且痛苦。

現在，您要睡得更香，確保沒有人可以利用您的系統。它要多少錢？在您為保護系統付出了巨額資金之後，您可能會發現，運行“不受保護”系統的競爭對手承受了$ 80的損失，賠率超過數百萬個。很難量化這種可能性。既然您有更多的機率贏得世界上最艱難的彩票，那麼最好押掉永遠的工作！

結論：在我們的職業中，贏得機率是我們最好的熟睡伴侶！

結論2：種族條件攻擊可以可能在自動網絡系統上被利用，攻擊者顯然可以將他們同步到微秒！！！這也可能會增加損害，因此歡迎採取最佳的安全措施！

結論3：如果系統已經在運行，請使用可接受的答案為系統打補丁（設計，開發，測試，UAT，部署，PMO ...） 比潛在損壞要貴得多。請在下面發表評論

*我舉了一個例子，因為傳說中以色列的機場安全線漫長而徹底

這裡已經有很好的答案，涵蓋了數據庫的大部分漏洞利用。但是，我想添加我的現實生活經驗，在活動（露天節）領域工作並設計票證驗證系統和應用程序。

最大的挑戰之一是網絡穩定性，因為所有掃描設備一直都具有網絡功能的假設是完全錯誤的。在掃描過程中隨時可能會出現延遲，中斷或不可用的情況。流程，並且不應延遲客戶進入事件（至少從我們的角度出發，其他事件可能需要更嚴格的驗證）。

在我們的應用程序中，票證是使用簽名驗證的，但是僅在網絡啟動時才同步並提交到數據庫。該應用程序將經過驗證/待提交的票證存儲在存儲桶中，並在網絡可用後嘗試提交盡可能多的票證。這也避免了對每張票執行一次 INSERT 。

在事件條目的最遠位置，wifi根本無法到達。為了節省僅覆蓋10米的覆蓋範圍的另一台路由器的成本，掃描設備可以在它們之間進行通信並共享其連接。這意味著，如果僅其中一台設備可以訪問wifi，則其他設備可以從理論上將其存儲桶發送到該設備，或者發送到可以轉發該設備的範圍內的最近設備。掃描設備每分鐘至少失去一次連接。

從理論上講，一張票可以被任意數量的未連接設備掃描，但每個設備只能掃描一次。這是一個種族條件，但是要利用其他答案提到的方法卻不那麼容易。

如何防止這種情況出現？：

您可以通過刪除並行操作來防止爭用情況，這是鎖的作用。由於您基本上會降低數據庫接受並發寫入的能力，因此它將引入延遲。

然後問題變成了，值得嗎？我們可以接受更多的延遲，直到為了確保正確身份驗證而進行驗證為止？這會阻止人們發現敞開的門或跳柵欄嗎？

一個好的解決方案可能是使用消息隊列而不是設置延遲。掃描的票證不會立即得到處理，它會一直等到所有已發送的票證才被處理。除非票證已離開隊列並已正確處理，否則係統不會返迴響應。有人認為這可能會很慢，因為每個人都必須等待其他人完成。但您可以在邏輯上分片票證ID，例如：2個隊列，1個用於奇數票證，1個用於偶數票證。或者只是簡單地將組號放在id本身中。

這是一個典型的問題，是由於您的會計系統的設計（此處的“會計”是在跟踪任何資產或項目的使用，而不僅僅是金錢）與您要跟踪的真實世界信息之間的不匹配引起的。 p p>

您已經說明，在現實世界中，很可能對代碼進行兩次掃描，並且您希望跟踪這種情況，但是您的數據庫僅存儲“已被掃描”。就目前而言，這是不正確的： SET is_scanned = TRUE WHERE ticket_id =？確實是正確的（真實世界之前的狀態是“ ticket_id？已被掃描”，也就是說

而不是保持狀態，而是保留一個分類帳：標題為 ticket_id，scanned_timestamp的表 scan ，scanner_id ，鍵是這三個字段的所有 。¹因此，您不僅要記錄已掃描票證，還要記錄記錄的每次掃描。票。如果沒有包含 ticket_id =？的行，則您將知道從未對票證進行過掃描，否則，您將獲得掃描票證的所有時間（以及位置）的列表。

現在，您的數據庫能夠更好地模擬現實世界的信息，您可以決定要對此做些什麼。您的特定DBMS可能會提供一些解決此爭用條件的方法（ INSERT ticket_id，scanner_id INTO掃描WHERE ticket_id NOT IN掃描或其他任何方法），在這種情況下，您肯定要防止同一ticket_id出現兩個條目。或者，您可以簡單地讓兩個人都進入，然後再分析您的記錄，以弄清您似乎擁有兩張具有相同ticket_id的票證的原因。

您想走的路實際上是業務決策，而不是技術決策。有很多原因可能會導致您錯誤地發行兩張具有相同ticket_id的有效票證（例如，與企圖退貨有關的錯誤），或者同一人需要使用兩次票證（忘記在出口處掃描）。如果嘗試欺騙系統的人數低於一定水平，那麼您的企業最好吃一些欺騙者的費用，而不是支付拒絕有效票證持有人的費用（聲譽，訴訟或其他方式）

簡而言之：使用分類帳而不是說明適用的位置，使數據庫設計與實際的實際情況相匹配，並讓企業製定有關如何應對這些實際情況的業務決策。

¹我在這里大肆揮舞著細節，以使答案簡短，只表達一般性想法。
²在這裡，我假設採取了一種具有相同效果的適當一致性策略將這些INSERT請求序列化到此表中。

在Clojure中，它們具有稱為“原子”的功能來解決此類問題。

有兩個線程進入。它們都讀取值 is_scanned = false 並繼續進行。處理完他們的東西後，他們返回 is_scanned = true 來更新atom。但是，一個線程很快就會出現。

稍後出現的線程將更改原子，因此該函數將無法更新原子。相反，它將被告知使用現在更新的 is_scanned = true 值重新運行。現在返回的是另一張票不再有效。

這裡的視頻解釋了clojure的這一功能。