主要表現(xiàn)
強(qiáng)制執(zhí)行訪問控制策略，
使用戶無法執(zhí)行超出其預(yù)期權(quán)限。失敗策略通常會導(dǎo)致未經(jīng)授權(quán)的信息披露、修改或銷毀或執(zhí)行超出用戶權(quán)限的業(yè)務(wù)功能。
常見的訪問控制漏洞包括：
通過修改URL，內(nèi)部應(yīng)用程序狀態(tài)，或者HTML頁面繞過訪問控制檢查，或者使用自定義API 攻擊工具。
允許將主鍵更改為其他用戶記錄，允許查看或編輯他人的帳戶。
特權(quán)提升。在沒有登錄的情況下充當(dāng)用戶，或以用戶身份登錄時充當(dāng)管理員。
元數(shù)據(jù)操作，例如重放或篡改JSON Web令牌（JWT）訪問控制令牌或操作的cookie或隱藏字段以提升權(quán)限或?yàn)E用JWT無效
CORS配置錯誤允許未經(jīng)授權(quán)的API訪問
強(qiáng)制瀏覽經(jīng)過身份驗(yàn)證的頁面作為未經(jīng)身份驗(yàn)證的用戶，或訪問特權(quán)頁面作為標(biāo)準(zhǔn)用戶。訪問API缺少POST，PUT和DELETE的訪問控制
預(yù)防方法
訪問控制僅在受信任的服務(wù)器端強(qiáng)制執(zhí)行時才有效
代碼或無服務(wù)器API，攻擊者無法修改
訪問控制檢查或元數(shù)據(jù)。
除公共資源外，默認(rèn)拒絕
實(shí)施一次訪問控制機(jī)制并重新使用它們，整個應(yīng)用程序，包括最小化CORS使用
模型訪問控制應(yīng)該強(qiáng)制執(zhí)行記錄所有權(quán)，而不是接受用戶可以創(chuàng)建，閱讀，更新或刪除，任何記錄
應(yīng)具有獨(dú)特的應(yīng)用程序業(yè)務(wù)限制要求，由域模型強(qiáng)制執(zhí)行
禁用Web服務(wù)器目錄列表并確保文件元數(shù)據(jù)（例如.git）和備份文件不存在于Web根目錄中
記錄訪問控制失敗，在適當(dāng)時提醒管理員（例如重復(fù)失?。?。
速率限制API和控制器訪問，以最大限度地減少傷害自動攻擊工具
注銷后，JWT令牌應(yīng)在服務(wù)器上失效。開發(fā)人員和QA人員應(yīng)包括功能訪問控制
單元和集成測試
常見方法
DAC
MAC
RBAC
ABAC
訪問控制設(shè)計(jì)原則
- 開發(fā)初始前徹底設(shè)計(jì)好訪問控制
一旦您選擇了一個特定的訪問控制設(shè)計(jì)模式，這通常是困難和耗時時使用新模式重新設(shè)計(jì)應(yīng)用程序中的訪問控制。訪問控制是應(yīng)用程序安全設(shè)計(jì)的主要領(lǐng)域之一，必須徹底預(yù)先設(shè)計(jì)，特別是在滿足多租戶和水平（數(shù)據(jù)相關(guān)）訪問控制。
訪問控制設(shè)計(jì)可以從簡單的開始，但通常會發(fā)展為復(fù)雜的、功能豐富的安全控制。在評估軟件框架的訪問控制能力時，確保您的訪問控制功能將允許為您的特定訪問進(jìn)行自定義控制功能需要。
- 強(qiáng)制所有請求進(jìn)行訪問控制檢查
確保所有請求都經(jīng)過某種訪問控制驗(yàn)證層。諸如Java過濾器或其他自動請求處理機(jī)制的技術(shù)是理想的程序組件，有助于確保所有請求通過某種訪問控制檢查。
- 默認(rèn)拒絕
默認(rèn)情況下，拒絕是一個原則，即如果請求不被特別允許，它將被拒絕。這條規(guī)則在應(yīng)用程序代碼中有許多體現(xiàn)方式。
其中的一些例子是：
應(yīng)用程序代碼在處理訪問控制時可能引發(fā)錯誤或異常請求。在這些情況下，應(yīng)始終拒絕訪問控制。
當(dāng)管理員創(chuàng)建新用戶或用戶注冊新帳戶時，在配置該訪問之前，默認(rèn)情況下，帳戶應(yīng)具有最小或無訪問權(quán)限。
向應(yīng)用程序添加新功能時，應(yīng)拒絕所有用戶使用該功能。直到他正確配置了。
- 最小權(quán)限原則
確保僅以最少或盡可能少的方式提供所有用戶，程序或進(jìn)程訪問權(quán)限。警惕不提供細(xì)粒度訪問控制的系統(tǒng)配置功能。
- 不要硬編碼角色
許多應(yīng)用程序框架默認(rèn)為基于角色的訪問控制。這是常見的查找用這種性質(zhì)的檢查填充的應(yīng)用程序代碼。
if (user.hasRole("ADMIN")) || (user.hasRole("MANAGER")) {
deleteAccount();
}
在代碼中注意這種基于角色的編程。它有以下限制或者危險。
這種基于角色的編程是脆弱的。在代碼中很容易造成錯誤或缺少
對角色檢查。
基于角色的編程不適用于多租戶。極端措施如
需要為每個客戶分配代碼或添加支票,
基于角色系統(tǒng)，需要為不同的客戶提供不同的規(guī)則。
基于角色的編程不允許對特定數(shù)據(jù)或水平訪問做控制。
具有許多訪問控制檢查的大型代碼庫可能難以審計(jì)或驗(yàn)證總體應(yīng)用程序訪問控制策略。
相反，請考慮以下訪問控制編程方法：
if (user.hasAccess("DELETE_ACCOUNT")) {
deleteAccount();
}
這種基于屬性或者功能的訪問控制檢查是
建設(shè)設(shè)計(jì)完善、功能豐富的門禁系統(tǒng)。這種程序設(shè)計(jì)
還允許隨著時間的推移提供更大的訪問控制自定義功能
- 記錄所有訪問控制事件
應(yīng)記錄所有訪問控制失敗，因?yàn)檫@些可能表示惡意用戶
探測應(yīng)用程序的漏洞。
