压在透明的玻璃上c-国产精品国产一级A片精品免费-国产精品视频网-成人黄网站18秘 免费看|www.tcsft.com

API安全性已經(jīng)成為企業(yè)組織的一個關(guān)鍵性業(yè)務(wù)發(fā)展問題，而非僅僅是信息安全的問題，很多企業(yè)由于擔(dān)心API安全問題，而不得不推遲新業(yè)務(wù)系統(tǒng)的應(yīng)用。由于當(dāng)前的技術(shù)工具和安全流程無法跟上API安全發(fā)展的步伐。組織必須尋找更有效的API安全防護措施，在API應(yīng)用生命周期的每個階段進行安全性驗證和保護。

2023年API安全事件

API安全公司FireTail認(rèn)為，2023年將成為API泄露事件創(chuàng)紀(jì)錄的一年。根據(jù)該公司的監(jiān)測，今年以來已有超過5億條數(shù)據(jù)信息因為易受攻擊的API應(yīng)用而導(dǎo)致了泄露，其中較為嚴(yán)重的API安全事件包括：

• 2023年1月，豐田（Toyota）、梅賽德斯（Mercedes）、寶馬（BMW）和其他十幾個汽車品牌曝出API相關(guān)漏洞。遠程信息處理系統(tǒng)中的API漏洞不僅僅暴露了客戶數(shù)據(jù)，還允許惡意行為者遠程實現(xiàn)按喇叭、閃爍燈、遠程跟蹤、開關(guān)車門、啟停車輛等操作；
• 同月，T-Mobile公開承認(rèn)，黑客利用一個API漏洞竊取了3700萬客戶的數(shù)據(jù)；
• 2023年2月，Trustwave研究人員發(fā)現(xiàn)，F(xiàn)insify公司的Money Lover個人理財應(yīng)用暴露了其500多萬用戶的電子郵件地址和數(shù)字錢包賬號；
• 2023年3月，CISA發(fā)布了一份關(guān)于Nexx車庫門控制器和智能報警器的安全公告，在超過40,000臺設(shè)備中發(fā)現(xiàn)了存在多個API應(yīng)用漏洞，攻擊者可以利用這些漏洞竊取個人信息，如物理地址、打開車庫門和關(guān)閉警報；
• 2023年6月，Patchstack研究人員報告稱，WooCommerce公司最受歡迎的WordPress支付插件WooCommerce Stripe Gateway中存在一個嚴(yán)重API漏洞，允許未經(jīng)身份驗證的用戶查看用戶訂單的敏感數(shù)據(jù)，包括電子郵件和完整地址。該漏洞累計影響了50萬以上用戶的個人隱私安全；
• 同樣在6月，Eaton Works的一名研究人員入侵了本田汽車電子商務(wù)平臺，通過利用API接口漏洞，他可以重置任何賬戶的密碼，并獲得完整的客戶信息、經(jīng)銷商信息、付款密鑰和內(nèi)部財務(wù)報告。該事件導(dǎo)致了近40,000條車主記錄暴露；
• 2023年7月，為超過18萬家企業(yè)提供云“目錄即服務(wù)”（directory-as-a-service）的軟件服務(wù)商JumpCloud公司，因API相關(guān)漏洞而全部更改了其API應(yīng)用密鑰。

API應(yīng)用安全挑戰(zhàn)

根據(jù)Enterprise Strategy Group公司對超過400家企業(yè)的調(diào)研統(tǒng)計，有超過92%的組織在過去12個月里至少經(jīng)歷了一次與API相關(guān)的安全事件，而導(dǎo)致API應(yīng)用安全事件日益普遍的原因主要包括：API生態(tài)系統(tǒng)的規(guī)模、應(yīng)用復(fù)雜性和快速變化的本質(zhì)。

研究人員發(fā)現(xiàn)，面對API應(yīng)用快速增長，企業(yè)組織最擔(dān)憂的問題是缺少對API訪問行為的有效認(rèn)證和控制。在不久前剛剛更新的2023年度“OWASP TOP 10 API安全風(fēng)險”清單中，和身份驗證和授權(quán)相關(guān)的安全風(fēng)險有四個。而FireTail API數(shù)據(jù)泄露跟蹤報告的相關(guān)數(shù)據(jù)也顯示，在今年所監(jiān)測到的12起公共API應(yīng)用數(shù)據(jù)泄露事件中，每一起都涉及至少一個身份驗證或授權(quán)方面的安全漏洞。

API安全應(yīng)用的另一個重要挑戰(zhàn)是如何識別其中的關(guān)鍵數(shù)據(jù)以及如何監(jiān)控這些數(shù)據(jù)在API生態(tài)系統(tǒng)中安全地流動。為了保證安全性，企業(yè)組織需要弄清楚他們最敏感的數(shù)據(jù)是什么、在哪里、誰可以訪問，并根據(jù)這些信息來設(shè)計API的安全性。不幸的是，很多公司需要手動操作來完成以上工作，這是一個緩慢且易出錯的過程，也無法真正理解API與其所連接的數(shù)據(jù)之間的邏輯關(guān)系。

缺乏可見性也是API安全應(yīng)用的主要挑戰(zhàn)。畢竟，我們無法保護自己看不見的東西。在企業(yè)中，除了API應(yīng)用的開發(fā)者，很少有人會意識到這些API的存在，這使得大量的API缺少維護，并經(jīng)常容易被忽略。當(dāng)組織缺乏適當(dāng)?shù)腁PI可見性、治理機制和生命周期策略時，僵尸、影子和幽靈等可怕的API威脅就會出現(xiàn)。

