這是什麼？
OWASP Juice Shop 是一個練習網頁應用測試的工具。
本篇是 OWASP Top 10 系列的起始篇。
對於不清楚 OWASP 是什麼的同學，看這裏。
簡單說 OWASP 是一套網頁應用的測試列表，你可以按照它的指示一項一項地對網頁應用進行測試，
它會告訴你該漏洞的原理，測試方式以及應對策略，十分詳細，是行業標杆。
部署 Juice Shop
可以在 Juice Shop 的 Github 頁面看到，Juice Shop 可以被一鍵部署到 Heroku（是免費的），你只需要註冊一個賬號即可。同時也可以下載到本地，部署到虛擬機。
Heroku很方便，註冊個賬號，點一下 Github 上的部署，就搞定了。
部署完成之後，在個人帳號的 Settings 一欄，往下拉可以看到自己的應用的 Heroku 域名。
直接訪問即可。
其他部署方式見文檔。
幫助文檔
幫助文檔在這裏，這裏有所有你需要的資料。
另外，在瀏覽器，訪問 https://example.herokuapp.com/#/score-board，將看到一個計分板，這裏按照漏洞的類型做了分類，並且每個分類中用難度係數（1-6星）對每一個挑戰做了評估，可以選擇適合自己的開始。
第一個挑戰
排在 OWASP Top 10 第一位的是 Injection。
在 score-board 把 1-2 星都選上，然後選擇 Injection，之後我就按順序往下走了。
點擊右上角 Account，找到 Login 界面。隨意輸入用戶名密碼，報錯了。
這個練習是一個經典 SQL 注入。首先在 Burp Suite 中攔截一個請求，然後右鍵 Send to Repeater （Ctrl + R 也行）。
這裏有什麼漏洞？
這裏的漏洞是 Bypass Login Authentication，繞過登陸驗證。
攻擊者只需要在用戶名處，構造一個恆爲 true 的表達式，然後註釋掉接着的部分，即使不輸入密碼，也可以成功繞過登錄驗證。
在 Example Attack Scenarios 裏面，有對於原理的詳細講解。
漏洞是怎麼造成的？
在 OWASP 的解釋中可以看到，正式程序員在開發註冊流程的時候，手動拼接 SQL 請求，沒有對用戶的輸入做出篩選，過濾和驗證，導致的漏洞。
怎麼這樣的注入漏洞是否存在？
舉個例子，某程序員在代碼中拼接瞭如下的 SQL 語句。
query = "SELECT * FROM user
where username =' + $username +
'and password=' +
hash_func($password) +
"';""
這裏，在拼接的時候，程序員選擇了使用單引號，'，當然也有可能選擇使用雙引號，"，只需要轉義一下。
所以，測試這樣的注入是否存在，只需要在用戶名處輸入一個單引號，或者雙引號，如果網頁報出了服務器端或者數據庫端的錯誤，那麼注入漏洞就存在。
輸入 test:test 或者 ":test 的時候，點擊提交報的是 Invalid email or password.。
而如果我輸入一個單引號，頁面報錯是一個奇怪的 [object Object]。
初步可以斷定，登錄驗證可繞過。
在 Repeater 裏面查看一下服務端的返回，是這樣的。
後端的錯誤展示了很多信息，如使用的是 SQLite 數據庫，具體的 SQL 語句以及密碼。
利用漏洞
原理知道了，那麼只需要構造一個 SQL 表達式，結果恆爲 true 即可繞過驗證。
在用戶名處輸入
' or 1 = 1 --
即可繞過驗證。
解釋：
- 第一個單引號與
email = ''or是邏輯表達式，說email = ''或者1 = 11 = 1是恆爲true的，所以整個表達式恆爲true- 最後的
--，將剩下的 SQL 部分註釋掉，也就是忽略密碼部分驗證。注意，--後面一定要加上一個空格，不然後面的註釋不生效。
最後的 SQL 表達式會是"SELECT * FROM Users WHERE email = '' or 1 =1 -- AND password = ...
執行一下，成功繞過登錄驗證。
預防措施
見 OWASP How to Prevent 部分，比我講的好多了。
參考鏈接：
- https://github.com/bkimminich/juice-shop
- https://owasp.org/
- https://pwning.owasp-juice.shop/
- https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top_10-2017_A1-Injection