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

宣告：本文由bypass整理並翻譯，僅用於安全研究和學習之用。

我一直致力於安全編碼實踐，並試圖盡可能多地學習基本要點。在過去的幾年裡，我已經意識到乙個小小的漏洞在普通人的生活中可能造成的傷害。像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也必須是唯一的。以下是如何執行以下操作的想法。

//

問題是正在使用相同的會話物件，因此獲取當前會話
//使該會話無效
before_login.invalidate（）;
//生成乙個新會話，新的jsessionid 

3.通過web服務進行使用者列舉

列舉問題非常嚴重，因為它可以讓攻擊者弄清楚應用程式中存在的使用者的使用者名稱/電子郵件id，以下細節可以在以後用於暴力攻擊。

我們使用widsler擴充套件並利用它的「getuser」功能對burp-suite進行此攻擊。因此，當我們輸入有效的使用者名稱時，我們嘗試從系統收集響應，然後我們輸入乙個不是使用者名稱的隨機字串，然後檢查響應。我們可以在下面的影象中看到相應的響應。

使用者不存在

上面的影象是我們在具有特定使用者名稱的使用者不存在時收到的請求和響應。我們在**器中傳送了請求查詢以檢查響應。

使用者確實存在

上面的影象是我們收到的使用者確實存在的條件的請求和響應。我們在**器中傳送了請求查詢以檢查響應，並在此次獲得了不同的響應。這給了我們乙個想法，我們可以根據我們收到的響應來列舉使用者。

因此，我們在入侵者選項卡中傳遞請求，然後執行蠻力來檢查使用該應用程式的各個使用者。

列舉的使用者名稱

這裡的主要問題是開發人員實際上在響應查詢中放了太多細節。正如在這次攻擊中我們可以清楚地看到，由於響應中的資訊太多，我們可以弄清楚哪些使用者具有相應的使用者名稱，哪些使用者沒有。我們需要製作一些標準化的訊息，以便攻擊者不能僅僅使用一些簡單的列舉技術。

4.暴力攻擊

這是攻擊者通過前一種方法列舉使用者及其使用者名稱後執行的下一階段攻擊。

旁邊的影象顯示我們已經列舉使用者的登入頁面，需要執行暴力攻擊才能知道這些使用者的登入憑據。

因此，當我們嘗試登入時，我們攔截burp-suite中的流量並捕獲請求資料報並將其傳送給入侵者。

請求查詢

現在，我們已經列舉了使用者名稱，我們執行命中和嘗試，暴力攻擊。我們從網際網路上獲取一組常用密碼並執行我們的攻擊以找出相應的密碼。

通過burp-suite進行蠻力攻擊

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

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

認證失敗

會話管理

簡訊身份驗證的安全風險

賬戶接管 這個是簡訊身份驗證最嚴重的安全風險，攻擊者可以竊取任意使用者的賬戶，甚至是事先不知道使用者的手機號碼 使用者模擬 與上面的類似，但是這個的風險取決於具體的服務。通常，如果可以進行模擬，由於確認機制相同，因此也有可能竊取已註冊的帳戶。簡訊轟炸 簡訊轟炸可以針對客戶或任何其他人。易受攻擊的we...

登入工程三 現代Web應用中的身份驗證實踐

首先，我們要為 登入 做乙個簡要的定義，令後續的講述更準確。之前的兩篇文章有意無意地混淆了 登入 與 身份驗證 的說法，因為在本篇之前，不少 傳統web應用 都將對身份的識別看作整個登入的過程，很少出現像企業應用環境中那樣複雜的情景和需求。但從之前的文章中我們看到，現代web應用對身份驗證相關的需求...

安全性 身份驗證和授權 一 之Principal

為了確保應用程式的安全，安全性有幾個重要方面需要考慮。一是應用程式的使用者，訪問應用程式的是乙個真正的使用者，還是偽裝成使用者的某個人？如何確定這個使用者是可以信任的？確保應用程式安全的使用者方面是乙個2個階段過程 另一方面是應用程式本身。如果應用程式駐留在web提供程式上，如何禁止應用程式執行對伺...