前些天進行滲透測試又沾，出現(xiàn)不安全的HTTP方法弊仪，做下小結。
一杖刷，先了解下常用的HTTP請求方法
| 方法 | 描述 |
|---|---|
| GET | GET是最常用的方法,它的作用是獲取服務器中的某個資源 |
| POST | POST方法是用來向服務器傳遞數(shù)據(jù)的. POST請求通常會用來提交HTML的表單. 表單中填好的數(shù)據(jù)會被傳輸給服務器,然后由服務器對這些數(shù)據(jù)進行處理 |
| PUT | 與GET從服務器讀取資源相反,PUT方法會向服務器寫入資源. 有些發(fā)布系統(tǒng)允許用戶創(chuàng)建Web頁面,并用PUT直接向其傳輸?shù)絎eb服務器中 |
| DELETE | DELETE方法所做的事情就是請服務器刪除請求URL所指定的資源 |
| OPTIONS | OPTIONS方法請求Web服務器告知其支持的各種功能. 可以詢問服務器通常支持哪些方法,或者對某些特殊資源支持哪些方法 |
| HEAD | HEAD方法與GET方法的行為很類似,但服務器在響應中只返回首部. 不會返回實體的主體部分. |
還有TRACE,CONNECT等励饵，我不太了解，也沒用過滑燃。
二役听、查看不安全的HTTP方法
Web服務器配置為允許使用危險的HTTP方法，可能允許未授權的用戶對Web服務器進行敏感操作。如OPTIONS典予，會造成服務器信息暴露甜滨，如ALLOW等
使用命令查看是否支持OPTIONS請求方法
curl -i -X OPTIONS https://test.***.com/proxy/register
上面就沒有禁用options方法，請求返回結果為200瘤袖，可以看到一些服務器信息
三衣摩、如何禁止使用不安全的HTTP方法
前兩天隨便百度了些文章，看到有文章說在請求頭設置允許使用的方法即可res.setHeader("Access-Control-Allow-Methods", "GET,POST")捂敌，又說curl命令打印出的信息艾扮，Allow是GET、HEAD就是正確的（無知的我）
結果提交到測試的時候占婉，人家告訴我返回200就是不對的泡嘴，應該是403之類，如下圖
又嘗試在封裝請求方法的地方去判斷請求方法逆济，但并不生效酌予。我沒搞懂真正的HTTP請求，我猜測不管用的原因是奖慌，我判斷的地方已經(jīng)走過了node請求那一步抛虫，header信息已經(jīng)發(fā)送成功了，暈暈乎乎的搞不明白简僧。最后選擇在nginx改配置莱褒，一勞永逸。涎劈。广凸。
if($request_method !== 'GET' && $request_method !== 'POST'){
return 403
}
這樣也不是個好辦法，等有空（也許沒空）把node端如何限制請求方式補上蛛枚。
