整数オーバーフロー エラーは、プログラムが算術演算の結果、データ型の最大値よりも大きいか、最小値よりも小さい量が得られるという事実を考慮していない場合に発生します。これらのエラーは、ユーザーの入力と、符号付きと符号なしの値の間の暗黙の変換が交差する、メモリ割り当て関数の問題をしばしば引き起こします。攻撃者がプログラムにメモリを過小に割り当てさせたり、メモリ操作で符号付きの値を符号なしの値として解釈させたりできる場合、プログラムがバッファオーバーフローの危険にさらされる可能性があります。

例: 以下のコードの引用は、整数オーバーフローの典型的なケースを示しています。

  77 accept-in PIC 9(10).
  77 num PIC X(4) COMP-5. *> native 32-bit unsigned integer
  77 mem-size PIC X(4) COMP-5.
  ...
  ACCEPT accept-in
  MOVE accept-in TO num
  MULTIPLY 4 BY num GIVING mem-size

  CALL "CBL_ALLOC_MEM" USING
    mem-pointer
    BY VALUE mem-size
    BY VALUE 0
    RETURNING status-code
  END-CALL

num の値が 1073741824 である場合、操作 MULTIPLY 4 BY num の結果はオーバーフローし、malloc() に対する引数 mem-size は 0 になります。ほとんどの malloc() の実装は 0 バイト バッファの割り当てを許可するため、後続のステートメントでヒープ バッファ mem-pointer のオーバーフローが発生します。

整数のオーバーフロー/アンダーフローは、計算または算術演算の結果が整数型の最大値を超えるか、最小値を下回る場合に発生し、これによって値が下限または上限にループバックしてそこから続行されます。算術演算の結果の値は、実際には上限/下限からの整数範囲の係数になります。

たとえば、ある数値が uint256 型で格納されている場合、これは 0 ～ 2^256-1 の範囲の 256 ビット符号なし整数で格納されていることを意味します。算術演算の結果が上限を超える数値になる場合、オーバーフローが発生し、開始値 (0) から余りが加算されます。算術演算により数値が下限を下回る場合、アンダーフローが発生し、最大値 (2^256-1) から余りが減算されます。

例 1: 次のパブリック関数は、整数のオーバーフロー/アンダーフローを引き起こし、マップ内の意図しないインデックスに影響を与える可能性がある算術演算を使用して uint256 マッピングを更新します。

contract overflow {
    mapping(uint256 => uint256) map;

    function init(uint256 k, uint256 v) public {
        map[k] -= v;
    }
}

次の場合に JSO Injection が発生します。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。


2. データが JSON ストリームに書き込まれた場合。

アプリケーションは、通常、JSON を使用してデータを保存したりメッセージを送信したりします。データの保存に使用される場合、JSON はキャッシュ保存されたデータのように扱われ、重要な情報が含まれる場合があります。メッセージの送信に使用される場合、JSON は多くの場合 RESTful サービスと一緒に使用され、認証情報のような機密情報の送信に使用される可能性があります。

アプリケーションが検証されていない入力から JSON を構成する場合、JSON 文書およびメッセージのセマンティクスが改変される場合があります。比較的良性の場合、攻撃者は、JSON 文書またはリクエストをパース中にアプリケーションに例外をスローさせる、余分な要素を挿入できるようになることがあります。JSON Injection を含むなど、より深刻な場合、攻撃者は、JSON 文書またはリクエスト内でビジネスに不可欠な値の予測可能な操作を許可する、余分な要素を挿入できるようになることがあります。また、JSON Injection により、Cross-Site Scripting や Dynamic Code Evaluation が引き起こされる場合もあります。

例 1: 次の C# コードは JSON.NET を使用して、ユーザー制御入力変数 username および password から C:\user_info.json にある JSON ファイルに、権限を与えられていないユーザー (「default」ロールのユーザーです。これに対し権限が付与されたユーザーのロールは「admin」です) のユーザー アカウントの認証情報をシリアライズします。

...

StringBuilder sb = new StringBuilder();
StringWriter sw = new StringWriter(sb);

