2

URL を指定すると、その出力を定期的に取得するツールをコーディングしています。問題は、出力が単純で軽量な HTML ページ (ほとんどの場合に予想される) ではなく、重いデータ ストリーム (つまり、/dev/urandom から直接、DoS 攻撃の可能性がある) になる可能性があることです。

java.net.URL+を使用してjava.net.URLConnection、接続と読み取りのタイムアウトを 30 秒に設定しています。現在、入力はjava.io.BufferedReader、を使用して、によって読み取られていreadLine()ます。

可能な解決策：

  1. java.io.BufferedReader.read()バイトごとに使用し、それらをカウントし、制限に達したら接続を閉じます。問題は、攻撃者が 29 秒ごとに 1 バイトを送信する可能性があるため、読み取り/接続タイムアウトがほとんど発生しないことです (204800B * 29 秒 = 68 日)。
  2. スレッドの実行を 1 ～ 5 分に制限し、java.io.BufferedReader.readLine(). ここに問題はありますか？

車輪を再発明しようとしているような気がしますが、解決策は非常に簡単ですが、頭に浮かびません。

前もって感謝します。

4

2 に答える 2

2

強制したいものを強制するFilterInputStreamを自分で作成し、それをスタックの一番下、接続出力ストリームの周りに配置することで、bhhisをカプセル化できます。

ただし、これと提案する解決策は、出力がチャンク転送モードで到着する場合にのみ機能します。それ以外の場合、HttpURLConnectionは、応答を読み取る前に応答全体をバッファリングできます。これに対する通常の解決策は、ファイアウォールのフィルターです。

于 2010-09-02T10:38:34.933 に答える
0

ここには、サービス拒否の方法がいくつかあるようです。

記憶をむさぼり食う巨大な大行列。おそらく最も簡単なのはMeteredInputStream、文字のデコードを行う前に a を使用することです。charによる読み取りcharは、どのような状況でも非常に遅くなります。char[]一度に長く読むこともできますが、コードが複雑になりすぎる可能性があります。

一度に多くの接続を維持している敵 (またはバグ) に対処する。メッセージ全体を非ブロッキング I/O で読み取り、その後通常どおりに処理する必要があります。

于 2010-09-02T09:59:32.973 に答える