Insecure Randomness エラーが発生するのは、セキュリティが重要であるコンテキストで、ランダム性のソースとして、予期可能な値を生成する関数が使用される場合です。

コンピュータは決定論的な機械であるため、真のランダム性を生成することはできません。Pseudo-Random Number Generator (PRNG) はランダム性をアルゴリズムにより近似します。最初の値はシードと呼ばれ、後続の値はそこから計算されます。

PRNG には、統計的なものと暗号的なものがあります。統計的 PRNG は有用な統計上の特性を提供しますが、その出力はきわめて予測可能で、再現しやすい数値ストリームを形成するため、生成される値を予期できないことにセキュリティが依存している場合の使用には不適切です。この問題に対処するため、暗号的 PRNG は、より予期しにくい出力を生成します。値を暗号によって保護するためには、攻撃者が生成されたランダムな値と真にランダムな値を区別することが不可能か、または非常に困難である必要があります。一般的に、PRNG アルゴリズムは、暗号的に安全であると告知されていなければ統計的 PRNG である可能性が高く、セキュリティが重要なコンテキストで使用すべきではありません。PRNG アルゴリズムを使用することで、解読されやすい一時パスワードや暗号化キー、セッションハイジャック、DNS 偽装などの深刻な脆弱性が発生する可能性があります。

例 1: 次のコードは統計的 PRNG を使用して、購入後の一定期間利用できる領収書の URL を作成します。

FORM GenerateReceiptURL CHANGING baseUrl TYPE string.
    DATA: r TYPE REF TO cl_abap_random,
		  var1 TYPE i,
		  var2 TYPE i,
		  var3 TYPE n.


	GET TIME.
	var1 = sy-uzeit.
	r = cl_abap_random=>create( seed = var1 ).
	r->int31( RECEIVING value = var2 ).
	var3 = var2.
    CONCATENATE baseUrl var3 ".html" INTO baseUrl.
ENDFORM.

このコードは CL_ABAP_RANDOM->INT31 関数を使用して、領収書ページの一意の識別子を生成します。CL_ABAP_RANDOM は統計的 PRNG なので、生成される文字列の推測は攻撃者にとってはたやすいことです。領収書システムの基礎設計にも欠陥がありますが、暗号的 PRNG など、予測可能な領収書 ID を生成しない乱数ジェネレータを使えば安全性が高まります。

Insecure Randomness エラーが発生するのは、セキュリティが重要であるコンテキストで、ランダム性のソースとして、予期可能な値を生成する関数が使用される場合です。

コンピュータは決定論的な機械であるため、真のランダム性を生成することはできません。Pseudo-Random Number Generator (PRNG) はランダム性をアルゴリズムにより近似します。最初の値はシードと呼ばれ、後続の値はそこから計算されます。

PRNG には、統計的なものと暗号的なものがあります。統計的 PRNG は有用な統計上の特性を提供しますが、その出力はきわめて予測可能で、再現しやすい数値ストリームを形成するため、生成される値を予期できないことにセキュリティが依存している場合の使用には不適切です。この問題に対処するため、暗号的 PRNG は、より予期しにくい出力を生成します。値を暗号によって保護するためには、攻撃者が生成されたランダムな値と真にランダムな値を区別することが不可能か、または非常に困難である必要があります。一般的に、PRNG アルゴリズムは、暗号的に安全であると告知されていなければ統計的 PRNG である可能性が高く、セキュリティが重要なコンテキストで使用すべきではありません。PRNG アルゴリズムを使用することで、解読されやすい一時パスワードや暗号化キー、セッションハイジャック、DNS 偽装などの深刻な脆弱性が発生する可能性があります。

例 1: 次のコードは統計的 PRNG を使用して、購入後の一定期間利用できる領収書の URL を作成します。

string GenerateReceiptURL(string baseUrl) {
    Random Gen = new Random();
    return (baseUrl + Gen.Next().toString() + ".html");
}

このコードは Random.Next() 関数を使用して、領収書ページの一意の識別子を生成します。Random.Next() は統計的 PRNG なので、生成される文字列の推測は攻撃者にとってはたやすいことです。領収書システムの基礎設計にも欠陥がありますが、暗号的 PRNG など、予測可能な領収書 ID を生成しない乱数ジェネレータを使えば安全性が高まります。

Insecure Randomness エラーが発生するのは、セキュリティが重要であるコンテキストで、ランダム性のソースとして、予期可能な値を生成する関数が使用される場合です。

コンピュータは決定論的な機械であるため、真のランダム性を生成することはできません。Pseudo-Random Number Generator (PRNG) はランダム性をアルゴリズムにより近似します。最初の値はシードと呼ばれ、後続の値はそこから計算されます。

PRNG には、統計的なものと暗号的なものがあります。統計的 PRNG は有用な統計上の特性を提供しますが、その出力はきわめて予測可能で、再現しやすい数値ストリームを形成するため、生成される値を予期できないことにセキュリティが依存している場合の使用には不適切です。この問題に対処するため、暗号的 PRNG は、より予期しにくい出力を生成します。値を暗号によって保護するためには、攻撃者が生成されたランダムな値と真にランダムな値を区別することが不可能か、または非常に困難である必要があります。一般的に、PRNG アルゴリズムは、暗号的に安全であると告知されていなければ統計的 PRNG である可能性が高く、セキュリティが重要なコンテキストで使用すべきではありません。PRNG アルゴリズムを使用することで、解読されやすい一時パスワードや暗号化キー、セッションハイジャック、DNS 偽装などの深刻な脆弱性が発生する可能性があります。

例 1: 次のコードは統計的 PRNG を使用して、購入後の一定期間利用できる領収書の URL を作成します。

char* CreateReceiptURL() {
    int num;
    time_t t1;
    char *URL = (char*) malloc(MAX_URL);
    if (URL) {
        (void) time(&t1);
        srand48((long) t1);     /* use time to set seed */
        sprintf(URL, "%s%d%s", "http://test.com/", lrand48(), ".html");
    }
    return URL;
}

このコードは lrand48() 関数を使用して、領収書ページの一意の識別子を生成します。lrand48() は統計的 PRNG なので、生成される文字列の推測は攻撃者にとってはたやすいことです。領収書システムの基礎設計にも欠陥がありますが、予測可能な領収書 ID を生成しない乱数ジェネレータを使えば安全性が高まります。

