発見されたのはRCEでした。2番目のテスターは1つの質問をし... ノート

発見されたのはRCEでした。2番目のテスターは1つの質問をし、チケットはクローズされました。

自動化されたセキュリティスキャンが、顕著な応答遅延により重大なRCE脆弱性を検出しました。ペイロードには実行を一時停止するコマンドが含まれており、これが誤ってコマンドインジェクションを示していました。この遅延は繰り返しテストしても一貫性がなく、脆弱性の証拠としての信頼性の低さを浮き彫りにしました。この問題は、Web Application Firewall (WAF) が疑わしい文字を含むリクエストの処理に時間がかかることに起因していました。これは、WAFの検査やアプリケーションの負荷などの他の要因によって引き起こされる遅延が、コマンド実行として誤解されるという既知の障害モードです。多くの自動化ツールや経験豊富なセキュリティ専門家でさえ、時間ベースの応答のみに依存することでこの落とし穴に陥る可能性があります。このテキストは、より良いアプローチを強調しています。遅延を探すだけでなく、サーバーが入力値をユニークで改ざん不可能な値として評価したかどうかを確認する必要があります。これには、ベースラインを確立するために、無害な制御リクエストを送信することが含まれます。次に、サーバーにランダムな数値の合計のような新しいものを計算するように依頼し、その特定の合計が応答に表示されるかどうかを確認します。直接的な出力がない場合は、遅延時間を変更することで、真の脆弱性と外部要因を区別するのに役立ちます。DNSコールバック自体は、リンクプレビューやその他の無害な機能によってトリガーされる可能性があるため、RCEの十分な証拠ではありません。スキャナーが実行されない環境でシェルメタ文字を使用する場合、特に誤検知が多く発生します。著者は、単一で一貫性のない観察に依存するのではなく、繰り返し可能で検証可能な結果を提唱しています。最終的な目標は、遅延応答だけでなく、入力のサーバーサイド実行によってのみ存在する可能性のある値を確認することです。