不可否認，密碼學具有各種各樣的優點，比如信息的機密性，但是對于密碼過分的依賴，利用其保護應用程序儼然是一個壞主意。在這篇文章中我們app安全的首席培訓師森爾·亞達夫，將針對一個案例進行研究，其中有一個SQL注入漏洞是通過加密的payload來進行識別和利用的。

　　注意：我們在本文中討論的問題并不是加密（即如何破解密碼），而是應用程序自身的缺陷，并且能夠由開發人員進行監督，使我們生成加密的有效負載（即任何給定明文的密文），然后將其用于識別和利用SQL注入。

　　實際的案例在現實中其實是比較難發現的，因此我們在我們的hack實驗室中重新創建了一個類似的漏洞，用于此演示，下面將會進行詳細的介紹：

　　在最近的一個電子商務應用程序中，我們觀察到大多數請求參數值已被加密。當請求參數被加密時，很難fuzz應用程序，除非可以中斷加密（這需要知道密鑰和加密算法），而這段時間內從黑盒子中獲得這些是不太可能的。具體情況可以查看我們上一篇關于黑客隱私的文章，從而能夠更了解這個問題。

　　這是訂單詳細信息頁面的示例，其中以加密格式發送id（orderid）參數。

　　注意：參數值（BDKfx3xNKsc = ）是加密的，而不是簡單的base64編碼。ID參數的加密值以base64編碼格式表示。

　　我們還注意到，如果我們退出應用程序，然后以相同的用戶登錄并導航到完全相同的頁面，則加密參數（nPBri1km2ic = ）的值現在不同，如下所示：

　　這提供了一個很好的指示，即隨機密鑰在每個成功的登錄或會話ID（cookie的一部分）中用于加密，以某種方式用作密鑰的一部分。這些看起來會很安全嗎？我們原本想試著找一些加密的缺陷，但似乎運氣并不好。

　　首先，我們嘗試在幾個位置注入單引號（'）來測試輸入驗證。但請求參數被拒絕了，因為這些參數需要加密格式（即有效的密文），因此我們似乎走到了墻角。

　　然后我們偶然發現了一個小車分享功能，此功能允許用戶與其他人共享購物車項目。當用戶保存購物車進行共享時，會產生一個帶有隨機查詢令牌的鏈接。通過訪問此鏈接（URL），用戶可以訪問彼此的購物車，而在購物車可以保存之前，用戶會被要求在購物車中輸入一個名字。

　　由于這是接受明文輸入的罕見輸入字段之一，所以我們對其進行了SQLi，XSS以及其他所有的Fuzz！但卻再次陷入了困境。

　　這時我們意識到，我們實際上偶然間發現了一些非常有趣的事情。在更深入的了解后，事實證明，生成的URL中的令牌共享購物車實際上是我們為購物車選擇的購物車名稱的密碼。

　　注意：Share cart功能不容易受到任何攻擊的影響，但可以用于為給定輸入（明文）生成加密的有效內容（密文）?，F在，可以生成一個加密的攻擊有效載荷來檢查應用程序對SQL注入，訪問權限繞過等漏洞的行為。為了測試SQL注入，我們生成了單引號（'）的加密值，如下所示：

　　加密的有效載荷用于模糊僅接受密文值作為輸入的各種應用參數。我們花了一些時間來打到正確的位置，但是最終orderitem頁面的ID參數返回一個SQL錯誤消息，確認了該漏洞，如下所示：

　　該錯誤消息證明了應用程序生成的動態查詢很容易就會受到SQL注入攻擊。而現在從數據庫中提取信息的時候到了，基于UNION的SQL查詢可用于從數據庫中提取數據，聯合運算符可用于組合兩個或多個select語句的結果。

　　第一個任務是確定作為SQL查詢的一部分返回的列數。使用試錯，我們在查詢中返回了一些列（30）?，F在是時候從數據庫中提取信息了。我們創建了一個加密的負載來提取數據庫版本信息，如下所示：

　　然后，由上述有效載荷的輸出生成的密文作為頁面上顯示DB版本的易受攻擊的ID參數的輸入。

　　最后我們使用這個漏洞構建了數據庫系統，并最終得到一個shell！

　　結論

　　加密參數來實現應用程序中的安全性是一個比較隱蔽的安全性例子。加密不會使軟件更安全，但使用強加密算法加密的數據保密，直到時間密鑰受到保護或惡意角色識別生成加密有效載荷的方式，已經被認為是保護數據免遭篡改或欺騙的事實機制。然而我們在這篇文章中看到，由于執行不力和缺乏明確管理方法可能會導致出現相當破壞性的安全漏洞。

<menuitem id="zjj55"></menuitem>

<menuitem id="zjj55"></menuitem>

<big id="zjj55"></big>

責任編輯：韓希宇