Insecure Randomness エラーが発生するのは、セキュリティが重要であるコンテキストで、ランダム性のソースとして、予期可能な値を生成する関数が使用される場合です。


コンピュータは決定論的な機械であるため、真のランダム性を生成することはできません。Pseudo-Random Number Generator (PRNG) はランダム性をアルゴリズムにより近似します。最初の値はシードと呼ばれ、後続の値はそこから計算されます。

PRNG には、統計的なものと暗号的なものがあります。統計的 PRNG は有用な統計上の特性を提供しますが、その出力はきわめて予測可能で、再現しやすい数値ストリームを形成するため、生成される値を予期できないことにセキュリティが依存している場合の使用には不適切です。この問題に対処するため、暗号的 PRNG は、より予期しにくい出力を生成します。値を暗号によって保護するためには、攻撃者が生成されたランダムな値と真にランダムな値を区別することが不可能か、または非常に困難である必要があります。一般的に、PRNG アルゴリズムは、暗号的に安全であると告知されていなければ統計的 PRNG である可能性が高く、セキュリティが重要なコンテキストで使用すべきではありません。PRNG アルゴリズムを使用することで、解読されやすい一時パスワードや暗号化キー、セッションハイジャック、DNS 偽装などの深刻な脆弱性が発生する可能性があります。

例 1: 次のコードは統計的 PRNG を使用して、購入後の一定期間利用できる領収書の URL を作成します。

<cfoutput>
Receipt: #baseUrl##Rand()#.cfm
</cfoutput>

このコードは Rand() 関数を使用して、領収書ページの一意の識別子を生成します。Rand() は統計的 PRNG なので、生成される文字列の推測は攻撃者にとってはたやすいことです。領収書システムの基礎設計にも欠陥がありますが、暗号的 PRNG など、予測可能な領収書 ID を生成しない乱数ジェネレータを使えば安全性が高まります。

Insecure Randomness エラーが発生するのは、セキュリティが重要であるコンテキストで、ランダム性のソースとして、予期可能な値を生成する関数が使用される場合です。

コンピュータは決定論的な機械であるため、真のランダム性を生成することはできません。Pseudo-Random Number Generator (PRNG) はランダム性をアルゴリズムにより近似します。最初の値はシードと呼ばれ、後続の値はそこから計算されます。

PRNG には、統計的なものと暗号的なものがあります。統計的 PRNG は有用な統計上の特性を提供します。しかし、その出力はきわめて予測可能で、再現しやすい数値ストリームを形成するため、生成される値を予期できないことにセキュリティが依存している場合の使用には不適切です。この問題に対処するため、暗号的 PRNG は、より予期しにくい出力を生成します。値を暗号によって保護するためには、攻撃者が生成されたランダムな値と真にランダムな値を区別することが不可能か、または非常に困難である必要があります。一般的に、PRNG アルゴリズムは、暗号的に安全であると告知されていなければ統計的 PRNG である可能性が高く、セキュリティが重要なコンテキストで使用すべきではありません。PRNG アルゴリズムを使用することで、解読されやすい一時パスワードや暗号化キー、セッションハイジャック、DNS 偽装などの深刻な脆弱性が発生する可能性があります。

例 1: 次のコードは、統計的 PRNG を使用して RSA 鍵を作成します。

import "math/rand"
...
var mathRand = rand.New(rand.NewSource(1))
rsa.GenerateKey(mathRand, 2048)

このコードは rand.New() 関数を使用して、RSA 鍵の乱数を生成します。rand.New() は統計的 PRNG なので、生成される値の推測は攻撃者にとってはたやすいことです。

Insecure Randomness エラーが発生するのは、セキュリティが重要であるコンテキストで、ランダム性のソースとして、予期可能な値を生成する関数が使用される場合です。

コンピュータは決定論的な機械であるため、真のランダム性を生成することはできません。Pseudo-Random Number Generator (PRNG) はランダム性をアルゴリズムにより近似します。最初の値はシードと呼ばれ、後続の値はそこから計算されます。

PRNG には、統計的なものと暗号的なものがあります。統計的 PRNG は有用な統計上の特性を提供しますが、その出力はきわめて予測可能で、再現しやすい数値ストリームを形成するため、生成される値を予期できないことにセキュリティが依存している場合の使用には不適切です。この問題に対処するため、暗号的 PRNG は、より予期しにくい出力を生成します。値を暗号によって保護するためには、攻撃者が生成されたランダムな値と真にランダムな値を区別することが不可能か、または非常に困難である必要があります。一般的に、PRNG アルゴリズムは、暗号的に安全であると告知されていなければ統計的 PRNG である可能性が高く、セキュリティが重要なコンテキストで使用すべきではありません。PRNG アルゴリズムを使用することで、解読されやすい一時パスワードや暗号化キー、セッションハイジャック、DNS 偽装などの深刻な脆弱性が発生する可能性があります。

例 1: 次のコードは統計的 PRNG を使用して、購入後の一定期間利用できる領収書の URL を作成します。

function genReceiptURL (baseURL){
  var randNum = Math.random();
  var receiptURL = baseURL + randNum + ".html";
  return receiptURL;
}

このコードは Math.random() 関数を使用して、領収書ページの一意の識別子を生成します。Math.random() は統計的 PRNG なので、生成される文字列の推測は攻撃者にとってはたやすいことです。領収書システムの基礎設計にも欠陥がありますが、暗号的 PRNG など、予測可能な領収書 ID を生成しない乱数ジェネレータを使えば安全性が高まります。

Insecure Randomness エラーが発生するのは、セキュリティが重要であるコンテキストで、ランダム性のソースとして、予期可能な値を生成する関数が使用される場合です。

コンピュータは決定論的な機械であるため、真のランダム性を生成することはできません。Pseudo-Random Number Generator (PRNG) はランダム性をアルゴリズムにより近似します。最初の値はシードと呼ばれ、後続の値はそこから計算されます。