using (JsonWriter writer = new JsonTextWriter(sw))
{
  writer.Formatting = Formatting.Indented;

  writer.WriteStartObject();

    writer.WritePropertyName("role");
    writer.WriteRawValue("\"default\"");

    writer.WritePropertyName("username");
    writer.WriteRawValue("\"" + username + "\"");

    writer.WritePropertyName("password");
    writer.WriteRawValue("\"" + password + "\"");

  writer.WriteEndObject();
}

File.WriteAllText(@"C:\user_info.json", sb.ToString());

ただし、JSON シリアライゼーションが JsonWriter.WriteRawValue() を使用して実行されるため、username および password 内の信頼できないデータに対して、JSON 関連の特殊文字をエスケープするための検証がされなくなります。これにより、ユーザーが、シリアライズされた JSON の構造を変更する可能性がある JSON キーを随意に挿入できるようになります。この例では、権限を与えられていないユーザー mallory (パスワード Evil123!) が username 変数の値を設定するプロンプトでユーザー名を入力するときに自身のユーザー名に ","role":"admin を追加する場合、結果として C:\user_info.json に保存される JSON は次のようになります。

{
  "role":"default",
  "username":"mallory",
  "role":"admin",
  "password":"Evil123!"
}

このシリアライズされた JSON ファイルがその後 JsonConvert.DeserializeObject() を使用して Dictionary オブジェクトにデシリアライズされた場合はこのようになります。

String jsonString = File.ReadAllText(@"C:\user_info.json");

Dictionary<string, string> userInfo = JsonConvert.DeserializeObject<Dictionary<string, strin>>(jsonString);

Dictionary オブジェクト内で username、password、および role キーの結果として得られる値はそれぞれ mallory、Evil123!、および admin になります。デシリアライズされた JSON 値が有効かについてこれ以上検証しないと、アプリケーションは誤ってユーザー mallory に「admin」権限を割り当てます。

次の場合に JSO Ｉnjection が発生します。

1.信頼できないソースからデータがプログラムに入力された場合。


2.データが JSON ストリームに書き込まれた場合。

アプリケーションは、通常、JSON を使用してデータを保存したりメッセージを送信したりします。データの保存に使用される場合、JSON はキャッシュ保存されたデータのように扱われ、重要な情報が含まれる場合があります。メッセージの送信に使用される場合、JSON は多くの場合 RESTful サービスと一緒に使用され、認証情報のような機密情報を送信する可能性があります。

アプリケーションが検証されていない入力から JSON を構成する場合、JSON 文書およびメッセージのセマンティクスが改変される場合があります。比較的良性の場合、攻撃者は、JSON 文書またはリクエストをパース中にアプリケーションに例外をスローさせる、余分な要素を挿入できるようになることがあります。JSON Injection を含むなど、より深刻な場合、攻撃者は、JSON 文書またはリクエスト内でビジネスに不可欠な値の予測可能な操作を許可する、余分な要素を挿入できるようになることがあります。また、JSON Injection により、Cross-Site Scripting や Dynamic Code Evaluation が引き起こされる場合もあります。

例 1: 次のコードは、ユーザー制御入力変数 username および password から ~/user_info.json にある JSON ファイルに、権限を与えられていないユーザー (「default」ロールのユーザーです。これに対し権限が付与されたユーザーのロールは「admin」です) のユーザー アカウントの認証情報をシリアライズします。

    ...
    func someHandler(w http.ResponseWriter, r *http.Request){
        r.parseForm()
        username := r.FormValue("username")
        password := r.FormValue("password")
        ...
        jsonString := `{
        "username":"` + username + `",
        "role":"default"
        "password":"` + password + `",
        }`
        ...
        f, err := os.Create("~/user_info.json")
        defer f.Close()

        jsonEncoder := json.NewEncoder(f)
        jsonEncoder.Encode(jsonString)
    }
    

ただし、JSON シリアライゼーションが文字列連結を使用して実行されるため、username および password 内の信頼できないデータに対して、JSON 関連の特殊文字をエスケープするための検証がされなくなります。これにより、ユーザーが、シリアライズされた JSON の構造を変更する可能性がある JSON キーを随意に挿入できるようになります。この例では、権限を与えられていないユーザー mallory (パスワード Evil123!) がユーザー名を入力するときに ","role":"admin を追加する場合、結果として ~/user_info.json に保存される JSON は次のようになります。

    {
    "username":"mallory",
    "role":"default",
    "password":"Evil123!",
    "role":"admin"
    }
    

