web application 存取控制

來源:互聯網
上載者:User

標籤:info   強制   mat   logs   roc   zed   author   受限   flow   

http://secappdev.org/handouts/2012/Jim%20Manico%20%26%20%20Eoin%20Keary/Final%20-%20Access%20Control%20Module%20v4.1.pdf

什麼是access control/authorization?

authorization is the process where a system determines if a specific user has access to a particular resource.

在上面的定義中有幾個關鍵詞: process, specific user, particular resource

authorization的目的是ensure that a user only access system functionality to which he is entitled.也就是說讓使用者具有已經賦予他的權利來訪問他可以訪問的資源

 

凡是網站有使用者就有存取控制的需求,傳統上基於RBAC(Role based access control)可以實現粗放的存取控制,但是RBAC也有非常明顯的問題:就是控制粒度太大,無法動態對某個資源來實現控制,要麼可以訪問,要麼不能訪問,而現實中很多情況下是:可以讀訪問部分資源,讀寫自己建立的資源,這種情況下RBAC就無能為力了。總的來說,RBAC無法解決水平存取控制的問題(horizontal access control)

對存取控制的惡意攻擊

1. Vertical access control attacks

    一個低許可權的使用者訪問高許可權功能(a standard user accessing administration functionality)

2. Horizontal access control attacks

    相同角色的使用者去訪問其他使用者的私人資料(same role, but accessing another user‘s private data)

3. Business logic access control attacks

   abuse of workflow

存取控制的issues

1. 需要application僅實現了一個"all or nother" approach:一旦authenticated那麼所有使用者都有相同的許可權

2. authorization logic通常依賴於預設環境是安全的並且會假設:使用者不會找到unlinked functionality或者說是hidden path/functionality, 使用者不會找到並且篡改那些隱藏的用戶端參數(比如:hidden form filed, cookies等)

3. 在應用中一旦有了多個permission level/roles這總會增加permission set間許可權衝突可能從而使得許可權系統工作紊亂

典型的許可權控制不好的實現實踐

1. 在application code中hard-coded role check

void   editProfile(User u, EditUser eu) {   if (u.isManager()) { editUser(eu)     } } 

帶來的問題: what needs to occur in order to change the access control policy of this feature?

 a. 使得證明我們已經實現了應用的授權策略非常困難

 b. 任何時候存取控制策略policy需要變更,那麼就必須修改代碼

 c. 脆弱而易於犯錯誤

 d. 無法實現自動化,需要在每一個application feature上來做hand-coded

 

2. 缺乏集中的存取控制邏輯

看看下面的分散參數控制情況: 

http://example.com/buy?action=chooseDataPackagehttp://example.com/buy?action=customizePackagehttp://example.com/buy?action=makePaymenthttp://example.com/buy?action=downloadData攻擊者可以通過concurrency就可能擷取不應有的許可權

3. 不可信資料卻驅動著存取控制決策

 a. 永遠不要信任從用戶端來的資料做存取控制決策

 b. 永遠不要在javascript中做存取控制決策

 c. 永遠不要只基於以下資訊來做存取控制決策:

    c.1: hidden fields

    c.2: cookie value

    c.3: form parameters

    c.4: url parameters

 d. 永遠不要依賴於用戶端發送過來參數值的順序來做決策

 

4. 存取控制遵循了"open by default”的原則,這將開放不必要的許可權

   很多administrative interfaces僅僅需要一個密碼就授權了。共用帳號而又缺乏auditing和logging會導致區分好人和壞人非常困難。admin interface往往不如user-level interface那麼安全因為總是假設administrators是值得信任的使用者

 

 

5. 缺乏解決水平存取控制的標準方法

6. access contro邏輯必須手工地加到每一個endpoin中

攻擊存取控制系統

1. elevation of privileges

2. 披露敏感資訊: 比如admin-level的帳號往往能夠訪問一個使用者的私密資訊

3. 資料篡改: 特權層級往往對於那些可以查看資料的使用者和可以修改使用者的資料不加以區分

testing for broken access control

試圖作為一個匿名使用者或者一個普通使用者來訪問admin components/functions:修改html hidden form fields, 測試web accessible directory structure for names,比如admin,administrator,manager等等:即直接存取那些受限的資源

試圖摸清administrator是如何被authenticated的。我們需要確保充足的鑒權渠道被使用,甚至可以加上普通密碼加上註冊手機得到的臨時密碼來鑒權

對於每一個user role,需要確保適當的pages或者components可以被那個role所訪問

Access control best practices:

1. 通過role based access control來對使用者assign permissions以實現vertical access control requirements;

2. 通過data-contextual access control在特定data items上下文環境中授權給特定使用者以實現horizontal access control requirements

3. 避免直接對單個使用者來做assign permissions動作

4. 對應用的所有pages都執行一致的authorization checking routings;

5. 如果可能,在最後應用apply DENY, case-by-case來 issue allow privilege

6. 實現一個集中的access control mechanism

7. code to the activity(permission), not the role

 8. 集中access control logic

9. 將access control作為一個filter或者說middleware

10. Deny by default, fail securely

11. 將相同的核心授權邏輯應用程式到presentation(view視圖)層和server-side access-control decisions中

12. server-side受信資料應該作為驅動access-control的資料來源頭

13. 可以在即時運行時修改一個使用者的role

14. build grouping capability for users and permissions

Code to the activity/permission

// 不再像下面的if ((user.isManager() ||     user.isAdministrator() ||     user.isEditor() ||    user.isUser() &&     user.id() != 1132)) {     //execute action}// 而應該像這樣:if (AC.hasAccess(ARTICLE_EDIT)) {   //execute activity}

code it once, never needs to change again

implies policy is persisted/centralized in some way

requires more design/work up front to get right

定義一個centralized ACL Controller:定義一個集中的ACL Controller

ACLService.isAuthorized(ACTION_CONSTANT) 
ACLService.assertAuthorized(ACTION_CONSTANT)

所有的access control decision都通過這些簡單的api來實現

集中的授權邏輯驅動policy behavir and persistence

可能包含data-driven access control policy information

如何使用一個centralized access controller

1. 在視圖presntation layer:

if (isAuthorized(VIEW_LOG_PANEL)){   <h2>Here are the logs</h2>  <%=getLogs();%/>} 

2. 在控制層controller中:

try (assertAuthorized(DELETE_USER)){   deleteUser();}

永遠在server端驗證policy:

1. 將user id verification放在session中;

2. 從受信任的server端資料來源頭來載入entitlements

3. 對所有的requests都強制authorization check: 包括js檔案發起的request,mage, ajax, flash request都要強制authorization check, 最好通過一個通用的middleware來實現這個強制鑒權功能

 

web application 存取控制

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.