安全測試之認證授權
在web安全中,認證授權又是每個人都熟知的,就像我們都應該設定一個高強度的密碼,以免被猜測破解,實際上還包括更多內容。
1. 許可權
在很多系統如CRM,ERP,OA中都有許可權管理,其中的目的一個是為了管理公司內部人員的許可權,另外一個就是避免人人都有許可權而帳號洩漏後會對公司帶來的負面影響。
許可權一般分為2種:訪問許可權和操作許可權。訪問許可權即是某個頁面的許可權,對於特定的一些頁面只有特定的人員才能訪問。而操作許可權指的是頁面中具體到某個行為,肉眼能看到的可能就是一個稽核按鈕或提交按鈕。我之前接觸過的一個SAAS平臺的CRM系統就用到了訪問許可權和操作許可權兩種,而現在公司後臺管理都是訪問許可權,當然訪問許可權實施起來更加方便快捷,也容易維護。
許可權的處理方式可以分為2種:使用者許可權和組許可權。設定多個組,不同的組設定不同的許可權,而使用者設定到不同的組中,那就繼承了組的許可權,這種方式就是組許可權管理,一般都是使用這種方式管理。而使用者許可權管理則比較簡單,對每個使用者設定許可權,而不是拉入某個組裡面,但是靈活性不夠強,使用者多的時候就比較費勁了,每次都要設定很久的許可權,而一部分使用者許可權是有共性的,所以組許可權都是目前很通用的處理方式。
在許可權方面,還包括了資料庫的許可權,網站管理的許可權以及API/Service的許可權。
DBA都需要控制好IDC的資料庫許可權,而不是將使用者許可權設定為*.*,需要建立專門供應用程式使用的帳號,並且需要對不同的資料庫和不同的表賦予許可權,專門供應用程式使用的帳號就不能進行更改表,更改資料庫及刪除操作,否則如果有SQL隱碼攻擊漏洞或程式有bug的話,黑客就能輕易連線到資料庫獲取更多的資訊。因為DBA帳號除了可以更改資料庫結構,資料,及配置之外,還可以通過LOAD DATA INFILE讀取某個檔案,相當於整臺伺服器都被控制了。
API可以分為private API和open API。那私有API一般是不希望外網訪問的,如果架設在內網的話,最好使用內網IP來訪問,如果是公網的話,最好設定一定的許可權管理。Open API的許可權就相對複雜很多,除了校驗引數正確性,還需校驗使用者是否在白名單中,在白名單裡的話還需校驗使用者對應的許可權,有些時候還需要考慮是否要加密傳輸等等。
2. 密碼猜測
以下哪種錯誤提示更加適合呢?
1)輸入的使用者名稱不正確
2)輸入的密碼不正確
3)輸入的使用者名稱或密碼不正確
看到前面兩種提示資訊,我們獲得了什麼資訊呢?使用者名稱不正確那可以猜測到正確的使用者名稱,當只是提示密碼不正確的時候說明使用者名稱正確了,這兩種提示其實是在暗示使用者正確輸入了什麼,哪個不正確。而第三種給出的提示就比較模糊,可能是使用者名稱可能是密碼錯誤。如果非要說前兩種提示資訊更準確更易於普通使用者的話,就會給黑客們帶來可乘之機,而第三種就沒轍了,實在不知道到底是哪個錯誤了,難道增加不少。使用工具或批處理指令碼來強制列舉破解的話也需要更多的時間。
弱密碼你中槍了嗎?
2011年11月22日,360安全中心釋出了中國網民最常用的25個“弱密碼”: 000000、111111、11111111、112233、123123、123321、123456、12345678、654321、666666、888888、abcdef、abcabc、abc123、a1b2c3、aaa111、123qwe、qwerty、qweasd、admin、password、passwd、iloveyou、5201314。別人給我使用過的管理帳號中就有設定這樣的密碼,非常危險。
那如何應對密碼猜測攻擊呢?一般有以下幾種方案:1)超過錯誤次數帳戶鎖定;2)使用RSA/驗證碼;3)使用安全性高的密碼策略。很多網站三種結合起來使用的。另外,在儲存密碼到資料庫時也一定要檢查是否經過嚴格的加密處理,不要再出現某天你的網站被暴庫了結果還存的是明文密碼。
3. 找回密碼的安全性
最不安全的做法就是在郵件內容中傳送明文新密碼,一旦郵箱被盜,對應網站的帳號也會被盜;一般做法是郵件中傳送修改密碼連結,測試時就需要特別注意使用者資訊標識是否加密,加密方法以及是否易破解;還有一種就是修改時回答問題,問題回答正確才能進行修改,大名鼎鼎的QQ就是這麼做的。據傳,原來支付寶有個很嚴重的安全問題,就是完全可以通過手機號碼找回登入密碼和支付密碼,會傳送驗證碼到手機然後登入網頁修改密碼,有使用者手機號碼停機後,別人買了這個號然後登入了支付寶把錢轉走了,現在支付寶找回登入密碼時仍然可以通過手機號碼找回,但是支付密碼修改就需要手機簡訊和身份證件一起驗證。不過我們很多人難免會在網路上留下手機號碼的痕跡,聰明的善於挖掘彙總資訊的人一定可以找到你的身份證號碼,所以友情提示下:更換號碼時一定要及時修改帳號關聯的手機號碼。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/11323760/viewspace-1062483/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 認證授權方案之授權初識
- 認證授權方案之JwtBearer認證JWT
- 認證授權方案之授權揭祕 (上篇)
- 認證授權
- 【認證與授權】Spring Security系列之認證流程解析Spring
- 使用請求頭認證來測試需要授權的 API 介面API
- 【認證與授權】Spring Security的授權流程Spring
- Ocelot(四)- 認證與授權
- OAuth 2.0 授權碼認證OAuth
- puppet自動認證授權
- 授權(Authorization)和認證(Authentication)
- Ceph配置與認證授權
- Spring Security OAuth2.0認證授權四:分散式系統認證授權SpringOAuth分散式
- 認證授權問題概覽
- OAuth 2.0 授權認證詳解OAuth
- EMQX Cloud 更新:外部認證授權MQCloud
- shiro授權和認證(四)
- 認證授權:IdentityServer4IDEServer
- 認證授權:學習OIDC
- 細說API - 認證、授權和憑證API
- 基於.NetCore3.1系列 —— 認證授權方案之授權揭祕 (下篇)NetCore
- 【認證與授權】2、基於session的認證方式Session
- Oauth2認證模式之授權碼模式實現OAuth模式
- 認證/授權與許可權的問題
- 認證授權:IdentityServer4 - 各種授權模式應用IDEServer模式
- 認證授權:學習OAuth協議OAuth協議
- OAuth2.0認證授權workflow探究OAuth
- 靈活多樣認證授權,零開發投入保障 IoT 安全
- 認證授權的設計與實現
- JAAS中的認證與授權問題
- SpringSecurity認證和授權流程詳解SpringGse
- 聊聊常見的服務(介面)認證授權
- SpringSecurity(1)---認證+授權程式碼實現SpringGse
- 中介軟體---登陸認證授權---Shiro
- Java Web系列:JAAS認證和授權基礎JavaWeb
- 微服務下認證授權框架的探討微服務框架
- 網站安全滲透測試檢測認證登入分析網站
- 網路驗證之授權碼使用