개발자 도구 · JSON 포맷터 및 유효성 검사기
JSON의 중복 키: RFC 8259이 허용하는 것과 파서가 수행하는 것
· 배경
JSON 표준 검증
JSON의 문법은 동일한 키를 두 번 허용하고 사양에서는 이름이 '고유해야 한다'고만 말하고 파서는 어떤 값이 우선하는지에 대해 동의하지 않습니다. 이 게시물에서는 이것이 정확성과 보안에 중요한 이유를 설명합니다.
서버가 어떤 '역할'을 읽었습니까?
`{"role":"viewer","role":"editor"}`을 고려하세요. 두 멤버 모두 문법적으로 완전하므로 ToolAcre은 유효한 JSON을(를) 보고합니다. 텍스트가 `JSON.parse`에 도달하면 결과 개체에는 값이 `"editor"`인 하나의 `role` 속성이 있습니다. 이전 멤버는 숨겨진 이력으로 보관되지 않습니다. 따라서 성공적인 구문 검사는 개체 이름이 두 번 이상 나타나는지 여부에 대해 아무 대답도 하지 않습니다.
형식을 지정하면 손실이 발생한 후에만 손실이 표시됩니다. 출력에는 선택한 레이아웃에 `{"role":"editor"}`이 포함됩니다. 직렬화는 원래 멤버 시퀀스가 아닌 구문 분석된 개체를 받기 때문에 폐기된 `viewer` 멤버를 재현할 수 없습니다. 반복되는 이름이 검토에 중요한 경우 정규화된 결과에 의존하기보다는 형식을 누르기 전에 원본 텍스트를 보존하고 검사하세요.
문법에서는 허용하지만 사양에서는 권장하지 않습니다.
RFC 8259에서는 개체 내의 이름이 고유해야 한다고 말합니다. “해야 한다”는 고유성을 기본 개체 문법의 일부로 만들지 않고도 상호 운용 가능한 출력을 촉진합니다. 반복되는 이름은 여전히 유효한 문자열, 콜론 및 올바른 쉼표로 구분된 위치의 값으로 구성됩니다. 결과적으로 문법 검사기는 문서를 승인할 수 있지만 애플리케이션 정책에서는 이를 거부합니다.
많은 오류는 필수 구문 오류이므로 이러한 구분을 놓치기 쉽습니다. 콜론이나 후행 쉼표가 누락되면 JSON 개체를 전혀 형성할 수 없습니다. 중복은 다릅니다. 파서가 모든 토큰을 인식한 후 상호 운용성 질문을 생성합니다. ToolAcre는 의도적으로 구문에서 멈추고 중복 이름 규칙을 추가하지 않으므로 유효한 결과를 고유성 보장으로 읽어서는 안 됩니다.
JSON.parse 및 ToolAcre의 기능
`JSON.parse`는 개체 이름이 반복될 때 나중에 나타나는 항목을 사용합니다. ToolAcre는 포맷하기 전에 구문 분석하기 때문에 해당 동작을 상속합니다. `{"limit":10,"limit":25,"unit":"items"}`의 경우 유효성 검사가 성공하고 구문 분석된 제한은 25이며 형식이 지정된 출력에는 하나의 `limit`이 포함됩니다. 선택적 키 정렬은 남아 있는 속성의 위치를 변경할 수 있지만 덮어쓴 항목을 노출할 수는 없습니다.
해당 결과를 모든 파서 또는 구성에 일반화하지 마십시오. 일부 시스템은 중복을 거부할 수 있으며 다른 처리 스택은 객체를 구성하기 전에 다른 정책을 적용하거나 토큰을 검사할 수 있습니다. 안전한 교차 시스템 설명은 좁습니다. 반복되는 이름은 안정적으로 상호 운용할 수 없습니다. 언어 전반의 주장에 의존하기보다는 구별이 중요한 경우 각 경계에서 사용되는 실제 파서 모드를 확인하세요.
파서 불일치가 위험이 되는 경우
중복은 구성 요소가 동일한 텍스트를 다르게 해석하는 구체적인 다단계 경로에서만 보안 문제가 됩니다. 예를 들어 요청 필터는 애플리케이션이 다른 항목을 소비하는 동안 하나의 항목을 검사할 수 있습니다. 이러한 일이 발생할 수 있는지 여부는 정확한 파서, 옵션, 전달 동작 및 필드 사용에 따라 다릅니다. 중복된 구문만으로는 악용 가능한 우회가 입증되지 않습니다.
방어 가능한 제어는 신뢰 경계에서 하나의 정책을 설정하고 실제 스택을 테스트하는 것입니다. 모호함이 허용되지 않는 경우 손실이 있는 개체를 생성하기 전에 중복된 이름을 거부하거나 모든 구성 요소가 이미 구문 분석된 동일한 표현을 받도록 보장하세요. ToolAcre는 최종 승리 형식 동작을 보여줄 수 있지만 브라우저 도구의 일부가 아닌 게이트웨이, 프레임워크 또는 서비스를 감사할 수는 없습니다.
작업된 예: 반복되는 키가 있는 문서
`{"theme":"light","prefs":{"density":"roomy","density":"compact"},"theme":"dark"}`을(를) 붙여넣으세요. ToolAcre는 모든 구성원이 구문적으로 유효하기 때문에 텍스트를 허용합니다. 구문 분석에서는 루트 테마를 `dark`로, 중첩 밀도를 `compact`로 유지합니다. 서식을 지정하면 각 이름의 복사본이 하나씩 생성되므로 표시된 문서에서 이전 값이 모두 사라집니다.
이 예는 형식화된 결과 검색이 너무 늦은 이유도 보여줍니다. 중복 감지는 모든 객체 깊이에서 원본 토큰 스트림을 읽는 동안 멤버 이름을 관찰해야 합니다. 배열에는 중복 이름 규칙이 필요하지 않지만 별도의 애플리케이션 규칙은 반복되는 요소 값에 관심을 가질 수 있습니다. 소스를 변경하지 않고 유지하고, 이에 대해 중복 인식 파서 또는 린터를 실행하고, 정책이 경고인지 거부인지 결정합니다.
의도적으로 중복 감지
소스 JSON에서 중복 이름 감지를 명시적으로 약속하는 도구를 사용하십시오. 적합한 접근 방식에는 반복 시 실패하는 파서 모드, 열려 있는 각 객체의 이름을 추적하는 스트리밍 토큰 핸들러 또는 문서화된 중복 키 규칙이 있는 린터가 포함됩니다. 중첩된 개체 및 이스케이프된 이름을 확인합니다. `"name"` 및 `"name"`는 소스 철자가 다르더라도 동일한 멤버 이름으로 디코딩됩니다.
JSON 일반 구문 분석에서 이전 항목을 삭제한 후에는 스키마가 대체되지 않습니다. 스키마 유효성 검사기는 일반적으로 생성된 값을 수신하고 중복 토큰 기록이 아닌 하나의 속성을 확인합니다. 구문 분석 전이나 구문 분석 중에 고유성 검사를 실행한 다음 모호하지 않은 값에 스키마 검사를 적용합니다. ToolAcre는 중복 감지나 스키마 검증을 수행하지 않으므로 둘 다 별도의 목적에 맞게 구축된 단계가 필요합니다.
여기서 다루지 않는 내용
반복되는 개체 이름은 레코드 전체에서 반복되는 값과 동일하지 않습니다. `[ {"id":7}, {"id":7} ]`에는 각각 하나의 `id`이 있는 두 개의 개별 개체가 포함되어 있습니다. 중복 식별자를 감지하면 데이터 세트 규칙이 있습니다. 마찬가지로, 동일한 문자열을 가진 두 개의 배열 요소는 응용 프로그램 계약에서 배열이 집합을 나타낸다고 명시하지 않는 한 두 개의 의도적인 위치로 유지됩니다.
이 기사는 광범위한 언어 생태계에 대한 보편적인 선제적, 최후적 승리 또는 거부 정책을 주장하지 않습니다. ToolAcre의 관찰 가능한 `JSON.parse` 동작을 기록하고 다른 구성 요소를 직접 확인해야 하는 이유를 설명합니다. 또한 복제본만으로는 악용 가능성을 판단하지 않습니다. 보안 영향에는 관련 인증, 라우팅 또는 유효성 검사 경계를 넘나드는 다양한 해석이 있다는 증거가 필요합니다.
요점: 유효한 JSON이 항상 명확한 것은 아닙니다 JSON
ToolAcre 유효한 결과는 토큰 순서가 엄격함을 의미합니다. JSON; 이는 모든 개체 이름이 고유하다는 의미는 아닙니다. `JSON.parse`은 반복되는 이름의 마지막 값을 유지하고 형식 지정은 해당 생존자만 직렬화합니다. 이전 항목이 지워지기 때문에 형식화된 출력은 원본 소스에 중복 항목이 포함되어 있는지 여부를 결정하는 데 적합하지 않습니다.
고유성이 중요한 경우 일반적인 구문 분석이나 서식 지정 전에 중복 인식 도구를 사용하여 원본 텍스트를 검사하세요. 결과로 얻은 명확한 값에 나중에 스키마 및 도메인 유효성 검사를 적용합니다. 보안 검토를 위해 불일치를 가정하는 대신 실제 요청 경로와 파서 설정을 추적합니다. 실제 규칙은 간단합니다. 구문 허용, 중복 이름 정책 및 다운스트림 의미는 별도의 증거를 사용하여 별도의 검사입니다.