LOW
打開，是個查詢ID
利用$_REQUEST獲取id參數，$_REQUEST 包含了 $_GET，$_POST 和 $_COOKIE 的數組，可以被遠程用戶篡改而並不可信。
直接將$_REQUEST的數據插入sql查詢語句未做任何過濾,造成了SQL注入漏洞
-1'union select user,password from users #
Medium
打開頁面，是按鈕選擇查詢，無法輸入字符
查看源碼，發現是用$_POST方法提交，相對比$_GET和$_REQUEST安全
從POST表單獲取id後，使用mysqli_real_escape_string()過濾，該函數會轉義 SQL 語句中使用的字符串中的特殊字符，來預防數據庫攻擊。下列字符受影響：\x00 \n \r \ ' " \x1a
因爲WHERE user_id = $id 是直接數字型傳參，所以mysqli_real_escape_string()並未生效
是表單選擇無法輸入，但因爲是POST方法提交表單，可以使用抓包工具，修改參數
High
先查看頁面效果，發現有個鏈接跳轉，打開鏈接來到session-input.php，先查看一下
沒什麼值得注意的，這個頁面僅僅是將我們的輸入放到了 Session 會話中，而且對我們的輸入沒有進行任何過濾或驗證
再查看high的源碼
從 Session 中取出 id 而沒有進行任何的過濾或驗證，而且是字符型注入，emmmm，其實就是跳到另一個low級別頁面，不是吧，阿sir
Imposeable
查看頁面，發現和low是一樣的
查看源碼，好了，沒事了，打擾了
checkToken()檢查token，防止CSRF
在處理用戶輸入的時候，首先是判斷用戶輸入的是不是數字類型，is_nummic()函數判斷id是否是數字，是返回true，否則返回false。通過這個判斷可以將特殊字符或or、xor等都過濾掉，限制只能是純數字。
使用PDO prepare 預編譯的方式，沒有使用常規的mysql過濾函數，因爲前者可以指定參數類型，限制了傳入更安全。後者可以使用編碼繞過