デシリアライズされた JSON 値が有効かどうかこれ以上検証しないと、アプリケーションは意図せずユーザー mallory に「admin」権限を割り当てます。

次の場合に JSO Injection が発生します。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。


2. データが JSON ストリームに書き込まれた場合。

アプリケーションは、通常、JSON を使用してデータを保存したりメッセージを送信したりします。データの保存に使用される場合、JSON はキャッシュ保存されたデータのように扱われ、重要な情報が含まれる場合があります。メッセージの送信に使用される場合、JSON は多くの場合 RESTful サービスと一緒に使用され、認証情報のような機密情報の送信に使用される可能性があります。

アプリケーションが検証されていない入力から JSON を構成する場合、JSON 文書およびメッセージのセマンティクスが改変される場合があります。比較的良性の場合、攻撃者は、JSON 文書またはリクエストをパース中にアプリケーションに例外をスローさせる、余分な要素を挿入できるようになることがあります。JSON Injection を含むなど、より深刻な場合、攻撃者は、JSON 文書またはリクエスト内でビジネスに不可欠な値の予測可能な操作を許可する、余分な要素を挿入できるようになることがあります。また、JSON Injection により、Cross-Site Scripting や Dynamic Code Evaluation が引き起こされる場合もあります。

例 1: 次の JavaScript コードでは、jQuery を使用して URL から値を受け取る JSON をパースしています。

var str = document.URL;
var url_check = str.indexOf('name=');
var name = null;
if (url_check > -1) {
  name =  decodeURIComponent(str.substring((url_check+5), str.length));
}

$(document).ready(function(){
  if (name !== null){
    var obj = jQuery.parseJSON('{"role": "user", "name" : "' + name + '"}');
    ...
  }
  ...
});

ここで、name で信頼されていないデータは検証されずに JSON 関連の特殊文字がエスケープされません。これにより、ユーザーが、シリアライズされた JSON の構造を変更する可能性がある JSON キーを随意に挿入できるようになります。この例では、権限のないユーザー mallory が URL の名前パラメーターに ","role":"admin を追加すると、JSON は次のようになります。

{
  "role":"user",
  "username":"mallory",
  "role":"admin"
}

これは jQuery.parseJSON() によってパースされてプレーン オブジェクトに設定されます。つまり、obj.role は "user" の代わりに "admin" を返すようになります。

次の場合に JSO Injection が発生します。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。


2. データが JSON ストリームに書き込まれた場合。

アプリケーションは、通常、JSON を使用してデータを保存したりメッセージを送信したりします。データの保存に使用される場合、JSON はキャッシュ保存されたデータのように扱われ、重要な情報が含まれる場合があります。メッセージの送信に使用される場合、JSON は多くの場合 RESTful サービスと一緒に使用され、認証情報のような機密情報の送信に使用される可能性があります。

アプリケーションが検証されていない入力から JSON を構成する場合、JSON 文書およびメッセージのセマンティクスが改変される場合があります。比較的良性の場合、攻撃者は、JSON 文書またはリクエストをパース中にアプリケーションに例外をスローさせる、余分な要素を挿入できるようになることがあります。JSON Injection を含むなど、より深刻な場合、攻撃者は、JSON 文書またはリクエスト内でビジネスに不可欠な値の予測可能な操作を許可する、余分な要素を挿入できるようになることがあります。また、JSON Injection により、Cross-Site Scripting や Dynamic Code Evaluation が引き起こされる場合もあります。

例 1: 次の Objective-C コードは、ユーザー制御が可能なフィールド _usernameField および _passwordField から JSON に、権限を与えられていないユーザー (「default」ロールのユーザーです。これに対し権限が付与されたユーザーのロールは「admin」です) のユーザー アカウントの認証情報をシリアライズします。

...

NSString * const jsonString = [NSString stringWithFormat: @"{\"username\":\"%@\",\"password\":\"%@\",\"role\":\"default\"}" _usernameField.text, _passwordField.text];

ただし、JSON シリアライゼーションが NSString.stringWithFormat: を使用して実行されるため、_usernameField および _passwordField 内の信頼できないデータに対して、JSON 関連の特殊文字をエスケープするための検証がされなくなります。これにより、ユーザーが、シリアライズされた JSON の構造を変更する可能性がある JSON キーを随意に挿入できるようになります。この例では、権限を与えられていないユーザー mallory (パスワード Evil123!) がユーザー名を _usernameField フィールドに入力するときに自身のユーザー名に ","role":"admin を追加する場合、結果として JSON は次のようになります。