PRNG には、統計的なものと暗号的なものがあります。統計的 PRNG は有用な統計上の特性を提供しますが、その出力はきわめて予測可能で、再現しやすい数値ストリームを形成するため、生成される値を予期できないことにセキュリティが依存している場合の使用には不適切です。この問題に対処するため、暗号的 PRNG は、より予期しにくい出力を生成します。値を暗号によって保護するためには、攻撃者が生成されたランダムな値と真にランダムな値を区別することが不可能か、または非常に困難である必要があります。一般的に、PRNG アルゴリズムは、暗号的に安全であると告知されていなければ統計的 PRNG である可能性が高く、セキュリティが重要なコンテキストで使用すべきではありません。PRNG アルゴリズムを使用することで、解読されやすい一時パスワードや暗号化キー、セッションハイジャック、DNS 偽装などの深刻な脆弱性が発生する可能性があります。

例 1: 次のコードは統計的 PRNG を使用して、購入後の一定期間利用できる領収書の URL を作成します。

fun GenerateReceiptURL(baseUrl: String): String {
    val ranGen = Random(Date().getTime())
    return baseUrl + ranGen.nextInt(400000000).toString() + ".html"
}

このコードは Random.nextInt() 関数を使用して、領収書ページの「一意の」識別子を生成します。Random.nextInt() は統計的 PRNG なので、生成される文字列の推測は攻撃者にとってはたやすいことです。領収書システムの基礎設計にも欠陥がありますが、暗号的 PRNG など、予測可能な領収書 ID を生成しない乱数ジェネレータを使えば安全性が高まります。

Insecure Randomness エラーが発生するのは、セキュリティが重要であるコンテキストで、ランダム性のソースとして、予期可能な値を生成する関数が使用される場合です。

コンピュータは決定論的な機械であるため、真のランダム性を生成することはできません。Pseudo-Random Number Generator (PRNG) はランダム性をアルゴリズムにより近似します。最初の値はシードと呼ばれ、後続の値はそこから計算されます。

PRNG には、統計的なものと暗号的なものがあります。統計的 PRNG は有用な統計上の特性を提供しますが、その出力はきわめて予測可能で、再現しやすい数値ストリームを形成するため、生成される値を予期できないことにセキュリティが依存している場合の使用には不適切です。この問題に対処するため、暗号的 PRNG は、より予期しにくい出力を生成します。値を暗号によって保護するためには、攻撃者が生成されたランダムな値と真にランダムな値を区別することが不可能か、または非常に困難である必要があります。一般的に、PRNG アルゴリズムは、暗号的に安全であると告知されていなければ統計的 PRNG である可能性が高く、セキュリティが重要なコンテキストで使用すべきではありません。PRNG アルゴリズムを使用することで、解読されやすい一時パスワードや暗号化キー、セッションハイジャック、DNS 偽装などの深刻な脆弱性が発生する可能性があります。

例 1: 次のコードは統計的 PRNG を使用して、購入後の一定期間利用できる領収書の URL を作成します。

  function genReceiptURL($baseURL) {
    $randNum = rand();
    $receiptURL = $baseURL . $randNum . ".html";
    return $receiptURL;
  }

このコードは rand() 関数を使用して、領収書ページの一意の識別子を生成します。rand() は統計的 PRNG なので、生成される文字列の推測は攻撃者にとってはたやすいことです。領収書システムの基礎設計にも欠陥がありますが、暗号的 PRNG など、予測可能な領収書 ID を生成しない乱数ジェネレータを使えば安全性が高まります。

Insecure Randomness エラーが発生するのは、セキュリティが重要であるコンテキストで、ランダム性のソースとして、予期可能な値を生成する関数が使用される場合です。

コンピュータは決定論的な機械であるため、真のランダム性を生成することはできません。Pseudo-Random Number Generator (PRNG) はランダム性をアルゴリズムにより近似します。最初の値はシードと呼ばれ、後続の値はそこから計算されます。

PRNG には、統計的なものと暗号的なものがあります。統計的 PRNG は有用な統計上の特性を提供しますが、その出力はきわめて予測可能で、再現しやすい数値ストリームを形成するため、生成される値を予期できないことにセキュリティが依存している場合の使用には不適切です。この問題に対処するため、暗号的 PRNG は、より予期しにくい出力を生成します。値を暗号によって保護するためには、攻撃者が生成されたランダムな値と真にランダムな値を区別することが不可能か、または非常に困難である必要があります。一般的に、PRNG アルゴリズムは、暗号的に安全であると告知されていなければ統計的 PRNG である可能性が高く、セキュリティが重要なコンテキストで使用すべきではありません。PRNG アルゴリズムを使用することで、解読されやすい一時パスワードや暗号化キー、セッションハイジャック、DNS 偽装などの深刻な脆弱性が発生する可能性があります。

例 1: 次のコードは統計的 PRNG を使用して、購入後の一定期間利用できる領収書の URL を作成します。

CREATE or REPLACE FUNCTION CREATE_RECEIPT_URL
  RETURN VARCHAR2
AS
  rnum VARCHAR2(48);
  time TIMESTAMP;
  url VARCHAR2(MAX_URL)
BEGIN
  time := SYSTIMESTAMP;
  DBMS_RANDOM.SEED(time);
  rnum := DBMS_RANDOM.STRING('x', 48);
  url := 'http://test.com/' || rnum || '.html';
  RETURN url;
END

このコードは DBMS_RANDOM.SEED() 関数を使用して、領収書ページの一意の識別子を生成します。DBMS_RANDOM.SEED() は統計的 PRNG なので、生成される文字列の推測は攻撃者にとってはたやすいことです。領収書システムの基礎設計にも欠陥がありますが、予測可能な領収書 ID を生成しない乱数ジェネレータを使えば安全性が高まります。

Insecure Randomness エラーが発生するのは、セキュリティが重要であるコンテキストで、ランダム性のソースとして、予期可能な値を生成する関数が使用される場合です。

コンピュータは決定論的な機械であるため、真のランダム性を生成することはできません。Pseudo-Random Number Generator (PRNG) はランダム性をアルゴリズムにより近似します。最初の値はシードと呼ばれ、後続の値はそこから計算されます。

