目錄
今日目標
這是什麼漏洞？
我的目標是要登錄到 Bender 這個用戶的賬戶。
Bender 是一個普通用戶，要完成這個挑戰，必須要猜測該用戶的 email 賬號，並且這是一個注入的漏洞，而不要去嘗試獲取該用戶的密碼 hash，或者嘗試爆破該用戶的密碼，這是一個注入的練習。
跟第一篇文章一樣，這還是一個繞過登陸驗證的注入漏洞。
這個漏洞是怎麼造成的？
開發者在開發登陸流程的時候
- 沒有使用 ORM 進行數據庫請求，而是直接拼接了請求語句；
- 沒有對用戶輸入做過濾，校驗，和編碼；
關於第一點，可以參考這一系列文章的第一篇。
關於第二點，在後面的如何應對一節中做說明。
怎麼判斷漏洞是否存在？
記得在第一篇文章中，說明了判斷此類漏洞的方法。通過在輸入框中輸入單引號，或者雙引號，然後查看服務端返回結果，如果返回結果有異樣，那麼可以判斷注入漏洞存在。
如何利用這個漏洞？
在第一篇文章中，我們可以繞過登陸驗證，注入之後構造的數據庫請求如：
SELECT user_name from Users where email = '' or 1 = 1 -- AND password = ...
由此，我們可以登陸任何用戶的賬戶。
上一篇文章在成功繞過登陸驗證之後，admin 賬戶的郵箱是這樣的
那麼 bender 用戶的郵箱，就可以猜測應該是
[email protected]
構造如下用戶名，即可完成登陸
[email protected]' --
如何應對？
過濾
對於用戶輸入的過濾，也就是把一些敏感字符直接刪除掉。例如，如果用戶輸入中有 < > 這樣的尖括號，直接刪除掉。但是這樣的方式很粗暴，如果用戶並沒有注入的意圖，只是有使用尖括號的需求，那麼用戶體驗就會很差。
校驗
暴力過濾會影響用戶體驗，那麼可以稍做改進。在服務端收到用戶輸入之後，對用戶輸入進行一定的校驗。我舉得正則是比較好的方式，任何符合 <script 的非大小寫敏感的模式，如果出現在不該出現的如用戶登陸的邏輯當中，做統一的錯誤處理。
編碼
更進一步，對於用戶輸入，在開始傳輸的時候，做一次 URL Encode。那麼例如 <，在傳輸的時候，會被轉換成 <，也就避免了注入代碼執行。
- https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top_10-2017_A1-Injection
- https://www.w3schools.com/tags/ref_urlencode.ASP