電子商務(wù)平臺的物流 API 如果出現(xiàn)安全漏洞，則消費者的個人信息會被大量暴露。

物流 API 整合了企業(yè)和第三方供應(yīng)商之間的數(shù)據(jù)和服務(wù)，以解決各種市場需求。如果 API 集成不當(dāng)，可能會出現(xiàn)泄露個人身份信息 (PII) 的風(fēng)險。許多使用 API 通信的垂直行業(yè)應(yīng)該得到足夠的保護，尤其是在傳輸敏感數(shù)據(jù)時。否則，無意的 PII 泄漏不僅會對未能履行其法律或合規(guī)義務(wù)的組織造成嚴重后果，也會對暴露 PII 的消費者造成嚴重后果。

什么是外部物流供應(yīng)商？

外部物流供應(yīng)商說白了就是商家用來交付產(chǎn)品的快遞服務(wù)（第二方物流或 2PL），也可以是由倉儲、電商平臺和交付產(chǎn)品組成的第三方物流 (3PL) 服務(wù)。下圖顯示了外部物流提供商在不同用例中的工作方式。

外部物流提供商如何在不同用例中發(fā)揮作用

最初，研究人員調(diào)查了通過不安全的方法無意中暴露PII的3PL和4PL提供商。但隨著研究的深入，我們也發(fā)現(xiàn)，除了 3PL 和 4PL 提供商會暴露敏感信息外，已經(jīng)集成到其系統(tǒng)中的服務(wù)也存在自身的安全漏洞，從而加劇了整個電子商務(wù)生態(tài)系統(tǒng)的風(fēng)險。電子商務(wù)平臺允許商家通過 API 整合現(xiàn)有的外部物流提供商，將不同的服務(wù)整合到一個平臺中。電子商務(wù)平臺和物流提供商共享的 API 密鑰和身份驗證密鑰旨在促進一個安全的通信渠道。

PII是如何從電子商務(wù)和物流API實現(xiàn)中泄露的？

PII 從物流 API 實施中暴露的方式有很多，這些方式與不安全的編碼做法相關(guān)。

URL查詢參數(shù)

不經(jīng)意間暴露PII的一個編碼做法涉及電子商務(wù)平臺和物流API 中的 URL 查詢參數(shù)。電子商務(wù)平臺通常要求客戶登錄帳戶或選擇訪客結(jié)帳選項。一些在線購物網(wǎng)站使用他們通過電子郵件或短信發(fā)送給用戶的唯一 URL，將他們重定向到可以訪問訂單信息的網(wǎng)站。

將發(fā)送到收件人擁有的電子郵件地址或電話號碼的唯一URL的組合使用足以保護PII的假設(shè)是有問題的，因為這會產(chǎn)生錯誤的安全感。研究表明，未經(jīng)授權(quán)的各方仍然可以通過直接訪問URL來檢索客戶的PII，而不需要進一步的身份驗證。

URL參數(shù)中的身份驗證密鑰

當(dāng)消費者在在線商店下訂單時，商店會向他們發(fā)送一封確認電子郵件，其中包含 URL 鏈接和 URL 參數(shù)上的身份驗證密鑰，以查看訂單詳細信息。此密鑰用于驗證檢查訂單頁面的用戶是否是電子郵件的收件人。訂單頁面包含客戶姓名、電子郵件地址、電話號碼和付款方式等信息。

盡管沒有正確的身份驗證，但仍然顯示客戶的PII

將身份驗證密鑰作為 URL 參數(shù)的一部分傳遞的做法可能會泄漏 PII，因為這些密鑰仍然可以使用其他方式檢索，例如訪問用戶的瀏覽歷史記錄和路由器日志。使用未加密的 URL 查詢參數(shù)使 PII 容易受到嗅探和中間人攻擊。

未經(jīng)身份驗證的 3PL API

雖然在線零售商使用的 3PL 服務(wù)的基本組件包括訂單處理、運輸和跟蹤，但我們還發(fā)現(xiàn) 3PL 提供商的 API（在下圖中稱為 X 公司）通過未經(jīng)身份驗證的 API 服務(wù)披露 PII。其他四家 3PL 提供商正在使用此 API 服務(wù)來顯示客戶的訂單信息。

四家 3PL 公司使用另一家 3PL 公司的 API 檢索訂單和跟蹤信息

當(dāng)我們通過四個 3PL 提供商中的一個提供的 URL 鏈接檢查訂單信息頁面，并檢查為查看訂單詳細信息而發(fā)出的 HTTP 請求時，研究人員發(fā)現(xiàn)他們正在查看的頁面正在后臺向另一個 3PL 發(fā)出 HTTP 請求供應(yīng)商獲取訂單詳情。

從 API 請求中檢索到的數(shù)據(jù)顯示了完整的客戶信息集