PRNG には、統計的なものと暗号的なものがあります。統計的 PRNG は有用な統計上の特性を提供しますが、その出力はきわめて予測可能で、再現しやすい数値ストリームを形成するため、生成される値を予期できないことにセキュリティが依存している場合の使用には不適切です。この問題に対処するため、暗号的 PRNG は、より予期しにくい出力を生成します。値を暗号によって保護するためには、攻撃者が生成されたランダムな値と真にランダムな値を区別することが不可能か、または非常に困難である必要があります。一般的に、PRNG アルゴリズムは、暗号的に安全であると告知されていなければ統計的 PRNG である可能性が高く、セキュリティが重要なコンテキストで使用すべきではありません。PRNG アルゴリズムを使用することで、解読されやすい一時パスワードや暗号化キー、セッションハイジャック、DNS 偽装などの深刻な脆弱性が発生する可能性があります。

例 1: 次のコードは統計的 PRNG を使用して、購入後の一定期間利用できる領収書の URL を作成します。

    def genReceiptURL(self,baseURL):
        randNum = random.random()
        receiptURL = baseURL + randNum + ".html"
        return receiptURL

このコードは rand() 関数を使用して、領収書ページの一意の識別子を生成します。rand() は統計的 PRNG なので、生成される文字列の推測は攻撃者にとってはたやすいことです。領収書システムの基礎設計にも欠陥がありますが、暗号的 PRNG など、予測可能な領収書 ID を生成しない乱数ジェネレータを使えば安全性が高まります。

Insecure Randomness エラーが発生するのは、セキュリティが重要であるコンテキストで、ランダム性のソースとして、予期可能な値を生成する関数が使用される場合です。

コンピュータは決定論的な機械であるため、真のランダム性を生成することはできません。Pseudo-Random Number Generator (PRNG) はランダム性をアルゴリズムにより近似します。最初の値はシードと呼ばれ、後続の値はそこから計算されます。

PRNG には、統計的なものと暗号的なものがあります。統計的 PRNG は有用な統計上の特性を提供しますが、その出力はきわめて予測可能で、再現しやすい数値ストリームを形成するため、生成される値を予期できないことにセキュリティが依存している場合の使用には不適切です。この問題に対処するため、暗号的 PRNG は、より予期しにくい出力を生成します。値を暗号によって保護するためには、攻撃者が生成されたランダムな値と真にランダムな値を区別することが不可能か、または非常に困難である必要があります。一般的に、PRNG アルゴリズムは、暗号的に安全であると告知されていなければ統計的 PRNG である可能性が高く、セキュリティが重要なコンテキストで使用すべきではありません。PRNG アルゴリズムを使用することで、解読されやすい一時パスワードや暗号化キー、セッションハイジャック、DNS 偽装などの深刻な脆弱性が発生する可能性があります。

例 1: 次のコードは統計的 PRNG を使用して、購入後の一定期間利用できる領収書の URL を作成します。

def generateReceiptURL(baseUrl) {
  randNum = rand(400000000)
  return ("#{baseUrl}#{randNum}.html");
}

このコードは Kernel.rand() 関数を使用して、領収書ページの一意の識別子を生成します。Kernel.rand() は統計的 PRNG なので、生成される文字列の推測は攻撃者にとってはたやすいことです。

Insecure Randomness エラーが発生するのは、セキュリティが重要であるコンテキストで、ランダム性のソースとして、予期可能な値を生成する関数が使用される場合です。

コンピュータは決定論的な機械であるため、真のランダム性を生成することはできません。Pseudo-Random Number Generator (PRNG) はランダム性をアルゴリズムにより近似します。最初の値はシードと呼ばれ、後続の値はそこから計算されます。

PRNG には、統計的なものと暗号的なものがあります。統計的 PRNG は有用な統計上の特性を提供しますが、その出力はきわめて予測可能で、再現しやすい数値ストリームを形成するため、生成される値を予期できないことにセキュリティが依存している場合の使用には不適切です。この問題に対処するため、暗号的 PRNG は、より予期しにくい出力を生成します。値を暗号によって保護するためには、攻撃者が生成されたランダムな値と真にランダムな値を区別することが不可能か、または非常に困難である必要があります。一般的に、PRNG アルゴリズムは、暗号的に安全であると告知されていなければ統計的 PRNG である可能性が高く、セキュリティが重要なコンテキストで使用すべきではありません。PRNG アルゴリズムを使用することで、解読されやすい一時パスワードや暗号化キー、セッションハイジャック、DNS 偽装などの深刻な脆弱性が発生する可能性があります。

例 1: 次のコードは統計的 PRNG を使用して、購入後の一定期間利用できる領収書の URL を作成します。

def GenerateReceiptURL(baseUrl : String) : String {
    val ranGen = new scala.util.Random()
    ranGen.setSeed((new Date()).getTime())
    return (baseUrl + ranGen.nextInt(400000000) + ".html")
}

このコードは Random.nextInt() 関数を使用して、領収書ページの一意の識別子を生成します。Random.nextInt() は統計的 PRNG なので、生成される文字列の推測は攻撃者にとってはたやすいことです。領収書システムの基礎設計にも欠陥がありますが、暗号的 PRNG など、予測可能な領収書 ID を生成しない乱数ジェネレータを使えば安全性が高まります。

Insecure Randomness エラーが発生するのは、セキュリティが重要であるコンテキストで、ランダム性のソースとして、予期可能な値を生成する関数が使用される場合です。

コンピュータは決定論的な機械であるため、真のランダム性を生成することはできません。Pseudo-Random Number Generator (PRNG) はランダム性をアルゴリズムにより近似します。最初の値はシードと呼ばれ、後続の値はそこから計算されます。

PRNG には、統計的なものと暗号的なものがあります。統計的 PRNG は有用な統計上の特性を提供しますが、その出力はきわめて予測可能で、再現しやすい数値ストリームを形成するため、生成される値を予期できないことにセキュリティが依存している場合の使用には不適切です。この問題に対処するため、暗号的 PRNG は、より予期しにくい出力を生成します。値を暗号によって保護するためには、攻撃者が生成されたランダムな値と真にランダムな値を区別することが不可能か、または非常に困難である必要があります。一般的に、PRNG アルゴリズムは、暗号的に安全であると告知されていなければ統計的 PRNG である可能性が高く、セキュリティが重要なコンテキストで使用すべきではありません。PRNG アルゴリズムを使用することで、解読されやすい一時パスワードや暗号化キー、セッションハイジャック、DNS 偽装などの深刻な脆弱性が発生する可能性があります。

例 1: 次のコードでは、統計的 PRNG を使用してパスワードのリセット トークンとして使用されるランダムな値を作成します。

    sqlite3_randomness(10, &reset_token)