最后，企業(yè)對API應(yīng)用安全的保障能力存在不足。調(diào)查數(shù)據(jù)顯示，盡管有74%的受訪企業(yè)表示他們已經(jīng)部署了API安全工具，但事實上并未形成有效的防護能力。很多傳統(tǒng)API管理工具，缺乏解決API特有漏洞所需的具體功能，也無法提供檢測特定API攻擊（比如撞庫攻擊和蠻力破解）所需的可見性。

API安全性自查清單

企業(yè)需要尋求更加有效API安全防護策略和方法，以減少API安全治理的復(fù)雜性和管理成本。

參考2023年度“OWASP TOP 10 API安全風(fēng)險”清單，安全研究人員總結(jié)梳理了一份易于遵循的API安全性檢查清單，通過全面的API安全風(fēng)險檢查，企業(yè)可以有效提升API應(yīng)用的安全性。

OWASP – A1 ：對象級授權(quán)

1. 驗證是否使用用戶策略和層次結(jié)構(gòu)實現(xiàn)授權(quán)檢查；
2. 驗證API是否需要依賴于從客戶端發(fā)送的身份ID，API應(yīng)用應(yīng)該檢查會話中存儲對象的ID；
3. 驗證服務(wù)器配置是否按照所使用的應(yīng)用服務(wù)器和框架的建議進行了加固；
4. 驗證API是否實現(xiàn)了在每次客戶端請求訪問數(shù)據(jù)庫時檢查授權(quán)；
5. 驗證API沒有使用隨機猜測ID（UUID）。

OWASP – A2：破損的認(rèn)證

1. 驗證是否全面認(rèn)證所有API；
2. 驗證密碼重置API和一次性鏈接是否允許用戶一起進行身份驗證，并受到嚴(yán)格保護；
3. 驗證API是否實現(xiàn)標(biāo)準(zhǔn)的身份驗證，令牌生成，密碼存儲和多因素身份驗證；
4. 驗證API是否使用了短期訪問令牌；
5. 驗證API是否使用了嚴(yán)格的速率限制身份驗證，并實現(xiàn)鎖定策略和弱密碼檢查。

OWASP – A3：過度的數(shù)據(jù)暴露

1. 驗證API是否依賴于客戶端來過濾數(shù)據(jù)；
2. 驗證API響應(yīng)性，并根據(jù)API使用者的實際需要調(diào)整響應(yīng)；
3. 驗證API規(guī)范性，定義所有請求和響應(yīng)的模式；
4. 驗證錯誤API響應(yīng)是否已經(jīng)明確定義；
5. 驗證所有敏感或PII信息的使用是否有明確的理由；
6. 驗證API強制響應(yīng)檢查措施，以防止意外的數(shù)據(jù)和異常泄漏。

OWASP – A4：缺乏資源和速率限制

1. 驗證是否根據(jù)API方法、客戶端和地址配置了速率限制；
2. 驗證有效載荷限制是否已配置；
3. 在執(zhí)行速率限制時驗證壓縮比；
4. 驗證計算/容器資源上下文中的速率限制。

OWASP – A5：無效的功能級授權(quán)

1. 驗證默認(rèn)情況下是否能夠拒絕所有訪問；
2. 驗證API是否依賴于應(yīng)用程序來強制管理訪問；
3. 驗證所有不需要的功能是否都被禁用；
4. 驗證計算/容器資源內(nèi)容中的速率限制是否有效；
5. 確保僅根據(jù)特定角色授予角色；
6. 驗證授權(quán)策略是否在API中正確實現(xiàn)。

OWASP – A6：批量分配

1. 驗證API是否自動綁定傳入數(shù)據(jù)和內(nèi)部對象；
2. 驗證API是否顯示定義組織期望的所有參數(shù)和有效負(fù)載；
3. 驗證API在設(shè)計時是否精確定義了訪問請求中接受的模式、類型和模式，并在運行時強制執(zhí)行它們。

OWASP – A7：安全配置錯誤

1. 驗證API實現(xiàn)是否可重復(fù)，并且加固和修復(fù)活動已納入開發(fā)過程；
2. 驗證API生態(tài)系統(tǒng)是否具有自動定位配置缺陷的過程；
3. 驗證平臺是否在所有API中禁用了不必要的功能；
4. 驗證API安全系統(tǒng)是否可以限制管理訪問；
5. 驗證所有的輸出是否安全，包括錯誤的輸入；
6. 驗證授權(quán)策略是否在API中正確實現(xiàn)。

OWASP – A8：請求偽造??

1. 驗證API對各類消費者的信任機制是否正確，即使是對內(nèi)部員工的；
2. 驗證API是否嚴(yán)格定義所有輸入數(shù)據(jù)：模式、類型、字符串模式，并在運行時強制執(zhí)行；
3. 驗證API是否可以對所有傳入數(shù)據(jù)進行驗證、過濾和阻斷；
4. 驗證API是否定義、限制和執(zhí)行API輸出，以防止數(shù)據(jù)泄漏。

OWASP – A9：資產(chǎn)管理不當(dāng)

1. 驗證平臺能否限制訪問任何不應(yīng)公開的內(nèi)容；
2. 驗證API應(yīng)用架構(gòu)是否具備額外的外部安全控制，如API防火墻；
3. 驗證一個API應(yīng)用進程是否被有效地管理；
4. 驗證架構(gòu)是否實現(xiàn)嚴(yán)格的API身份驗證、重定向等。

OWASP – A10：日志記錄和監(jiān)控不足

1. 驗證API日志的完整性和準(zhǔn)確性；
2. 驗證日志格式是否可以被其他工具有效使用；
3. 驗證API應(yīng)用管理平臺是否對敏感日志進行了有效保護；
4. 驗證API應(yīng)用平臺是否包含足夠的詳細(xì)信息以識別攻擊者；
5. 驗證平臺與SIEM等其他安全工具是否可以協(xié)同、集成。

來源：安全牛