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

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

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

需要安全代碼？

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

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

我們來挖掘吧！

那麽，這篇特別的文章“如何編寫安全代碼？”專註於Broken auth問題和Session管理問題。

與身份驗證和會話管理相關的應用程序功能通常無法正確實現，允許攻擊者破壞密碼，密鑰，會話令牌或利用其他實現缺陷來承擔其他用戶的身份。

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

1.硬編碼登錄憑據

硬編碼登錄憑據是程序員可以犯的最大錯誤之一，因為它與在銀盤上為黑客提供憑證一樣好。敏感數據永遠不應該是硬編碼的。

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

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

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

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

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

2. Cookie操作

隨著越來越多的身份驗證過程通過檢查用戶提供的cookie細節來執行，Cookie操作正在成為當今最危險的攻擊之一。

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

讓我演示攻擊者如何利用分配給用戶的ok弱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進行蠻力攻擊

在任何情況下都絕不允許暴力進攻。應始終存在帳戶鎖定功能，因為它可以使應用程序免於暴力破解並噴出用戶憑據。蠻力也可以通過允許用戶不使用字典單詞，使用一定長度的密碼更好地要求他們使用密碼來抵消。在存儲之前，應始終對用戶的密碼進行哈希處理，使用帶哈希值的鹽也非常重要。

道德

我們可以采取以下預防措施，並在嘗試與Broken Auth和會話管理問題作鬥爭時保留這些心理記錄。

認證失敗

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

會話管理

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

安全編碼實踐之三：