Insecure Randomness エラーが発生するのは、セキュリティが重要であるコンテキストで、ランダム性のソースとして、予期可能な値を生成する関数が使用される場合です。

コンピュータは決定論的な機械であるため、真のランダム性を生成することはできません。Pseudo-Random Number Generator (PRNG) はランダム性をアルゴリズムにより近似します。最初の値はシードと呼ばれ、後続の値はそこから計算されます。

PRNG には、統計的なものと暗号的なものがあります。統計的 PRNG は有用な統計上の特性を提供しますが、その出力はきわめて予測可能で、再現しやすい数値ストリームを形成するため、生成される値を予期できないことにセキュリティが依存している場合の使用には不適切です。この問題に対処するため、暗号的 PRNG は、より予期しにくい出力を生成します。値を暗号によって保護するためには、攻撃者が生成されたランダムな値と真にランダムな値を区別することが不可能か、または非常に困難である必要があります。一般的に、PRNG アルゴリズムは、暗号的に安全であると告知されていなければ統計的 PRNG である可能性が高く、セキュリティが重要なコンテキストで使用すべきではありません。PRNG アルゴリズムを使用することで、解読されやすい一時パスワードや暗号化キー、セッションハイジャック、DNS 偽装などの深刻な脆弱性が発生する可能性があります。

例 1: 次のコードは統計的 PRNG を使用して、購入後の一定期間利用できる領収書の URL を作成します。

...
Function genReceiptURL(baseURL)
dim randNum
randNum = Rnd()
genReceiptURL = baseURL & randNum & ".html"
End Function
...

このコードは Rnd() 関数を使用して、領収書ページの一意の識別子を生成します。Rnd() は統計的 PRNG なので、生成される文字列の推測は攻撃者にとってはたやすいことです。領収書システムの基礎設計にも欠陥がありますが、暗号的 PRNG など、予測可能な領収書 ID を生成しない乱数ジェネレータを使えば安全性が高まります。

ランダム値または疑似ランダム値を生成する関数 (シードが渡される) を、定数の引数を使用してコールしないでください。疑似乱数ジェネレーター (CL_ABAP_RANDOM クラスまたはそのバリアントなど) が特定の定数値を使用してシードされると、値を返すかまたは割り当てる GET_NEXT、INT および類似のメソッドによって返される値を攻撃者が予測できるようになり、攻撃者は複数の PRNG 出力を収集できるようになります。

例 1: 次の引用では、オブジェクト random_gen2 で生成される値は、オブジェクト random_gen1 から予想できます。

		DATA: random_gen1 TYPE REF TO cl_abap_random,
			  random_gen2 TYPE REF TO cl_abap_random,
			  var1 TYPE i,
			  var2 TYPE i.

		random_gen1 = cl_abap_random=>create( seed = '1234' ).

		DO 10 TIMES.
			CALL METHOD random_gen1->int
				RECEIVING
			value  = var1.

			WRITE:/ var1.
		ENDDO.

		random_gen2 = cl_abap_random=>create( seed = '1234' ).

		DO 10 TIMES.
			CALL METHOD random_gen2->int
				RECEIVING
			value  = var2.

			WRITE:/ var2.
		ENDDO.

この例では、疑似乱数ジェネレータ、random_gen1 と random_gen2 が同じようにシードされたため、var1 = var2 となります

ランダム値または疑似ランダム値を生成する関数 (シードが渡される) を、定数の引数を使用してコールしないでください。特定の値を使用して (srand(unsigned int) のような関数を使用) 疑似ランダム数値の生成機能 (rand() など) をシードすると、値を返すかまたは割り当てる rand() および類似のメソッドによって返される値は、攻撃者にとって予想可能になり、攻撃者が複数の PRNG 出力を収集できるようになります。

例 1: 疑似ランダム数値の生成機能で生成される値が、最初の 2 つのブロックで予測できます (どちらも同じシードで開始されるため)。

        srand(2223333);
        float randomNum = (rand() % 100);
        syslog(LOG_INFO, "Random: %1.2f", randomNum);
        randomNum = (rand() % 100);
        syslog(LOG_INFO, "Random: %1.2f", randomNum);

        srand(2223333);
        float randomNum2 = (rand() % 100);
        syslog(LOG_INFO, "Random: %1.2f", randomNum2);
        randomNum2 = (rand() % 100);
        syslog(LOG_INFO, "Random: %1.2f", randomNum2);

        srand(1231234);
        float randomNum3 = (rand() % 100);
        syslog(LOG_INFO, "Random: %1.2f", randomNum3);
        randomNum3 = (rand() % 100);
        syslog(LOG_INFO, "Random: %1.2f", randomNum3);

この例では、randomNum1 と randomNum2 の結果は同一の方法でシードされているので、擬似ランダム数値の生成機能 srand(2223333) をシードするコール後の rand() への各コールは、結果的に同じコール実行順序で同じ出力になります。たとえば、出力は以下のようになります。

Random: 32.00
Random: 73.00
Random: 32.00
Random: 73.00
Random: 15.00
Random: 75.00

このような結果は決してランダムではありません。

ランダム値または疑似ランダム値を生成する関数 (シードが渡される) を、定数の引数を使用してコールしないでください。疑似乱数ジェネレーター (PRNG) が特定の値を使用 (math.Rand.New(Source) のような関数を使用) してシードされると、値を返すかまたは割り当てる math.Rand.Int() および類似のメソッドによって返される値を攻撃者が予測できるようになり、攻撃者は複数の PRNG 出力を収集できるようになります。

例 1: 疑似ランダム数値の生成機能で生成される値が、最初の 2 つのブロックで予測できます (どちらも同じシードで開始されるため)。

  randomGen := rand.New(rand.NewSource(12345))
  randomInt1 := randomGen.nextInt()
  
  randomGen.Seed(12345)
  randomInt2 := randomGen.nextInt()

この例では、PRNG が同一の方法でシードされるため、擬似乱数ジェネレーターにシードを設定したコール (randomGen.Seed(12345)) の後に nextInt() をコールすると、同じ出力が同じ順序で得られます。