{
  "username":"mallory",
  "role":"admin",
  "password":"Evil123!",
  "role":"default"
}

このシリアライズされた JSON 文字列がその後 NSJSONSerialization.JSONObjectWithData: を使用して NSDictionary オブジェクトにデシリアライズされた場合はこのようになります。

NSError *error;
NSDictionary *jsonData = [NSJSONSerialization JSONObjectWithData:[jsonString dataUsingEncoding:NSUTF8StringEncoding] options:NSJSONReadingAllowFragments error:&error];

NSDictionary オブジェクト内で username、password、および role キーの結果として得られる値はそれぞれ mallory、Evil123!、および admin になります。デシリアライズされた JSON 値が有効かについてこれ以上検証しないと、アプリケーションは誤ってユーザー mallory に「admin」権限を割り当てます。

次の場合に JSON Ｉnjection が発生します。

1.信頼できないソースからデータがプログラムに入力された場合。


2.データが JSON ストリームに書き込まれた場合。

アプリケーションは、通常、JSON を使用してデータを保存したりメッセージを送信したりします。データの保存に使用される場合、JSON はキャッシュ保存されたデータのように扱われ、重要な情報が含まれる場合があります。メッセージの送信に使用される場合、JSON は多くの場合 RESTful サービスと一緒に使用され、認証情報のような機密情報の送信に使用される可能性があります。

アプリケーションが未検証の入力から JSON を構築すると、JSON ドキュメントとメッセージのセマンティクスは変更される可能性があります。深刻でないとしても、攻撃者が余分な要素を挿入し、JSON ドキュメントまたはリクエストを解析中に、アプリケーションに例外をスローさせる可能性があります。深刻なケース (JSON Injection が伴う場合など) としては、攻撃者が、JSON ドキュメントまたはリクエスト内に、ビジネス上不可欠な値の予測可能な操作を許可する余分な要素を挿入することがあります。また、JSON Injection が Cross-Site Scripting や Dynamic Code Evaluation を引き起こす場合があります。

例: 次の Python コードは、URL から取得された、信頼できない値で json ファイルを更新します。

import json
import requests
from urllib.parse import urlparse
from urllib.parse import parse_qs

url = 'https://www.example.com/some_path?name=some_value'
parsed_url = urlparse(url)
untrusted_values = parse_qs(parsed_url.query)['name'][0]

with open('data.json', 'r') as json_File:    
    data = json.load(json_File)

    data['name']= untrusted_values
    
with open('data.json', 'w') as json_File:
    json.dump(data, json_File)

...

name 内の信頼できないデータに対して、JSON 関連の特殊文字をエスケープするための検証がされなくなります。これにより、ユーザーが JSON キーを随意に挿入できるようになり、シリアライズされた JSON の構造を変更する可能性があります。この例では、権限を与えられていないユーザー mallory が URL の名前パラメータに ","role":"admin を追加する場合、JSON は次のようになります。

{
"role":"user",
"username":"mallory",
"role":"admin"
}

これで、JSON ファイルは悪意のあるデータで改ざんされ、ユーザーは "user" ではなく "admin" の特権付きアクセス権を使用できるようになりました

次の場合に JSO Injection が発生します。

1.信頼できないソースからデータがプログラムに入り込んだ場合。


2.データが JSON ストリームに書き込まれた場合。

アプリケーションは、通常、JSON を使用してデータを保存したりメッセージを送信したりします。データの保存に使用される場合、JSON はキャッシュ保存されたデータのように扱われ、重要な情報が含まれる場合があります。メッセージの送信に使用される場合、JSON は多くの場合 RESTful サービスと一緒に使用され、認証情報のような機密情報の送信に使用される可能性があります。

アプリケーションが検証されていない入力から JSON を構成する場合、JSON 文書およびメッセージのセマンティクスが改変される場合があります。比較的良性の場合、攻撃者は、JSON 文書またはリクエストをパース中にアプリケーションに例外をスローさせる、余分な要素を挿入できるようになることがあります。JSON Injection を含むなど、より深刻な場合、攻撃者は、JSON 文書またはリクエスト内でビジネスに不可欠な値の予測可能な操作を許可する、余分な要素を挿入できるようになることがあります。また、JSON Injection により、Cross-Site Scripting や Dynamic Code Evaluation が引き起こされる場合もあります。

