安全編碼實踐之三：身份驗證和會話管理防護

聲明：本文由Bypass整理並翻譯，僅用於安全研究和學習之用。

文章來源：https://medium.com/bugbountywriteup/how-to-write-secure-code-d4823bc2e86d

如何編寫安全代碼？保護本身免受破碎的身份驗證和會話管理！

須要安全代碼？

我一直致力於安全編碼實踐，並試圖儘量多地學習基本要點。在過去的幾年裏，我已經意識到一個小小的漏洞在普通人的生活中可能形成的傷害。像WannaCry和Petya勒索軟件這樣的網絡攻擊在幾個遭受其緣由的人心目中是至關新鮮的。

研究人員仍然能夠在網絡應用程序和其餘領域中發現另外一個很是嚴重的錯誤。除非程序員本身意識到他們正在編寫的代碼，不然這種趨勢不會降低。代碼不只應該可以執行它應該執行的預期工做，並且還可以抵禦任何惡意負載和攻擊場景。實現這一目標的最佳方式是可以在編碼和安全社區之間創建協同做用，並相互幫助。

咱們來挖掘吧！

那麼，這篇特別的文章「如何編寫安全代碼？」專一於身份驗證和會話管理問題。

身份驗證和會話管理相關的應用程序功能存在安全缺陷，容許攻擊者破壞密碼，密鑰，會話令牌或利用其餘實現缺陷來承擔其餘用戶的身份。

在本文中，我將介紹幾種不一樣類型的攻擊和方法，您可使用它們來防止它們： -

1.硬編碼登陸憑據

硬編碼登陸憑據是程序員能夠犯的最大錯誤之一，由於它與在銀盤上爲黑客提供憑證同樣好。敏感數據永遠不該該是硬編碼的。

不安全的代碼 - 硬編碼的信用卡

上面的代碼是其中一個示例，其中登陸憑證在程序員編寫的代碼中進行了硬編碼。

雖然下面的代碼是一個示例，其中憑證在程序中沒有硬編碼，使得它比信用卡硬編碼的指數更加安全。

安全代碼 - 信用證不是硬編碼的

這種小差別會對應用程序的安全性產生巨大影響。

2. Cookie操做

隨着愈來愈多的身份驗證過程經過檢查用戶提供的cookie細節來執行，Cookie操做正在成爲當今最危險的攻擊之一。

攻擊者正在尋找方法來打破並弄清楚網絡應用程序如何分配cookie，以便他們能夠操縱它們並像其餘用戶進行賬戶接管同樣構成。

讓我演示攻擊者如何利用分配給用戶的弱cookie或者cookie保持不變。

 這邊的圖像是一個登陸門戶，咱們將進行攻擊並顯示弱cookie實現的問題。

一旦咱們登陸到應用程序，咱們就會攔截Burp-Suite中的流量，以查看它以及傳遞給用戶身份驗證咱們的cookie。

Cookie細節

上圖顯示了咱們嘗試登陸時分配的四個「Set-Cookie」參數。這四個不一樣的cookie登陸，PHPSESSID，顯示提示，用戶名和uid。咱們懷疑uid對每一個用戶都是惟一的。因此咱們繼續篡改uid以檢查咱們是否能夠訪問其餘人的賬戶。

修改cookie

要捕獲cookie的值，咱們使用瀏覽器中存在的Cookie Manager擴展，而後傳遞請求。咱們將「uid」從24改成12，以下所示。

修改過的cookie

一旦咱們修改了cookie值，咱們就能夠看到，當咱們訪問其餘用戶的賬戶時，咱們已經執行了賬戶接管攻擊。

此次攻擊經歷的緣由是，在用戶登陸以前和以後，PHPSESSID根本沒有被修改，所以「uid」是識別哪一個用戶剛剛登陸到他們賬戶的惟一決定因素。正如咱們上面所看到的那樣，很容易被操縱，容許賬戶接管。

爲了不這種狀況發生，咱們須要在登陸嘗試後從新分配cookie，咱們須要記住，cookie也必須是惟一的。如下是如何執行如下操做的想法。

//問題是正在使用相同的會話對象，所以獲取當前會話
HttpSession before_login = request.getSession（）;
//使該會話無效
before_login.invalidate（）;
//生成一個新會話，新的JSESSIONID 
HttpSession after_login = request .getSession（true）;

上面的代碼用於在登陸先後更改SESSIONID cookie。

3.經過Web服務進行用戶枚舉

枚舉問題很是嚴重，由於它可讓攻擊者弄清楚應用程序中存在的用戶的用戶名/電子郵件ID，如下細節能夠在之後用於暴力攻擊。

咱們使用Widsler擴展並利用它的「getuser」功能對Burp-Suite進行此攻擊。所以，當咱們輸入有效的用戶名時，咱們嘗試從系統收集響應，而後咱們輸入一個不是用戶名的隨機字符串，而後檢查響應。咱們能夠在下面的圖像中看到相應的響應。

用戶不存在

上面的圖像是咱們在具備特定用戶名的用戶不存在時收到的請求和響應。咱們在轉發器中發送了請求查詢以檢查響應。

 

 用戶確實存在

上面的圖像是咱們收到的用戶確實存在的條件的請求和響應。咱們在轉發器中發送了請求查詢以檢查響應，並在這次得到了不一樣的響應。這給了咱們一個想法，咱們能夠根據咱們收到的響應來枚舉用戶。

所以，咱們在入侵者選項卡中傳遞請求，而後執行蠻力來檢查使用該應用程序的各個用戶。

枚舉的用戶名

這裏的主要問題是開發人員實際上在響應查詢中放了太多細節。正如在此次攻擊中咱們能夠清楚地看到，因爲響應中的信息太多，咱們能夠弄清楚哪些用戶具備相應的用戶名，哪些用戶沒有。咱們須要製做一些標準化的消息，以便攻擊者不能僅僅使用一些簡單的枚舉技術。

4.暴力攻擊

這是攻擊者經過前一種方法枚舉用戶及其用戶名後執行的下一階段攻擊。

 

旁邊的圖像顯示咱們已經枚舉用戶的登陸頁面，須要執行暴力攻擊才能知道這些用戶的登陸憑據。

所以，當咱們嘗試登陸時，咱們攔截Burp-Suite中的流量並捕獲請求數據包並將其發送給入侵者。

 

請求查詢

如今，咱們已經枚舉了用戶名，咱們執行命中和嘗試，暴力攻擊。咱們從互聯網上獲取一組經常使用密碼並運行咱們的攻擊以找出相應的密碼。

經過Burp-Suite進行蠻力攻擊

在任何狀況下都毫不容許暴力進攻。應始終存在賬戶鎖定功能，由於它可使應用程序免於暴力破解並噴出用戶憑據。蠻力也能夠經過容許用戶不使用字典單詞，使用必定長度的密碼更好地要求他們使用密碼來抵消。在存儲以前，應始終對用戶的密碼進行哈希處理，使用帶哈希值的鹽也很是重要。

安全防護

咱們能夠採起如下預防措施，並在嘗試與身份驗證和會話管理問題做鬥爭時保留這些心理記錄。

認證失敗

• 提示錯誤/成功消息
• 永遠不要硬編碼憑證
• 密碼策略執行（成熟，強度，鹽的哈希）

會話管理

• 令牌的不可預測性（即安全隨機性）
• 到期策略，登陸/註銷重置
• 使用強加密
• 複雜的Cookie安全性