參考文章：https://www.freebuf.com/articles/web/149761.html
參考文章：https://joychou.org/web/nginx-http-forward-proxy-ssrf.html
參考文章：https://joychou.org/operations/nginx-config-security.html
Ningx.conf配置一共分為4部分：1、頂級配置 2、Events 模塊 3、http部分 4、Server部分
默認的nginx.conf配置如下：
user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log;
pid /run/nginx.pid;
# Load dynamic modules. See /usr/share/doc/nginx/README.dynamic.
include /usr/share/nginx/modules/*.conf;
events {
worker_connections 1024;
}
http {
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;#日志存儲位置
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
types_hash_max_size 2048;
include /etc/nginx/mime.types;
default_type application/octet-stream;
# Load modular configuration files from the /etc/nginx/conf.d directory.
# See http://nginx.org/en/docs/ngx_core_module.html#include
# for more information.
include /etc/nginx/conf.d/*.conf;#配置文件目錄
server {
listen 80 default_server;#監聽端口
listen [::]:80 default_server;
server_name _;#域名
root /usr/share/nginx/html;#web目錄存儲的位置
# Load configuration files for the default server block.
include /etc/nginx/default.d/*.conf;
location / {
}
error_page 404 /404.html;
location = /40x.html {
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
}
}
不安全配置導致的任意文件讀取/目錄遍歷
觸發點：這個常見於Nginx做反向代理的情況，動態的部分被proxy_pass傳遞給后端端口，而靜態文件需要Nginx來處理。假設靜態文件存儲在/home/目錄下，而該目錄在url中名字為files，那么就需要用alias設置目錄的別名
location /files {
alias /home/;
}
為/files設置一個別名為/home/，
訪問：http://116.85.41.113/files../etc/passwd，發現成功讀取！
這里相當於/home/../etc/passwd，如果/files為/files/那么肯定就是正常解析，但是這里沒有閉合導致了任意文件讀取
alias的目錄遍歷：只能跳到上一層目錄，讀取上一層目錄及其任意子目錄的文件，不能任意目錄遍歷讀取任意文件，有局限性！
修復方法：結尾都帶上/字符！
如果當前目錄是可遍歷的，也就是再加上
autoindex on;
$uri導致的CRLF注入
觸發點：在實際業務場景中經常需要在nginx中配置路徑跳轉。比如用戶訪問http://x.com需要自動跳轉到https://x.com或者是訪問http://x.com自動跳轉到http://www.x.com
實現條件：
1、需要進行302跳轉
2、還需要知道用戶請求的路徑內容
這里有有三個可以表示URI的變量：
$uri
$document_uri
$request_uri
$uri和$document_uri表示的是解碼以后的請求路徑，並且不帶參數
而$request_uri表示的是完整的URI，帶參數，並且沒有解碼過
如果在nginx.conf中配置了下列的代碼：
location /test {
return 302 http://$host:443$uri;
}
這里$host為請求域，$uri為請求路徑，這里知道$uri會進行解碼，那么當我們進行注入%0d%0a的時候，就會觸發CRLF漏洞
注意：該漏洞除了發生在return的后面，也可能發生在rewrite、add_header、proxy_set_header、proxy_pass的后門
修復方式：將$uri/$document_uri都改為$request_uri
proxy_pass反向代理導致的SSRF
觸發點：SSRF(服務端請求偽造)漏洞常出現在反向代理的配置中，反向代理的語法如下：proxy_pass http://ip:port/uri/;
不安全配置如下：
location ~ /([a-zA-Z0-9.:%]+) {
proxy_pass http://$1;
}
如果攻擊者可以操控IP, 將其修改成內網IP地址即可造成SSRF漏洞。
請求成功為：
請求失敗為：
最大的特點：無回顯！
proxy_pass正向代理導致的SSRF
不安全配置如下：
proxy_pass http://$host$request_uri;
最大的特點：有回顯！
default_server配置不當（2021.5.09更新）
nginx 的 default_server 指令可以定義默認的 server 去處理一些沒有匹配到 server_name 的請求，如果沒有顯式定義，則會選取第一個定義的 server 作為 default_server
在了解到如上規則后，我們可以捕獲未做綁定的域名訪問或直接IP訪問，做重定向到 403 頁面等處理
環境配置如下：
此時的default_server為第一個server塊，那么造成的結果就是如果用IP直接訪問則回顯403頁面，如下所示
這時候配置了第二個server塊：
如果Host字段為www.ttttt.com的話，那么nginx則會以第二個server來處理這個請求，那么請求的目錄則為/usr/share/nginx/html中，如下所示
可能到這里還是不會太懂這個東西在挖掘漏洞的時候有什么關系？繼續往下走
來，繼續模擬，如下所示：
此時去重新配置我們的nginx服務器的配置文件
先回顧下請求一個域名的流程是怎么樣的？首先看本機緩存，再看HOSTS記錄，如果都沒有則請求本地DNS服務器，本地DNS服務器中沒有，則本地DNS服務器迭代去請求根DNS服務器，上面的圖中在本機的HOSTS寫上兩個模擬的地址，因為條件有限啊，模擬不了DNS服務器，所以這里就模擬HOSTS作為DNS服務器
挖掘zpchcbd.com的域名的漏洞，發現收集的域名其中DNS解析的一個IP為192.168.4.136（假設外網IP），直接訪問192.168.4.136卻是回顯為403拒絕訪問的界面
這時候就可以通過該ip來匹配不同的host字段來進行訪問，比如訪問hosts字段頭為admin.zpchcbd.com
那要如何進行利用？
r3start提供了一個自定義hosts頭來進行訪問的腳本：https://github.com/fofapro/Hosts_scan
總結下：
1、內網的管理系統和業務系統都用同一台nginx服務器進行反向代理
2、掃外網的時候掃到解析ip為內網的域名（如何大量的搜集內部的域名才是最重要的）
3、通過hosts碰撞，來遍歷域名綁定外網的這個Nginx的ip，如果正好如何這個nginx的配置項的server_name則hosts碰撞成功！