研究人員仔細檢查了訂單信息頁面 URL 的參數(shù)。其中一個在后臺發(fā)出的 API 請求使用未經(jīng)身份驗證的方法來驗證 API 請求，該請求返回了有關(guān)客戶和所購買商品的完整信息集。因此，任何有權(quán)訪問訂單信息 URL 的人都可以重建 URL 以檢索客戶的 PII。

過期設(shè)置超過建議持續(xù)時間的會話和 cookie

另一種不安全的編碼做法是某些 3PL 提供商使用會話和 cookie 的過期日期設(shè)置不當(dāng)。我們觀察到許多 3PL 提供商不遵守特定于使用會話和 cookie 來規(guī)范身份驗證的最佳安全做法的實例。此方法是開放 Web 應(yīng)用程序安全項目 (OWASP) 推薦的最佳做法之一，盡管會話生存時間 (TTL) 應(yīng)始終在事務(wù)完成后或用戶退出連接后立即過期。攻擊者可以使用檢測到的 cookie 密鑰來重放交易并獲取 PII，他們可以利用這些 PII 來啟動惡意計劃。

該列表顯示了過期日期設(shè)置超過 OWASP 建議的持續(xù)時間的 cookie，從而使 cookie 信息可供攻擊者重播交易

解決不安全編碼做法的安全建議

泄露的 PII 的誘惑、其潛在的惡意用途以及 API 在電子商務(wù)中發(fā)揮的關(guān)鍵作用，都強有力地證明了利益相關(guān)方需要采用一種審慎的方法來確保物流API實現(xiàn)的安全性。

以下是如何改進編碼做法的一些建議：

1.會話和cookie過期

會話過期決定何時終止會話與服務(wù)器的經(jīng)過身份驗證的連接。默認情況下，該時間設(shè)置為一天，或者會話在用戶停止與網(wǎng)站的連接后終止。相同的機制適用于 cookie 過期。一旦用戶不再在網(wǎng)站上執(zhí)行任何操作，應(yīng)激活會話超時，以防止重復(fù)使用過期的 cookie。

2. 過多的數(shù)據(jù)暴露

當(dāng)暴露超出事務(wù)要求的數(shù)據(jù)時，就會發(fā)生過多的數(shù)據(jù)暴露。一些開發(fā)人員實現(xiàn)發(fā)送交易的所有信息，而不是完成交易所需的信息。這會造成數(shù)據(jù)暴露給具有訪問限制或有限權(quán)限的帳戶的情況。物流API泄露的數(shù)據(jù)可能被用于詐騙或欺詐。

從 API 響應(yīng)中暴露過多信息

開發(fā)人員應(yīng)采用識別交易所需的重要客戶信息并對其風(fēng)險級別進行分類的做法。

3. 破壞對象級授權(quán)

對象級授權(quán)通常在編碼階段實現(xiàn)，它是一種訪問控制策略，用于確保只有經(jīng)過授權(quán)的用戶才能訪問對象。對象級授權(quán)檢查應(yīng)該在接收對象ID并對對象執(zhí)行任何類型操作的每個API端點中實現(xiàn)。這些測試確保已登錄的用戶具有對所請求對象執(zhí)行操作的權(quán)限。

在處理PII時，更安全的做法是加密數(shù)據(jù)并在授予訪問權(quán)之前要求用戶身份驗證。當(dāng)使用3PL API集成時，在與3PL相關(guān)供應(yīng)商共享PII時，應(yīng)該充分保護PII。有許多不同的身份驗證算法可用于保護API事務(wù)。令牌如JSON Web令牌(JWT)或使用使用salt編碼的base64生成的自定義令牌對于保護API調(diào)用是必不可少的。

總之，開發(fā)人員應(yīng)牢記在整個交易過程中應(yīng)提供哪些數(shù)據(jù)以及應(yīng)采取哪些身份驗證措施。

給電商平臺用戶的安全建議

消費者在最大限度地降低 PII 暴露風(fēng)險方面發(fā)揮著同樣重要的作用。以下安全做法可以幫助他們保護 PII 的安全：

• 正確處置發(fā)貨信息，并確保帶有 PII 的標簽被撕碎或混淆，這樣攻擊者就無法再閱讀它們。
• 刪除瀏覽歷史記錄，尤其是在公共或共享設(shè)備上。
• 免將未知瀏覽器擴展安裝到可以讀取和收集未加密 URL 查詢字符串的 Web 瀏覽器。
• 在公共 Wi-Fi 網(wǎng)絡(luò)上使用合法的虛擬專用網(wǎng)絡(luò) (VPN) 以減少個人數(shù)據(jù)的暴露。
• 對電子商務(wù)平臺和其他需要用戶輸入 PII 的網(wǎng)站實施雙因素或多因素身份驗證。