次の場合に JSO Injection が発生します。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。


2. データが JSON ストリームに書き込まれた場合。

アプリケーションは、通常、JSON を使用してデータを保存したりメッセージを送信したりします。データの保存に使用される場合、JSON はキャッシュ保存されたデータのように扱われ、重要な情報が含まれる場合があります。メッセージの送信に使用される場合、JSON は多くの場合 RESTful サービスと一緒に使用され、認証情報のような機密情報の送信に使用される可能性があります。

アプリケーションが検証されていない入力から JSON を構成する場合、JSON 文書およびメッセージのセマンティクスが改変される場合があります。比較的良性の場合、攻撃者は、JSON 文書またはリクエストをパース中にアプリケーションに例外をスローさせる、余分な要素を挿入できるようになることがあります。JSON Injection を含むなど、より深刻な場合、攻撃者は、JSON 文書またはリクエスト内でビジネスに不可欠な値の予測可能な操作を許可する、余分な要素を挿入できるようになることがあります。また、JSON Injection により、Cross-Site Scripting や Dynamic Code Evaluation が引き起こされる場合もあります。

例 1: 次の Swift コードは、ユーザー制御が可能なフィールド usernameField および passwordField から JSON に、権限を与えられていないユーザー (「default」ロールのユーザーです。これに対し権限が付与されたユーザーのロールは「admin」です) のユーザー アカウントの認証情報をシリアライズします。

...
let jsonString : String = "{\"username\":\"\(usernameField.text)\",\"password\":\"\(passwordField.text)\",\"role\":\"default\"}"

ただし、JSON シリアライゼーションが文字列補間を使用して実行されるため、usernameField および passwordField 内の信頼できないデータに対して、JSON 関連の特殊文字をエスケープするための検証がされなくなります。これにより、ユーザーが、シリアライズされた JSON の構造を変更する可能性がある JSON キーを随意に挿入できるようになります。この例では、権限を与えられていないユーザー mallory (パスワード Evil123!) がユーザー名を usernameField フィールドに入力するときに自身のユーザー名に ","role":"admin を追加する場合、結果として JSON は次のようになります。

{
  "username":"mallory",
  "role":"admin",
  "password":"Evil123!",
  "role":"default"
}

このシリアライズされた JSON 文字列がその後 NSJSONSerialization.JSONObjectWithData: を使用して NSDictionary オブジェクトにデシリアライズされた場合はこのようになります。

var error: NSError?
var jsonData : NSDictionary = NSJSONSerialization.JSONObjectWithData(jsonString.dataUsingEncoding(NSUTF8StringEncoding), options: NSJSONReadingOptions.MutableContainers, error: &error) as NSDictionary

NSDictionary オブジェクト内で username、password、および role キーの結果として得られる値はそれぞれ mallory、Evil123!、および admin になります。デシリアライズされた JSON 値が有効かについてこれ以上検証しないと、アプリケーションは誤ってユーザー mallory に「admin」権限を割り当てます。

次の場合に LDAP Injection エラーが発生します。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。

この場合、データのソースが信頼できると Fortify Static Code Analyzer は判断できません。

2. データが LDAP フィルタの動的な構築に使用された場合。
例 1: 次のコードは、指定の上司にレポートする全従業員のレコードを取得する LDAP クエリを動的に構築し、実行します。この上司の名前は HTTP リクエストから読み取られるため、信頼することはできません。

...
DirectorySearcher src =
           new DirectorySearcher("(manager=" + managerName.Text + ")");
src.SearchRoot = de;
src.SearchScope = SearchScope.Subtree;

foreach(SearchResult res in src.FindAll()) {
  ...
}

John Smith という上司にレポートする従業員を検索するような通常の状況では、このコードが実行するフィルタは次のようになります。

(manager=Smith, John)

