3

このトピックに関する私の最初の理解は、これらの攻撃を回避するために、リクエストで利用可能な一部のジャンク文字を防ぐ必要があるということです.

これを使用する前に、すべてのリクエスト パラメータのパターン マッチングによってこれを解決することにしました。インターネット上で入手可能な投稿のほとんどは、Null Byte に関するものであり、与えられた例は、フ​​ァイル IO がこの攻撃の主な犠牲者であることを示しています。以下は私の質問です

  1. null バイトが影響を与える可能性があるのはファイル IO だけですか、それとも他の操作もこの攻撃の犠牲になりますか?
  2. null bye 攻撃に対して安全になるようにリクエスト パラメータをフィルタリングする場合、注意が必要な文字/文字列/パターンは何ですか? 私はリストを持っていますが、完全なものではないと確信しています。%00、\0、16 進数の 0x00

私が参照している記事は次のとおりです。

http://projects.webappsec.org/w/page/13246949/Null%20Byte%20Injection

http://www.perlmonks.org/index.pl?node_id=38548

http://hakipedia.com/index.php/Poison_Null_Byte

前もって感謝します

より明確にするために：

最初の投稿では、私が話している Java の脆弱性を指摘しています。文字列serverlogs.txt%00.dbは Java で許可されていますが、C/C++ に関しては、これはserverlogs.txtです。C %00 は null バイトに置き換えられ、serverlogs.txt の後で文字列が終了します。したがって、そのような文字は避ける必要があります。これは、どのような文字を許可してはならないかを理解しようとしているものです。

String fn = request.getParameter("fn");
if (fn.endsWith(".db"))
{
File f = new File(fn);
//read the contents of “f” file
…
}
4

4 に答える 4

4

試してみましたか？この簡単な単体テストを書きました：

@Test
public void test() throws Exception {
    FileOutputStream out = new FileOutputStream("test.txt");
    out.write("hello!".getBytes("utf-8"));
    out.close();
    String badPath = "test.txt\0foo";
    File file = new File(badPath);
    FileInputStream in = new FileInputStream(file);
    System.out.println(StreamUtils.copyToString(in, Charset.forName("utf-8")));
}

ここで、ヌル文字が文字列を壊した場合、ファイルの内容がコンソールに出力されることを期待します。代わりに、FileNotFoundException が発生します。記録として、これは Ubuntu 13.04 で Java 1.7.0_40 を使用していました。

アップデート

さらに調査すると、次のコードが明らかになりますFile#isInvalid。

final boolean isInvalid() {
    if (status == null) {
        status = (this.path.indexOf('\u0000') < 0) ? PathStatus.CHECKED
                                                   : PathStatus.INVALID;
    }
    return status == PathStatus.INVALID;
}
于 2013-09-25T04:51:32.020 に答える
3

悪い質問ではありません。これがすべてのプラットフォームで有効な脆弱性であるとは思えません (たとえば、Windows はカーネルで null で終わる文字列ではなく、パスカル スタイルの文字列を使用していると思います)。実際、この種の攻撃に対して脆弱でした。

考慮すべき重要なポイントは、文字列がどこから来ているか、文字列としてやり取りする前にそれらのバイトに対して何をしているのかです。リモート マシンから送信されるバイトは、そうでないことが証明されるまで、常に悪意があると想定する必要があります。また、インターネット経由で取得した文字列をローカル マシン上のパスに変換しようとしてはいけません。はい、Apache のような Web サーバーはこれを行いますが、これは最も脆弱なコードでもあります。正しい解決策は、悪いデータ (null バイトなど) をブラックリストに載せようとせず、良いデータだけをホワイトリストに載せることです。

于 2013-09-25T04:46:11.667 に答える
2

別の角度から Null バイトの問題に対処することもできます。

1013 年 5 月に Oracle は問題を修正しました: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8014846

したがって、Java 8 または Java 7u40 にアップグレードすれば、保護されます。 (はい、私はそれをテストしました!)、それは動作します!

私の個人的なブログへのリンクがスパムと見なされない場合は、ここにドロップします: http://crocode.blogspot.ru/2015/03/java-null-byte-injections.html

于 2015-03-21T20:48:17.673 に答える
1

あなたの質問を正しく読んでいれば、文字列の null バイトの終了後に実行可能コードがメモリに挿入されないようにする必要があります。

Java は C ではありません。

Java はその文字列に null bye の終端を使用しないため、これを防ぐ必要はありません。

于 2013-09-25T04:27:11.240 に答える