目次
$uri によって引き起こされる CRLF インジェクションの脆弱性
$uriCRLF インジェクションの脆弱性の原因
2 つの一般的なシナリオ
-
ユーザーが にアクセスすると
http://example.com/aabbcc、自動的に にジャンプしますhttps://example.com/aabbcc -
ユーザーが にアクセスすると
http://example.com/aabbcc、自動的に にジャンプしますhttp://www.example.com/aabbcc
2 番目のシナリオは主に、ユーザーが訪問するドメイン名を統一することであり、SEO の最適化により有益です。
ジャンププロセス中、ユーザーが訪問したページが変更されていないことを確認する必要があるため、ユーザーが要求したファイルパスを Nginx から取得する必要があります。
URIを表す3つの変数
-
$uri -
$document_uri -
$request_uri
1 と 2 はパラメータを含まないデコードされたリクエスト パスを表し、3 は完全な URI (デコードなし) を表します。
場合
以下のコードで運用保守を設定した場合
location / {
return 302 https://$host$uri;
}
分析：
$uriこれはデコードされたリクエスト パスである ため、改行が含まれる可能性があり、CRLF インジェクションの脆弱性 (改行インジェクション) が発生します。この CRLF インジェクションの脆弱性は、セッション固定の脆弱性、 Cookie の設定によって引き起こされるCSRF の脆弱性、またはXSS の脆弱性を 引き起こす可能性があります。このうち、を 2 つ注入することで
\r\nHTTP ボディを制御してXSS を実行できますが、ブラウザはこれを 301 ジャンプと認識するため、注入した内容は表示されません。
通常、http://192.168.149.128:8080/にアクセスすると、nginx がリダイレクトした後、http 応答ヘッダーに Location フィールドが表示されます。
http://192.168.149.128:8080/%0d%0atest=123に 普通にアクセスすると、 次の行に test=123 が表示されます。
分析：
%0d%0a ---- \r\n、これは改行文字であるため、URL に改行文字を追加すると、http 応答ヘッダーに悪意のあるデータが書き込まれる可能性があります
同様に、改行を 2 つ追加すると、応答本文にデータを書き込むことができます。http: //192.168.119.131 :8080/%0d%0a%0d%0a <script>alert(1)</script> にアクセスするのと同じように、応答は次のようになります
の解き方
location / {
return 302 https://$host$request_uri;
}ディレクトリトラバーサルの脆弱性
これは、Nginx がリバース プロキシとして使用される場合に一般的であり、動的部分はproxy_pass によってバックエンド ポートに渡されますが、静的ファイルの処理には Nginx が必要です。
場合
静的ファイルが /home/ ディレクトリに保存されており、URL 内のディレクトリの名前が files であると仮定すると、alias を使用してディレクトリ http://192.168.149.128:8081/files のエイリアスを設定する必要があります。 /
エイリアスの設定
location /files/{
alias /home/;
}
www.192.168.149.128/files../
location /files/ {
alias /home/
}この時点で、http://192.168.149.128:8081 /files/help.txt にアクセスして、/home/help.txt ファイルを取得します。
解析する
URL には
/filesサフィックスがありません/が、エイリアス設定には/home/サフィックスが付いているため、/ディレクトリから上位ディレクトリまでトラバースできるようになり、任意のファイルがダウンロードされる脆弱性が発生します。//home/
HTTPヘッダーが上書きされる問題
ご存知のとおり、Nginx 設定ファイルは Server、Location、If などのいくつかの設定ブロックに分割されており、プログラミング言語と同様の包含関係があります。外層で設定した一部のオプションを内層に継承できる場合
ここでの継承には、 add_header などの機能もあり、子ブロックで構成した後、親ブロックの add_header によって追加されたすべてのHTTP ヘッダーが上書きされるため、セキュリティ リスクが生じます。
場合
次のコードに示すように、Server ブロックは CSP ヘッダーを追加します。
server {
...
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;
}
}ただし、X-Content-Type-Options ヘッダーが /test2 の場所に追加されたため、親ブロック内のすべての add_headers が無効になりました。
