潛在漏洞發佈到一個託管服務

我實現一個簡單的商店接受付款時。我正在使用託管商店解決方案。它的工作方式是：潛在漏洞發佈到一個託管服務

我的頁面處理構建購物車。當需要錢的時候，我的網頁會重定向到託管商店。
託管商店將處理交易。
託管商店將回到我重定向的結果。

我想，以確保交易儘可能地順利和安全地。商店的文檔使該過程看起來非常簡單。所有真正需要發送到商店供應商的信息都在下面，從他們的文檔中獲取。

<FORM METHOD="POST" ACTION="https://www.fakehostedstore.com/xxx/index.php"> 
    <INPUT TYPE="HIDDEN" NAME="store_id" VALUE="abcdefg"> 
    <INPUT TYPE="HIDDEN" NAME="store_key" VALUE="hijklmnop"> 
    <INPUT TYPE="HIDDEN" NAME="charge_total" VALUE="100.00"> 

    <!--MORE OPTIONAL VARIABLES CAN BE DEFINED HERE --> 

    <INPUT TYPE="SUBMIT" NAME="SUBMIT" VALUE="Click to proceed to Secure Page"> 
</FORM>

這讓我有點擔心。例如，如果我開放了類似Firebug的東西，我可以在提交表單前將「charge_total」更改爲我喜歡的任何內容。很快，我可以將發送到商店的費用從「100.00」減少到「10.00」。這家店將負責收費，但不會更聰明，並繼續收取不正確的費用。

如果交易在商店完成，店裏發回已經成功收取的金額。然後我可以驗證我的預期收費。例如，我預計收取100美元的費用，只收取10美元，WTF！

有沒有辦法在這樣一種方式，它是篡改不易，以確保這種形式？

來源

2012-08-16 dangowans

我認爲，除非他們改變處理支付（如，例如，你在他們的服務的註冊產品，具有固定價格的方法，你不能做任何事情，他們給你回的產品ID，用戶輸入她想要購買的物品的數量，然後他們計算他們一方的總價格）。

難道他們送你回去的某些數據服務（如已採取的金額）？除了等待資金出現在銀行賬戶上之外，您是否有可能看到用戶支付的金額（回覆值，某些API調用等）？如果不是，他們的設計是嚴重缺陷的。

關於篡改，您無法做任何事情來阻止電力用戶更改價值。它甚至不一定必須在瀏覽器級別完成 - 她可以使用像Fiddler這樣的代理來篡改HTTP請求。

但是，你是否應該擔心它，取決於你賣什麼和如何。如果它是一些即時銷售平臺（比如你給一些互聯網資源等），這很糟糕。如果商店是通過郵寄方式發送東西的硬件商店，則可以每次驗證收到的金額，將其與預期的金額進行比較（我想，會有一些自動工具在銀行賬戶中查找收款，因爲通常情況下，您不會向用戶發送內容，直到您看到帳戶中有錢）。

我立即想起了自己在某個地方類似的事情（最可能是SO）：在早期的互聯網商店中，您有時可以在「數量」字段中輸入類似0.01 的東西，服務器，價格是通過乘以（所以你支付0.01實際價格！），而數量被四捨五入到整數！

編輯：他們是否有關於他們給予答覆的文檔？你嘗試過做假交易嗎？

編輯2：由於商店給你回收費金額，這是很好的。但是，這仍然可能對商店造成問題（非技術性），因爲仍需支付的款項將收取。你可以在下一個屏幕上顯示信息，說你收到的數額是你想要的數額的10倍，但是你仍然需要將這筆錢還給騙子（否則它將是非法的）。

很遺憾，店鋪沒有提供某種類型的消息認證代碼處理。實際上，有一個很好的方法可以防止這種欺騙行爲。但是，兩臺服務器必須配合。請參閱HMAC。它看起來很複雜，但這個想法很簡單。我將在簡化的算法中解釋它。

你有一個輸入，比如price=100。你把它交給第三方。目前，這很容易被篡改。但是，讓我們假設我們發送更多字段，price_verification。我們可以使用預先同意的哈希函數和預先同意的鹽來計算此值（您和付款服務器都必須知道它）。然後，您計算price_verification=SHA1(price + someLengthySalt)並將其發送到支付服務器。他們知道算法和鹽，所以他們計算SHA1(received_price + someLengthySalt)。如果兩者不一樣，用戶就是一個騙子，你放棄了交易。當然，只要用戶不知道算法和/或鹽，這是安全的，所以他不能容易地計算price_verification。

然而，鹽應該是非常強大的，算法也許更復雜，如SHA1(SHA1(price)+salt)等）。需要考慮的是，價格的輸入空間非常小（只有2位小數的數字 - 如果沒有鹽，可以很容易地被強迫）。

這可以很容易地擴展到驗證任何數量的參數（您只需要就如何序列化數據達成一致）。

來源

2012-08-16 21:01:24

該提供商確實提供假商店和運行假交易的能力，所以我打算利用這一點。商店通過POST返回交易是否成功，金額以及其他一些細節。我打算將商店收取的金額與我預計收取的金額相匹配，所以我會知道收費是否發生了變化。 – dangowans 2012-08-16 21:17:23

不幸的是，你不能管理商店本身的產品列表。我同意這將是一個很好的選擇！ – dangowans 2012-08-16 21:18:14

看到我的第二個編輯。也許他們提供了一些MAC，但你忽略了它？ – 2012-08-16 21:48:35

我想我會提到商店如何處理這個潛在的安全問題。也許這適用於正在實施安全託管商店頁面的其他人。

商店提供兩種付款方式。首先，「購買」，立即從信用卡中取錢。這是我正在使用的方法。這很容易實施，但不能保證適量的卡被收取。

第二個「preauth」對卡片上的錢持有保留，但在執行額外的「捕獲」事務之前不會花錢。通過添加此步驟，可以在對卡正式充電之前確認預授權費用。如果費用無效，那麼也可以取消卡上的保留。

就我而言，我正在立即進行「捕獲」交易，但會計師可能一起「批量捕獲」所有當天的所有「預認證」。

來源

2012-08-29 17:39:46 dangowans

潛在漏洞發佈到一個託管服務

回答

相關問題