ランダム値または疑似ランダム値を生成する関数 (シードが渡される) を、定数の引数を使用してコールしないでください。疑似乱数ジェネレーター (Random など) が特定の値を使用 (Random(Int) のような関数を使用) してシードされると、値を返すかまたは割り当てる Random.nextInt() および類似のメソッドによって返される値を攻撃者が予測できるようになり、攻撃者は複数の PRNG 出力を収集できるようになります。

例 1:Random オブジェクト randomGen2 によって生成される値は、Random オブジェクト randomGen1 から予想できます。

        val randomGen1 = Random(12345)
        val randomInt1 = randomGen1.nextInt()
        val byteArray1 = ByteArray(4)
        randomGen1.nextBytes(byteArray1)

        val randomGen2 = Random(12345)
        val randomInt2 = randomGen2.nextInt()
        val byteArray2 = ByteArray(4)
        randomGen2.nextBytes(byteArray2)

この例では、疑似乱数ジェネレータ、randomGen1 と randomGen2 は同一の方法でシードされるので、randomInt1 == randomInt2、および対応する配列 byteArray1 と byteArray2 の値は等しくなります。

疑似ランダム値を生成する関数 (シードが渡される) を、整数の定数引数を使用してコールしないでください。疑似ランダム数値の生成機能が特定の値でシードされる場合、返される値が予測できます。

例 1: 疑似ランダム数値の生成機能で生成される値が、最初の 2 つのブロックで予測できます (どちらも同じシードで開始されるため)。

...
import random
random.seed(123456)
print "Random: %d" % random.randint(1,100)
print "Random: %d" % random.randint(1,100)
print "Random: %d" % random.randint(1,100)

random.seed(123456)
print "Random: %d" % random.randint(1,100)
print "Random: %d" % random.randint(1,100)
print "Random: %d" % random.randint(1,100)
...

この例では、PRNG が同様にシードされているため、疑似ランダム数値の生成機能 (random.seed(123456)) をシードするコールの後の randint() への各コールの結果、同じものが同じ順序で出力されます。たとえば、出力は以下のようになります。

Random: 81
Random: 80
Random: 3
Random: 81
Random: 80
Random: 3

このような結果は決してランダムではありません。

ランダム値または疑似ランダム値を生成する関数 (シードが渡される) を、定数の引数を使用してコールしないでください。疑似乱数ジェネレーター (Random など) が特定の値を使用 (Random.setSeed() のような関数を使用) してシードされると、値を返すかまたは割り当てる Random.nextInt() および類似のメソッドによって返される値を攻撃者が予測できるようになり、攻撃者は複数の PRNG 出力を収集できるようになります。

例 1:Random オブジェクト randomGen2 によって生成される値は、Random オブジェクト randomGen1 から予想できます。

        val randomGen1 = new Random()
        randomGen1.setSeed(12345)
        val randomInt1 = randomGen1.nextInt()
        val bytes1 = new byte[4]
        randomGen1.nextBytes(bytes1)

        val randomGen2 = new Random()
        randomGen2.setSeed(12345)
        val randomInt2 = randomGen2.nextInt()
        val bytes2 = new byte[4]
        randomGen2.nextBytes(bytes2)

この例では、疑似乱数ジェネレータ、randomGen1 と randomGen2 は同一の方法でシードされるので、randomInt1 == randomInt2、および対応する配列 bytes1[] と bytes2[] の値は等しくなります。

クラス CL_ABAP_RANDOM (またはそのバリアント) を、汚染された引数を使用して初期化しないでください。そのような初期化を行うと、攻撃者が疑似ランダム数値の生成機能のシードに使用される値を制御できるようになります。したがって、以下のようなメソッド (これらに限りません) へのコールによって作成された値のシーケンスを攻撃者が予測できるようになります。 GET_NEXT, INT, FLOAT, PACKED.

ランダム値または疑似ランダム値 (rand() など) を生成する関数 (シード (srand() など) が渡される) を、汚染された引数を使用してコールしないでください。このようなコールを行うと、攻撃者が疑似ランダム数値の生成機能のシードに使用される値を制御できるようになります。したがって、擬似乱数生成機能へのコールによって作成された値のシーケンス (通常は整数) を攻撃者が予測できるようになります。

疑似ランダム値を生成する関数 (ed25519.NewKeyFromSeed()) を、汚染された引数を使用してコールしないでください。そのようなコールを行うと、攻撃者は疑似乱数ジェネレータのシードに使用する値を制御できるようになるため、疑似乱数ジェネレータを呼び出したときに生成される一連の値を予測することができるようになります。

Random.setSeed() を、汚染された整数引数を使用してコールしないでください。そのようなコールを行うと、攻撃者は疑似ランダム数値生成機能のシードに使用する値を制御できるようになるため、Random.nextInt()、Random.nextLong()、Random.nextDouble() へのコールにより生成されるか、Random.nextBoolean() により返されるか、または Random.nextBytes(ByteArray) で設定される値 (通常は整数) のシーケンスを予想できるようになります。

疑似ランダム値を生成する関数 (random.randint() など) を、汚染された引数を使用してコールしないでください。このようなコールを行うと、攻撃者が疑似ランダム数値の生成機能のシードに使用される値を制御できるようになります。したがって、疑似ランダム数値生成機能へのコールによって作成された値のシーケンス (通常は整数) を攻撃者が予測できるようになります。

Random.setSeed() を、汚染された整数引数を使用してコールしないでください。そのようなコールを行うと、攻撃者は疑似ランダム数値生成機能のシードに使用する値を制御できるようになるため、Random.nextInt()、Random.nextShort()、Random.nextLong() へのコールにより生成されるか、Random.nextBoolean() により返されるか、または Random.nextBytes(byte[]) で設定される値 (通常は整数) のシーケンスを予想できるようになります。

公開鍵基盤 (PKI) は、信頼できる証明機関 (CA) に基づいていますが、侵害された証明機関の数が増えるとルート証明書を信用できなくなり、その結果、この CA が署名した証明書も信用できなくなります。こうした侵害された証明書を入手した攻撃者は、これらの CA を信頼するすべての SSL/TLS トラフィックを傍受できるようになります。

