Nginxの脆弱性が出現

この記事はhttps://vulhub.org/#/environments/nginx/nginx_parsing_vulnerability/を参照しています

環境は docker で構築

環境をプルする参照に移動してください。

1. Nginxの設定ミスのケース

1. CRLF インジェクションの脆弱性

設定エラーファイル error1.conf

root@ubuntu-virtual-machine:/vulhub/vulhub-master/nginx/insecure-configuration/configuration# ll
total 20
drwxr-xr-x 2 root root 4096 3月  22 21:48 ./
drwxr-xr-x 5 root root 4096 3月  22 21:48 ../
-rw-r--r-- 1 root root  154 3月  22 21:48 error1.conf
-rw-r--r-- 1 root root  158 3月  22 21:48 error2.conf
-rw-r--r-- 1 root root  390 3月  22 21:48 error3.conf

server {
        listen 8080;

        root /usr/share/nginx/html;

        index index.html;

        server_name _;

        location / {
                return 302 http://$host:$server_port$uri;
        }
}

これは、302 がリダイレクトされ、Nginx が $uri をデコードするためです。そのため、%0d%0a を渡して改行文字を挿入できるため、CRLF インジェクションの脆弱性が発生します。

ここで $uri を説明します

uri はホストhttp://example.com/aaaの後ろの値です(これは黄色の部分です)

root@ubuntu-virtual-machine:/vulhub/vulhub-master/nginx/insecure-configuration# curl -I http://127.0.0.1:8080/%0d%0aSet-Cookie:%20a=1
HTTP/1.1 302 Moved Temporarily
Server: nginx/1.13.0
Date: Thu, 23 Mar 2023 03:20:05 GMT
Content-Type: text/html
Content-Length: 161
Connection: keep-alive
Location: http://127.0.0.1:8080/
Set-Cookie: a=1

root@ubuntu-virtual-machine:/vulhub/vulhub-master/nginx/insecure-configuratio

`$uri` はデコードされたリクエスト パスであるため、CRLF インジェクションの脆弱性を引き起こす改行文字が含まれている可能性があります。

この CRLF インジェクションの脆弱性は、セッション固定の脆弱性、Cookie の設定に起因する CSRF の脆弱性、または XSS の脆弱性につながる可能性があります。このうち「\r\n」を2つ注入することでHTTPボディを制御してXSSを行うことができますが、ブラウザはこれを300ジャンプと判断するため、注入したコンテンツを表示しません。

解決：

1. $uri

2. $document_uri

3. $request_uri

3 番目のタイプを使用するとデコードされません

2. ディレクトリ トラバーサルの脆弱性

構成エラー ファイル

server {
        listen 8081;

        root /usr/share/nginx/html;

        index index.html;

        server_name _;

    autoindex on;

        location /files {
        alias /home/;
    }
}
~   

Nginx をリバース プロキシとして使用する場合によくあることですが、動的部分は proxy_pass によってバックエンド ポートに渡されますが、静的ファイルは Nginx によって処理される必要があります。

静的ファイルが /home/ ディレクトリに格納され、URL 内のディレクトリの名前が files であると仮定すると、エイリアスを使用してディレクトリのエイリアスを設定する必要があります。

        location /files {
        alias /home/;
    }

この時点で、` http://example.com/files/readme.txt`にアクセスして`/home/readme.txt` ファイルを取得します。

しかし、`/files` には URL にサフィックス `/` がなく、エイリアスによって設定された `/home/` にはサフィックス `/` があることに気付きました。この `/` は、`/ home/` directory 彼の上位ディレクトリに移動します。

ペイロード: http://your-ip:8081/files../、ルート ディレクトリへのトラバースに成功:

その後、任意のファイル ダウンロードの脆弱性を取得しました。

/user/share/nginx/html/config.php には mysql 構成の mysql ユーザー名とパスワードがあります

この脆弱性を解決するにはどうすればよいですか? ロケーション値とエイリアス値の両方に接尾辞「/」が付いているか、どちらも付いていないことを確認してください。

3. add_header が上書きされる

Nginx 構成ファイルのサブブロック (サーバー、場所、if) の add_header は、親ブロックの add_header によって追加された HTTP ヘッダーを上書きし、いくつかのセキュリティ リスクを引き起こします。

構成ファイルを表示

server {
        listen 8082;

        root /usr/share/nginx/html;

        index index.html;

        server_name _;

    autoindex on;

    add_header Content-Security-Policy "default-src 'self'";
    add_header X-Frame-Options DENY;

        location = /test1 {
                rewrite ^(.*)$ /xss.html break;
        }

        location = /test2 {
                add_header X-Content-Type-Options nosniff;
                rewrite ^(.*)$ /xss.html break;
    }
}

IE8 では、HTTP リクエスト パケット ヘッダーの新しい属性 X-Content-Type-Options が追加されました。X-Content-Type-Options:nosniff オプションを使用して、IE のドキュメント タイプの自動判断を無効にすることができます。

test2 にアクセス

ソースをクリック

彼はあなたの着信 XSS を抽出し、最初のものから傍受することができます

テストを開始