建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
電子商務(wù)平臺(tái)的物流 API 如果出現(xiàn)安全漏洞，則消費(fèi)者的個(gè)人信息會(huì)被大量暴露。
創(chuàng)新互聯(lián)公司自成立以來(lái)，一直致力于為企業(yè)提供從網(wǎng)站策劃、網(wǎng)站設(shè)計(jì)、網(wǎng)站制作、做網(wǎng)站、電子商務(wù)、網(wǎng)站推廣、網(wǎng)站優(yōu)化到為企業(yè)提供個(gè)性化軟件開(kāi)發(fā)等基于互聯(lián)網(wǎng)的全面整合營(yíng)銷(xiāo)服務(wù)。公司擁有豐富的網(wǎng)站建設(shè)和互聯(lián)網(wǎng)應(yīng)用系統(tǒng)開(kāi)發(fā)管理經(jīng)驗(yàn)、成熟的應(yīng)用系統(tǒng)解決方案、優(yōu)秀的網(wǎng)站開(kāi)發(fā)工程師團(tuán)隊(duì)及專(zhuān)業(yè)的網(wǎng)站設(shè)計(jì)師團(tuán)隊(duì)。
物流 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查詢(xún)參數(shù)
不經(jīng)意間暴露PII的一個(gè)編碼做法涉及電子商務(wù)平臺(tái)和物流API 中的 URL 查詢(xún)參數(shù)。電子商務(wù)平臺(tái)通常要求客戶(hù)登錄帳戶(hù)或選擇訪(fǎng)客結(jié)帳選項(xiàng)。一些在線(xiàn)購(gòu)物網(wǎng)站使用他們通過(guò)電子郵件或短信發(fā)送給用戶(hù)的唯一 URL，將他們重定向到可以訪(fǎng)問(wèn)訂單信息的網(wǎng)站。
將發(fā)送到收件人擁有的電子郵件地址或電話(huà)號(hào)碼的唯一URL的組合使用足以保護(hù)PII的假設(shè)是有問(wèn)題的，因?yàn)檫@會(huì)產(chǎn)生錯(cuò)誤的安全感。研究表明，未經(jīng)授權(quán)的各方仍然可以通過(guò)直接訪(fǎng)問(wèn)URL來(lái)檢索客戶(hù)的PII，而不需要進(jìn)一步的身份驗(yàn)證。
URL參數(shù)中的身份驗(yàn)證密鑰
當(dāng)消費(fèi)者在在線(xiàn)商店下訂單時(shí)，商店會(huì)向他們發(fā)送一封確認(rèn)電子郵件，其中包含 URL 鏈接和 URL 參數(shù)上的身份驗(yàn)證密鑰，以查看訂單詳細(xì)信息。此密鑰用于驗(yàn)證檢查訂單頁(yè)面的用戶(hù)是否是電子郵件的收件人。訂單頁(yè)面包含客戶(hù)姓名、電子郵件地址、電話(huà)號(hào)碼和付款方式等信息。
盡管沒(méi)有正確的身份驗(yàn)證，但仍然顯示客戶(hù)的PII
將身份驗(yàn)證密鑰作為 URL 參數(shù)的一部分傳遞的做法可能會(huì)泄漏 PII，因?yàn)檫@些密鑰仍然可以使用其他方式檢索，例如訪(fǎng)問(wèn)用戶(hù)的瀏覽歷史記錄和路由器日志。使用未加密的 URL 查詢(xún)參數(shù)使 PII 容易受到嗅探和中間人攻擊。
未經(jīng)身份驗(yàn)證的 3PL API
雖然在線(xiàn)零售商使用的 3PL 服務(wù)的基本組件包括訂單處理、運(yùn)輸和跟蹤，但我們還發(fā)現(xiàn) 3PL 提供商的 API（在下圖中稱(chēng)為 X 公司）通過(guò)未經(jīng)身份驗(yàn)證的 API 服務(wù)披露 PII。其他四家 3PL 提供商正在使用此 API 服務(wù)來(lái)顯示客戶(hù)的訂單信息。
四家 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ù)顯示了完整的客戶(hù)信息集
研究人員仔細(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)客戶(hù)和所購(gòu)買(mǎi)商品的完整信息集。因此，任何有權(quán)訪(fǎng)問(wèn)訂單信息 URL 的人都可以重建 URL 以檢索客戶(hù)的 PII。
過(guò)期設(shè)置超過(guò)建議持續(xù)時(shí)間的會(huì)話(huà)和 cookie
另一種不安全的編碼做法是某些 3PL 提供商使用會(huì)話(huà)和 cookie 的過(guò)期日期設(shè)置不當(dāng)。我們觀(guān)察到許多 3PL 提供商不遵守特定于使用會(huì)話(huà)和 cookie 來(lái)規(guī)范身份驗(yàn)證的最佳安全做法的實(shí)例。此方法是開(kāi)放 Web 應(yīng)用程序安全項(xiàng)目 (OWASP) 推薦的最佳做法之一，盡管會(huì)話(huà)生存時(shí)間 (TTL) 應(yīng)始終在事務(wù)完成后或用戶(hù)退出連接后立即過(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ì)話(huà)和cookie過(guò)期
會(huì)話(huà)過(guò)期決定何時(shí)終止會(huì)話(huà)與服務(wù)器的經(jīng)過(guò)身份驗(yàn)證的連接。默認(rèn)情況下，該時(shí)間設(shè)置為一天，或者會(huì)話(huà)在用戶(hù)停止與網(wǎng)站的連接后終止。相同的機(jī)制適用于 cookie 過(guò)期。一旦用戶(hù)不再在網(wǎng)站上執(zhí)行任何操作，應(yīng)激活會(huì)話(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ù)暴露給具有訪(fǎng)問(wèn)限制或有限權(quán)限的帳戶(hù)的情況。物流API泄露的數(shù)據(jù)可能被用于詐騙或欺詐。
從 API 響應(yīng)中暴露過(guò)多信息
開(kāi)發(fā)人員應(yīng)采用識(shí)別交易所需的重要客戶(hù)信息并對(duì)其風(fēng)險(xiǎn)級(jí)別進(jìn)行分類(lèi)的做法。
3. 破壞對(duì)象級(jí)授權(quán)
對(duì)象級(jí)授權(quán)通常在編碼階段實(shí)現(xiàn)，它是一種訪(fǎng)問(wèn)控制策略，用于確保只有經(jīng)過(guò)授權(quán)的用戶(hù)才能訪(fǎng)問(wèn)對(duì)象。對(duì)象級(jí)授權(quán)檢查應(yīng)該在接收對(duì)象ID并對(duì)對(duì)象執(zhí)行任何類(lèi)型操作的每個(gè)API端點(diǎn)中實(shí)現(xiàn)。這些測(cè)試確保已登錄的用戶(hù)具有對(duì)所請(qǐng)求對(duì)象執(zhí)行操作的權(quán)限。
在處理PII時(shí)，更安全的做法是加密數(shù)據(jù)并在授予訪(fǎng)問(wèn)權(quán)之前要求用戶(hù)身份驗(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)用戶(hù)的安全建議
消費(fèi)者在最大限度地降低 PII 暴露風(fēng)險(xiǎn)方面發(fā)揮著同樣重要的作用。以下安全做法可以幫助他們保護(hù) PII 的安全：
- 正確處置發(fā)貨信息，并確保帶有 PII 的標(biāo)簽被撕碎或混淆，這樣攻擊者就無(wú)法再閱讀它們。
- 刪除瀏覽歷史記錄，尤其是在公共或共享設(shè)備上。
- 免將未知瀏覽器擴(kuò)展安裝到可以讀取和收集未加密 URL 查詢(xún)字符串的 Web 瀏覽器。
- 在公共 Wi-Fi 網(wǎng)絡(luò)上使用合法的虛擬專(zhuān)用網(wǎng)絡(luò) (VPN) 以減少個(gè)人數(shù)據(jù)的暴露。
- 對(duì)電子商務(wù)平臺(tái)和其他需要用戶(hù)輸入 PII 的網(wǎng)站實(shí)施雙因素或多因素身份驗(yàn)證。
本文題目：電商平臺(tái)使用的物流API的安全風(fēng)險(xiǎn)
鏈接URL：http://m.5511xx.com/article/djjceos.html