証明機関の署名を必要とするのは、任意のネットワーク エンドポイントに接続し、それらのエンドポイントの SSL/TLS 証明書にどの CA が署名したかが事前にわからないブラウザーなどの汎用ネットワーク通信ツールです。限られた数のバックエンド サーバーに接続するモバイル アプリケーションでは、これらのサーバーが証明書の署名に使用した信頼できる CA の数を絞り込んで把握できるというメリットがあり、これらの証明書/公開鍵をアプリケーションに「ピン留め」して信頼する対象をアプリケーションが期待する証明書に減らすことができます。

例 1: 次の例では、デフォルトのプリロードされたシステム CA を使用して SSL/TLS 接続を確立しています。

val url = URL("https://myserver.org")
val data = url.readBytes()

URLConnection で使用される基礎の SSLSocketFactory は変更されていないため、Android のデフォルト鍵ストアに存在するすべての CA を信頼するデフォルトが使用されます。

公開鍵基盤 (PKI) は、信頼できる証明機関 (CA) に基づいていますが、侵害された証明機関の数が増えるとルート証明書を信用できなくなり、その結果、この CA が署名した証明書も信用できなくなります。こうした侵害された証明書を入手した攻撃者は、これらの CA を信頼するすべての SSL/TLS トラフィックを傍受できるようになります。

証明機関の署名を必要とするのは、任意のネットワーク エンドポイントに接続し、それらのエンドポイントの SSL/TLS 証明書にどの CA が署名したかが事前にわからないブラウザーなどの汎用ネットワーク通信ツールです。限られた数のバックエンド サーバーに接続するモバイル アプリケーションでは、これらのサーバーが証明書の署名に使用した信頼できる CA の数を絞り込んで把握できるというメリットがあり、これらの証明書/公開鍵をアプリケーションに「ピン留め」して信頼する対象をアプリケーションが期待する証明書に減らすことができます。

例 1: 次の例では、デフォルトのプリロードされたシステム CA を使用して SSL/TLS 接続を確立しています。

NSString* requestString = @"https://myserver.org";
NSURL* requestUrl = [NSURL URLWithString:requestString];
NSURLRequest* request = [NSURLRequest requestWithURL:requestUrl
                                         cachePolicy:NSURLRequestReloadIgnoringLocalCacheData
                                     timeoutInterval:10.0f];
NSURLConnection* connection = [[NSURLConnection alloc] initWithRequest:request delegate:self];

証明書の検証を処理するための NSURLConnectionDelegate メソッドが定義されていないため、iOS のデフォルト鍵ストアに存在するすべての CA を信頼するシステム メソッドが使用されます。

公開鍵基盤 (PKI) は、信頼できる証明機関 (CA) に基づいていますが、侵害された証明機関の数が増えるとルート証明書を信用できなくなり、その結果、この CA が署名した証明書も信用できなくなります。こうした侵害された証明書を入手した攻撃者は、これらの CA を信頼するすべての SSL/TLS トラフィックを傍受できるようになります。

証明機関の署名を必要とするのは、任意のネットワーク エンドポイントに接続し、それらのエンドポイントの SSL/TLS 証明書にどの CA が署名したかが事前にわからないブラウザーなどの汎用ネットワーク通信ツールです。限られた数のバックエンド サーバーに接続するモバイル アプリケーションでは、これらのサーバーが証明書の署名に使用した信頼できる CA の数を絞り込んで把握できるというメリットがあり、これらの証明書/公開鍵をアプリケーションに「ピン留め」して信頼する対象をアプリケーションが期待する証明書に減らすことができます。

例 1: 次の例では、デフォルトのプリロードされたシステム CA を使用して SSL/TLS 接続を確立しています。

let requestString = NSURL(string: "https://myserver.org") 
let requestUrl : NSURL = NSURL(string:requestString)!;
let request : NSURLRequest = NSURLRequest(URL:requestUrl);
let connection : NSURLConnection = NSURLConnection(request:request, delegate:self)!;

証明書の検証を処理するための NSURLConnectionDelegate メソッドが定義されていないため、iOS のデフォルト鍵ストアに存在するすべての CA を信頼するシステム メソッドが使用されます。

SSL 接続を使用するライブラリによっては、サーバー証明書はデフォルトで検証されません。これはすべての証明書を信頼することと同じです。その他のインスタンスでは、故意かどうかにかかわらず、これを明示的に無効化できます。

例 1: このアプリケーションは常に証明書チェーンが正しいことを検証するため、すべての証明書を信頼します。

...
private bool CertificateCheck(object sender, X509Certificate certificate, X509Chain chain, SslPolicyErrors sslPolicyErrors)
{
  ...
  return true; 
}
...
  HttpWebRequest webRequest = (HttpWebRequest) WebRequest.Create("https://www.myTrustedSite.com");
  webRequest.ServerCertificateValidationCallback = CertificateCheck;
  WebResponse response = webRequest.GetResponse();
...

"https://www.myTrustedSite.com" への接続を試みると、このアプリケーションは "hackedserver.com" に対して発行された証明書を受け入れます。アプリケーションは、ハッキングされているサーバーへの不正な SSL 接続によって、ユーザー機密情報をリークさせる可能性があります。

SSL 接続を使用する一部のライブラリでは、サーバー証明書の検証を無効にすることができます。これはすべての証明書を信頼することと同じです。

例 1: このアプリケーションは証明書の検証を明示的に無効にします。

...
  SSL_CTX_set_verify(ctx, SSL_VERIFY_NONE, verify_callback);
...

有効なホストへの接続を試みると、このアプリケーションは "hackedserver.com" に対して発行された証明書を即座に受け入れます。アプリケーションは、ハッキングされているサーバーへの不正な SSL 接続によって、ユーザー機密情報をリークさせる可能性があります。

SSL 接続を使用するライブラリによっては、サーバー証明書はデフォルトで検証されません。これはすべての証明書を信頼することと同じです。

例 1: このアプリケーションは、サーバー証明書を明示的に検証しません。

    ...
    config := &tls.Config{
        // Set InsecureSkipVerify to skip the default validation
        InsecureSkipVerify: true,
        ...
    }

    conn, err := tls.Dial("tcp", "example.com:443", conf)
    ..
    

example.com への接続を試みると、このアプリケーションはサーバーによって発行される証明書を容易に受け入れます。これによりアプリケーションは、ハッキングされているサーバーへの不正な SSL 接続によって、ユーザー機密情報をリークさせる可能性があります。

