による:
https://docs.python.org/3/library/http.server.html
警告http.serverは実稼働には推奨されません。基本的なセキュリティチェックのみを実装します。
サーバーがどのセキュリティの脆弱性にさらされているかは明記されていません。私はシステム管理者であり、これを本番環境にプッシュしたい開発チーム(私の理解では、http.server.SimpleHTTPRequestHandlerを拡張するときにそれを使用していることを理解しています)とCIOに青信号を与えています。ドキュメンテーションは詳細について詳しく述べていないため、どのようなリスクが伴うのか私にはわかりません。この製品のセキュリティの脆弱性について誰かに教えてもらえますか?
問題は、既知のセキュリティ脆弱性があることではありません。
問題は、あまり一般的ではないが重大な脆弱性に対処するための取り組みが実際にはないことです。
たとえば、多くのWebサーバーはエラーメッセージを表示します。ごく最近まで、Apache Httpdはエラーページにリクエストデータの一部を含めていました。これにより mod_proxyのデフォルト構成でのクロスサイトスクリプティング(CVE-2019-10092) が可能になり、アプリケーションに方法がありませんでした開発者は、サイトユーザーに対するこの脅威を軽減します。
Apache Httpd、Nginx、IIS、Lighttpdなどの主要なWebサーバーには、何百ものactive寄稿者(またはIISの場合、大規模な企業構造)があります。その背後にある)、セキュリティのベストプラクティスを理解している数十人のコア開発者、および潜在的な脆弱性のコードのレビューに特化したチーム。これらのプロジェクトのCVEを参照することでわかるように、バージョンがリリースされた後も、人々が気づくことがあります。
プログラミング言語用のHTTPサーバーを作成する開発者は、主要な製品である言語をサポートするツールを開発する小さなサブプロジェクトです。そのツールにコードを提供してくれた12人の人と、そのプロジェクトに1人か2人のコア開発者がいるかもしれません。
脆弱性の検索に使用できるリソースがないため、既知の脆弱性はありませんが(少なくとも、非常に悪い形式ですここにあります -)対処されていない可能性が高い既知の脆弱性を指摘するため)、HTTPサーバーの複雑な性質に起因する脆弱性が最も確実に存在します。
これらの脆弱性の一部mightは非常に重要であり、特権アカウントで任意のコードを実行するなど、攻撃者がサーバーを完全に制御できるようにします。このような脆弱性は存在しない可能性がありますが、徹底的なコードレビューなしで、Pythonのドキュメントページの上部に大きな赤いボックスの警告が表示されない限り、このような脆弱性が存在する可能性があります。
特定のケースでは、CIOがサインオフしました。
リスク評価が確実に行われるようにするのはCIOの責任です。システム管理者としての責任は、会社の役員の指示を実行することと、役員が情報に基づいた意思決定を行うために必要な情報を確保することの責任です。
責任の境界があるため、私が行う反論は、リスク評価を見ることです。リスク評価に非常に高い確率が含まれていない場合(自動ツールが脆弱なサーバーを数時間ですばやく見つけるため)、サーバーがマルウェアに感染する可能性がありますボットファームのコマンドアンドコントロールリピーターノードとして使用され、現実的なリスク評価を支援します。