開発者ツール · JSON フォーマッタおよびバリデータ
JSON の重複キー: RFC 8259 で許可される内容とパーサーの機能
· 背景
json 規格 検証
JSON の文法では同じキーを 2 回許可しており、仕様では名前が一意であるべきであるとだけ規定されており、どの値が優先されるかについてはパーサーの意見が一致していません。この投稿では、それが正確さとセキュリティにとって重要である理由を説明します。
サーバーはどの「ロール」を読み取りましたか?
`{"role":"viewer","role":"editor"}` を考えてみましょう。どちらのメンバーも文法的に完全であるため、ToolAcre は有効な JSON を報告します。テキストが `JSON.parse` に達すると、結果のオブジェクトには、値が `"editor"` である `role` プロパティが 1 つ含まれます。以前のメンバーは非表示履歴として保持されません。したがって、構文チェックが成功しても、オブジェクト名が複数回出現したかどうかについては何も答えられません。
書式設定により、損失が発生した後にのみ損失が表示されます。出力には、選択したレイアウトに `{"role":"editor"}` が含まれます。シリアル化では元のメンバー シーケンスではなく、解析されたオブジェクトを受け取るため、破棄された `viewer` メンバーを再現できません。名前の繰り返しがレビューにとって重要な場合は、正規化された結果に依存するのではなく、[フォーマット]を押す前にソース テキストを保存して検査してください。
文法では許可されていますが、仕様では禁止されています
RFC 8259 では、オブジェクト内の名前は一意である必要があると述べています。これは、一意性を基本的なオブジェクト文法の一部にすることなく、相互運用可能な出力を促進する「はず」です。繰り返される名前は、正しいカンマ区切りの位置にある有効な文字列、コロン、および値で構成されます。したがって、アプリケーション ポリシーがドキュメントを拒否しても、文法バリデータはドキュメントを受け入れることができます。
多くのエラーは必須の構文エラーであるため、この区別は見落とされがちです。コロンや末尾のコンマが欠落していると、JSON オブジェクトをまったく形成できません。重複は異なります。パーサーがすべてのトークンを認識した後、相互運用性の質問を作成します。 ToolAcre は意図的に構文で停止し、重複名のルールを追加しないため、その Valid 結果が一意性の保証として読み取られてはなりません。
JSON.parse と ToolAcre の機能
`JSON.parse` は、オブジェクト名が繰り返される場合に、後の出現を使用します。 ToolAcre はフォーマット前に解析するため、その動作を継承します。 `{"limit":10,"limit":25,"unit":"items"}` の場合、検証は成功し、解析された制限は 25 で、フォーマットされた出力には 1 つの `limit` が含まれます。オプションのキーの並べ替えでは、存続するプロパティの位置を変更できますが、上書きされたプロパティを公開することはできません。
その結果をすべてのパーサーまたは構成に一般化しないでください。一部のシステムは重複を拒否でき、他の処理スタックは別のポリシーを適用したり、オブジェクトを構築する前にトークンを検査したりする場合があります。システム間での安全なステートメントは限定的です。名前の繰り返しは確実に相互運用できません。区別が重要な場合は、言語全体の要求に依存するのではなく、各境界で使用される実際のパーサー モードを確認してください。
パーサーの不一致がリスクとなる場合
重複がセキュリティ上の問題になるのは、コンポーネントが同じテキストを異なる方法で解釈する具体的なマルチステージ パスの場合のみです。たとえば、リクエスト フィルターは、アプリケーションが別の発生を消費している間に 1 つの発生を検査する場合があります。それが起こるかどうかは、正確なパーサー、オプション、転送動作、およびフィールドの使用によって決まります。構文が重複しているだけでは、悪用可能なバイパスであるとは証明できません。
防御可能な制御は、信頼境界で 1 つのポリシーを確立し、実際のスタックをテストすることです。あいまいさが許容できない場合は、非可逆オブジェクトを構築する前に重複した名前を拒否するか、すべてのコンポーネントが同じ解析済みの表現を確実に受け取るようにします。 ToolAcre は、独自の最後に有利なフォーマット動作を実証できますが、ブラウザー ツールの一部ではないゲートウェイ、フレームワーク、またはサービスを監査することはできません。
作業例: キーが繰り返されるドキュメント
`{"theme":"light","prefs":{"density":"roomy","density":"compact"},"theme":"dark"}` を貼り付けます。すべてのメンバーが構文的に有効であるため、ToolAcre はテキストを受け入れます。解析すると、ルート テーマは `dark` として残り、ネストされた密度は `compact` として残ります。書式設定により各名前のコピーが 1 つ出力されるため、以前の両方の値が表示されたドキュメントから消えます。
この例は、フォーマットされた結果の検索が遅すぎる理由も示しています。重複検出では、元のトークン ストリームを読み取る際に、オブジェクトのすべての深さでメンバー名を監視する必要があります。配列には重複名のルールは必要ありませんが、別のアプリケーション ルールでは繰り返しの要素値が考慮される場合があります。ソースを変更しないで、それに対して重複認識パーサーまたはリンターを実行し、ポリシーが警告か拒否かを決定します。
意図的に重複を検出する
ソース JSON での重複名の検出を明示的に約束するツールを使用します。適切なアプローチには、繰り返しで失敗するパーサー モード、開いている各オブジェクトの名前を追跡するストリーミング トークン ハンドラー、または文書化された重複キー ルールを使用したリンターが含まれます。ネストされたオブジェクトとエスケープ名を確認します。`"name"` と `"name"` は、ソースのスペルが異なっていても、同じメンバー名にデコードされます。
JSON 通常の解析によって以前の出現が破棄されると、スキーマは代替にはなりません。スキーマ検証ツールは通常、構築された値を受け取り、重複したトークン履歴ではなく 1 つのプロパティを参照します。解析前または解析中に一意性チェックを実行し、明確な値にスキーマ チェックを適用します。 ToolAcre は重複検出もスキーマ検証も実行しないため、どちらも別の専用の手順が必要です。
これでカバーされない内容
繰り返されるオブジェクト名は、レコード全体で繰り返される値と同じではありません。 `[ {"id":7}, {"id":7} ]` には 2 つの個別のオブジェクトが含まれており、それぞれに 1 つの `id` が含まれています。重複した識別子の検出にはデータセット ルールがあります。同様に、同じ文字列を持つ 2 つの配列要素は、アプリケーション規約で配列がセットを表すと規定されていない限り、意図的に 2 つの位置に残ります。
この記事は、広範な言語エコシステムに対する普遍的な先着順、後着順、または拒否ポリシーを主張するものではありません。これは、ToolAcre の観察可能な `JSON.parse` 動作を記録し、別のコンポーネントを直接チェックする必要がある理由を説明します。また、複製だけから悪用可能性を判断することもできません。セキュリティへの影響には、異なる解釈が関連する承認、ルーティング、または検証の境界を越えているという証拠が必要です。
要点: 有効な JSON は常に明確であるとは限りません JSON
ToolAcre Valid の結果は、トークン シーケンスが厳密 JSON であることを意味します。すべてのオブジェクト名が一意であるという意味ではありません。 `JSON.parse` は、繰り返される名前の最後の値を保持し、フォーマットによってその生き残った値のみがシリアル化されます。以前に発生したものは消去されるため、フォーマットされた出力は、元のソースに重複が含まれているかどうかを判断するための証拠としては不適切です。
一意性が重要な場合は、通常の解析や書式設定の前に、重複認識ツールを使用して元のテキストを検査します。その後、結果として得られる明確な値にスキーマとドメインの検証を適用します。セキュリティを確認するには、不一致を仮定するのではなく、実際のリクエスト パスとパーサー設定を追跡します。実際のルールは単純です。構文の受け入れ、重複名のポリシー、および下流の意味は、別個の証拠を使用して別個にチェックされます。