• Authorization 授權的資訊安全設計原則、測試、個案與實作

    Authorization 主要是在經過認證完之後,跟對該使用者對於系統資源存取的”授權”,

    因此怎樣的權限可以存取哪些資料就是 Authorization的範疇。基本要回答的問題是

    • 使用者可以使用這個功能嗎?
    • 進一步是問這個功能針對該使用者存取的範圍是否應該限制?

    我們將討論安全設計的準則、新聞個案討論、測試的方法與實務設計的建議。

     

    基本安全設計準則

    基本安全設計的準則有

    • 所有的頁面應該都需要經過授權才能存取
    • 所有的功能或是頁面必須確認資訊的內容是否經過授權
    • 伺服器與資料庫等權限的設定

     

    所有的頁面應該都需要經過授權才能存取

     

    針對網頁來說,最著名的攻擊方式就是 Forced Browsing 或是 Directory Traversal

    新聞個案 Directory Traversal

    https://cwe.mitre.org/data/definitions/548.html

    http://www.securityfocus.com/archive/1/506000/100/0/threaded

    駭客有可能透過 ULR 參數的不同,間接讀取到不屬於自己的相關資料。

    http://localhost/cuteflow/pages/edituser.php?userid=1&language=pt&sortby=strLastName&sortdir=ASC&start=1

     

    前端與後端都要確認權限的存取

    為什麼前端使用者輸入時就已經檢查過,後端伺服器或是資料庫還要額外檢查呢?

    主要是因為駭客可以透過 FireFox Add Tamper Data 這樣的工具跳過前端的檢查,而將資料直接輸入到後端伺服器

    PayPal 新聞案例

    http://letsearndollar.blogspot.com/2009/07/change-any-paypal-price-with-data.html

    例如 PayPal 在結帳時的運費與稅率,可以透過 Tamper Data 的方式被修改為 “0”

     

    安全設計提醒

    • 所有的頁面應該都需要經過授權才能存取
    • 所有的功能或是頁面必須確認資訊的內容是否經過授權 (避免 Directory listing or traversal)
    • 除了前端檢查輸入的資料之外,後端資料庫與伺服器也要相對的檢查
    • 伺服器與資料庫等權限的設定

    另外 OWASP 針對 Access Control 的部分建議如下

    • Code to the activity, not the role
    • Centralize access control logic
    • Design access control as a filter
    • Deny by default, fail securely
    • Build centralized access control mechanism
    • Apply same core logic to presentation and server-side access control decisions
    • Determine access control through Server-side trusted data

    Posted by Tony @ 3:40 pm

  • Leave a Reply

    Your email address will not be published.