ただし、フィルタは定数ベースのクエリ文字列とユーザー入力の文字列を連結して動的に構築されるため、managerName に LDAP メタ文字が含まれない場合のみクエリは正しく動作します。攻撃者が managerName に文字列「Hacker, Wiley)(|(objectclass=*)」を入力すると、クエリは次のようになります。

(manager=Hacker, Wiley)(|(objectclass=*))

クエリが実行されるときの許可に応じて、|(objectclass=*) 条件の追加により、ディレクトリにあるすべてのエントリに対してフィルタが一致することになり、攻撃者はユーザーのプール全体に関する情報を取得できるようになります。LDAP クエリが実行されるときの許可によって、攻撃の範囲は限定される場合がありますが、攻撃者がクエリのコマンド構造を制御できる場合、この問題を利用する攻撃により少なくとも LDAP クエリを実行するユーザーがアクセスできるすべてのレコードが影響を受ける場合があります。

次の場合に LDAP Injection エラーが発生します。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。

2. データが LDAP フィルタの動的な構築に使用された場合。
例 1: 次のコードは、指定の上司にレポートする全従業員のレコードを取得する LDAP クエリを動的に構築し、実行します。この上司の名前はネットワークソケットから読み取られるため、信頼することはできません。

fgets(manager, sizeof(manager), socket);

snprintf(filter, sizeof(filter, "(manager=%s)", manager);

if ( ( rc = ldap_search_ext_s( ld, FIND_DN, LDAP_SCOPE_BASE,
       filter, NULL, 0, NULL, NULL, LDAP_NO_LIMIT,
       LDAP_NO_LIMIT, &result ) ) == LDAP_SUCCESS ) {
  ...
}

John Smith という上司にレポートする従業員を検索するような通常の状況では、このコードが実行するフィルタは次のようになります。

(manager=Smith, John)

ただし、フィルタは定数ベースのクエリ文字列とユーザー入力の文字列を連結して動的に構築されるため、manager に LDAP メタ文字が含まれない場合のみクエリは正しく動作します。攻撃者が manager に文字列「Hacker, Wiley)(|(objectclass=*)」を入力すると、クエリは次のようになります。

(manager=Hacker, Wiley)(|(objectclass=*))

クエリが実行されるときの許可に応じて、|(objectclass=*) 条件の追加により、ディレクトリにあるすべてのエントリに対してフィルタが一致することになり、攻撃者はユーザーのプール全体に関する情報を取得できるようになります。LDAP クエリが実行されるときの許可によって、攻撃の範囲は限定される場合がありますが、攻撃者がクエリのコマンド構造を制御できる場合、この問題を利用する攻撃により少なくとも LDAP クエリを実行するユーザーがアクセスできるすべてのレコードが影響を受ける場合があります。

次の場合に LDAP Injection エラーが発生します。
1.信頼できないソースからデータがプログラムに入り込んだ場合。

2.データが LDAP フィルタの動的な構築に使用された場合。
例 1: 次のコードは、指定の上司にレポートする全従業員のレコードを取得する LDAP クエリを動的に構築し、実行します。この上司の名前は HTTP リクエストから読み取られるため、信頼することはできません。

...
$managerName = $_POST["managerName"]];

//retrieve all of the employees who report to a manager

$filter = "(manager=" . $managerName . ")";

$result = ldap_search($ds, "ou=People,dc=example,dc=com", $filter);
...

John Smith という上司にレポートする従業員を検索するような通常の状況では、このコードが実行するフィルタは次のようになります。

(manager=Smith, John)

ただし、フィルタは定数ベースのクエリ文字列とユーザー入力の文字列を連結して動的に構築されるため、managerName に LDAP メタ文字が含まれない場合のみクエリは正しく動作します。攻撃者が managerName に文字列「Hacker, Wiley)(|(objectclass=*)」を入力すると、クエリは次のようになります。

(manager=Hacker, Wiley)(|(objectclass=*))

クエリが実行されるときの許可に応じて、|(objectclass=*) 条件の追加により、ディレクトリにあるすべてのエントリに対してフィルタが一致することになり、攻撃者はユーザーのプール全体に関する情報を取得できるようになります。LDAP クエリが実行されるときの許可によって、攻撃の範囲は限定される場合がありますが、攻撃者がクエリのコマンド構造を制御できる場合、この問題を利用する攻撃により少なくとも LDAP クエリを実行するユーザーがアクセスできるすべてのレコードが影響を受ける場合があります。