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

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

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

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

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

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

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

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

URL查詢參數(shù)

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

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

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

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

盡管沒(méi)有正確的身份驗(yàn)證，但仍然顯示客戶的PII

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

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

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

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

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

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

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

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

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

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

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

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

以下是如何改進(jìn)編碼做法的一些建議：

1.會(huì)話和cookie過(guò)期

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

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

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

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

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

3. 破壞對(duì)象級(jí)授權(quán)

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

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

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

給電商平臺(tái)用戶的安全建議

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

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