SSL 接続を使用するライブラリによっては、サーバー証明書はデフォルトで検証されません。これはすべての証明書を信頼することと同じです。

例 1: このサーバーは、クライアント接続を不正に検証しようとします。

...
var options = {
  key : fs.readFileSync('my-server-key.pem'),
  cert : fs.readFileSync('server-cert.pem'),
  requestCert: true,
  ...
}
https.createServer(options);
...

この https.Server オブジェクトが作成されるとき、設定 requestCert は true に指定されますが rejectUnauthorized は指定されずにデフォルトの false になります。つまり、サーバーは SSL を介してクライアントを検証するように作成されましたが、証明書が提供されている CA のリストで承認されていない場合にも接続が受け入れられます。

例 2: 次のアプリケーションは、SSL を介してサーバーに接続しようとします。

var tls = require('tls');
...
tls.connect({
  host: 'https://www.hackersite.com',
  port: '443',
  ...
  rejectUnauthorized: false,
  ...
});

この例では、rejectUnauthorized が False に設定されたので、権限のない証明書が受け入れられ、未確認のサーバーとのセキュアな接続が引き続き作成されることを意味します。アプリケーションは、ハッキングされているサーバーへの不正な SSL 接続によって、ユーザー機密情報をリークさせる可能性があります。

SSL 接続が行われる一部のライブラリでは、既定でサーバー証明書を検証しません (またはそのように明示的に設定されています)。これはすべての証明書を信頼することと同じです。

例 1: このコードは、HTTPS 証明書を受け取るように NSURLConnectionDelegate を設定します。

implementation NSURLRequest (IgnoreSSL)

+ (BOOL)allowsAnyHTTPSCertificateForHost:(NSString *)host
{
  return YES;
}

@end

Example 1 の NSURLRequest の実装を使用して SSL によりセキュリティ保護されるサーバーに接続するとき、リクエストされたサーバーの証明書が自己署名されている (これにより検証されない) 場合は警告やエラーが発生しません。これにより、アプリケーションはユーザーの機密情報を不正な SSL 接続によって漏洩する可能性があります。

SSL 接続を使用する一部のライブラリでは、サーバー証明書の検証を無効にすることができます。これはすべての証明書を信頼することと同じです。

例 1: このアプリケーションは、既定ではサーバー証明書を検証しません。

...
import ssl
ssl_sock = ssl.wrap_socket(s)
...

有効なホストへの接続を試みると、このアプリケーションは "hackedserver.com" に対して発行された証明書を即座に受け入れます。アプリケーションは、ハッキングされているサーバーへの不正な SSL 接続によって、ユーザー機密情報をリークさせる可能性があります。

SSL 接続を使用する一部のライブラリでは、サーバー証明書の検証を無効にすることができます。これはすべての証明書を信頼することと同じです。

例 1: このアプリケーションは証明書の検証を明示的に無効にします。

require 'openssl'
...
ctx = OpenSSL::SSL::SSLContext.new
ctx.verify_mode=OpenSSL::SSL::VERIFY_NONE
...

有効なホストへの接続を試みると、このアプリケーションは "hackedserver.com" に対して発行された証明書を即座に受け入れます。アプリケーションは、ハッキングされているサーバーへの不正な SSL 接続によって、ユーザー機密情報をリークさせる可能性があります。

SSL 接続が行われる一部のライブラリでは、既定でサーバー証明書を検証しません (またはそのように明示的に設定されています)。これはすべての証明書を信頼することと同じです。

例 1: このコードは、HTTPS 証明書を受け取るように NSURLConnectionDelegate を設定します。

class Delegate: NSObject, NSURLConnectionDelegate {
    
    ...

    func connection(connection: NSURLConnection, canAuthenticateAgainstProtectionSpace protectionSpace: NSURLProtectionSpace?) -> Bool {
        return protectionSpace?.authenticationMethod == NSURLAuthenticationMethodServerTrust
    }

    func connection(connection: NSURLConnection, willSendRequestForAuthenticationChallenge challenge: NSURLAuthenticationChallenge) {
        challenge.sender?.useCredential(NSURLCredential(forTrust: challenge.protectionSpace.serverTrust!), forAuthenticationChallenge: challenge)
        challenge.sender?.continueWithoutCredentialForAuthenticationChallenge(challenge)
    }
}

Example 1 の NSURLConnectionDelegate の実装を使用して SSL によりセキュリティ保護されるサーバーに接続するとき、リクエストされたサーバーの証明書が自己署名されている (これにより検証されない) 場合は警告やエラーが発生しません。これにより、アプリケーションはユーザーの機密情報を不正な SSL 接続によって漏洩する可能性があります。

例 2:NSURLSession クラスでは、SSL/TLS チェーンの検証はアプリケーションの認証委任メソッドによって処理されます。ただし、認証情報を提供してサーバーに対してユーザー (またはアプリケーション) を認証するのではなく、SSL/TLS ハンドシェイク時にサーバーが提供する認証情報をアプリケーションが確認して、URL ローディング システムにそれらの認証情報を許可すべきか拒否すべきかを通知します。次のコードは、サーバー検証を事実上回避し、セッションの認証情報として受け取ったチャレンジの proposedCredential を渡すだけの NSURLSessionDelgate を示しています。

class MySessionDelegate : NSObject, NSURLSessionDelegate {
    ...
    func URLSession(session: NSURLSession, didReceiveChallenge challenge: NSURLAuthenticationChallenge, completionHandler: (NSURLSessionAuthChallengeDisposition, NSURLCredential?) -> Void) {
        ...
        completionHandler(NSURLSessionAuthChallengeDisposition.UseCredential, challenge.proposedCredential)
        ...
    }
    ...
}

HTTP(S) レスポンスには、セッション cookie や API トークンなどの機密データが含まれることがあります。URL ローディング システムはパフォーマンス上の理由ですべての HTTP(S) レスポンスをキャッシュし、{app ID}/Library/Caches/com.mycompany.myapp/Cache.db* ファイルに暗号化せずに格納します。

HTTP(S) レスポンスには、セッション cookie や API トークンなどの機密データが含まれることがあります。URL ローディング システムはパフォーマンス上の理由ですべての HTTP(S) レスポンスをキャッシュし、{app ID}/Library/Caches/com.mycompany.myapp/Cache.db* ファイルに暗号化せずに格納します。