2

Web アプリケーション .NET では、その場で html を pdf に変換する必要がありました。いくつかのオープン ソース プロジェクトをいじりました。最後に wkhtmltopdf を見つけました。サーバー側では、アプリは wkhtmlpdf のサーバー側プロセスを呼び出し、引数を渡し、ユーザーに pdf ファイルを提示します。

セキュリティの観点から、このアプローチはどれほど悪いのでしょうか? ボットに対してより脆弱ですか?

4

3 に答える 3

8

生成されたプログラムに、信頼できない入力が与えられたときにバッファ オーバーフロー エラーが発生し、任意のコードが実行されるとします。良い面としては、任意のコードがサーバー プロセスではなく、別のプロセスで実行されていることです。悪い面: 任意のコードは、プロセスが持っているすべての権利を持っています。

サブシステムを独自のプロセスに分離することは良い方法ですが、それだけではありません。多層防御を使用します。

  • 正しく動作するために必要な最小限の特権で新しいプロセスを開始します。そうすれば、攻撃が成功した場合、ダメージは制限されます。

  • 特に信頼できないソースからのものである場合は、プロセスへの入力をサニタイズします。ファイルが適切なサイズであり、適切なデータが含まれていることを確認してください。

攻撃を成功させるには、1 つだけでなく、12 の不可能なフープをジャンプする必要があります。

サービス拒否に関する Joe の指摘も、よく考えてみてください。

于 2013-07-23T13:53:19.463 に答える
5

これは、サーバーを圧倒して DOS を実行する人々に対して脆弱です。要求をメッセージ キューに配置し、サービスでアイテムをキューから処理することができます。これは、最大でN 個のプロセスが実行されていることを保証できることを意味します。そして最悪の場合、キャンセルできる長いキューがあります。

メッセージ キューを使用する場合は、キュー コンシューマーを別のサーバー (複数可) に移動できます。これは、サービスの需要が多い場合にサーバーの負荷を分散するのに役立ちます。別のサービスで実行するということは、データへのアクセスが制限されることも意味します。これはセキュリティに適しています。つまり、実行可能ファイルは必要のないファイルやメモリにアクセスできません。

欠点は、これが非同期であり、ファイルをダウンロードする準備ができたことを通知する必要があることです。また、ダウンロードを待っている間、どこかに保存する必要があります。

これの利点は、待機中にユーザーが HTTP サービス接続を結び付けないことです。また、プロセスの実行に時間がかかる場合でも、ユーザーの接続はタイムアウトしません。

于 2013-07-23T13:48:47.420 に答える
0

サーバー上でプロセスを実行することは、そのままではセキュリティ上の欠陥にはなりません。あなたのような場合にプロセスを実行するのは、誰かが要求した他のアクションまたは操作の結果です。そのため、実行可能ファイルを実行するアクションにつながるメソッド/アーキテクチャにセキュリティ上の欠陥が存在する可能性があります。その層で十分に安全であると感じている場合は、別のプロセスを呼び出すことについてあまり心配しません。特に、提供するサービスにより多くの価値がもたらされるためです。

于 2013-07-23T13:50:47.180 に答える