Introduction
This function is designed to validate data according to by processing the received data according to the designated rules and conventions in UDP. Regarding the JSON file types and objects, they are to be checked according to the official JSON Schema Validation definitions, approved by the IETF Trust. Each JSON schema object is to be independently examined by the built-in engine for validity.
...
For the purpose of maintaining interoperability and according to the official JSON Schema regulations, several considerations are accounted for during validation. All of the listed conditions are implemented by following the official regulations. No exceptions or special cases are made , unless they are explicitly specified in the official UDP documentation.
...
- Validation of String Instances – The null character (\u0000) is considered a valid JSON string.
- Validation of Numeric Instances – The JSON schema will not add any bounds to numbers with arbitrary precision. Such instances can be arbitrarily large and/or can contain long decimal partparts.
- Regular Expressions – Use of keywords that use regular expressions or constrain the value to such an expression should confront to the core JSON Schema specifications.
- Meta-Schemes – The latest JSON Schema dialect meta-schema release specifications are supported.
...
Specific const rules are defined for the following JSON types:
- tuple – – Tuple refers to a set of objects which are ordered together and immutable. They cannot be changed and operate in the same manner as “string” data types. Validation is performed for the whole array of items placed inside the tuple instance.
- oneOf – oneOf validation is used to compare data between items exactly as shown in the current schema configuration.
- nestedObject – Nested – Nested objects are complex structures that includes include a “parent” JSON object that has “child” properties attached to it. Validation is performed on the whole iteration.
- reference – A reference keyword is a valid instance that points to a given location, that is indicated by the referenced value.
...
These format attributes must be of the string data type. They generally validate only a given set of instance types. If the validation type is not part of this set, then the overall validation for the format attribution should succeed during processing. The format attributes can be specified to any instance types type as defined by the current JSON schema data model.
...
- Format-Annotation Vocabulary – The value of this format must be collected as an annotation , if the used implementation supports such a collection. This is done to ensure the validation is done on an application - level , if the schema validation for individual objects is not available. Implementations can still be treated as a “format” in certain situations, as assertions that can attempt to validate the values. In such cases, these implementations are to document their level of support for the validation.
- Format-Assertion Vocabulary – The vocabulary will be declared with “true” value when implementations provide full validation support for all formats. If these implementations cannot validate the full schema, processing will not occur.
...
- “title” and “description” – Both of these vales values must be of the string data type. They are used to decorate a user interface about the data found in them. It is recommended to keep the “title” short, whereas the “description” should carry the explanation for the purpose of the instance.
- “default” – No restrictions are placed on this keyword value. Duplicated entries should be removed , if such are found. The “default” keyword is used to supply a default JSON value to be used with a given schema.
- “deprecated” – This keyword value must be of the boolean data type. If multiple occurrences are applicable to a single instance, the applications will consider the location to be deprecated. If the boolean value is “true”, then the service should refrain from using the given property. A root schema that contains the “deprecated” keyword with a “true” boolean status will indicate that the entire resource may be removed in the future. This keyword will apply to each instance location to which the schema object applies to. If this keyword is omitted, the service will consider it as having the same behaviour behavior as a value of “false”.
- “readOnly” and “writeOnly” – The values that are input for this keyword must be of the Boolean data type. If there are multiple occurrences, then the results will be processed as considering them as “true” statements. If the “readOnly” boolean value is set to “true”, then the service will process the value in accordance with the owning authority. Any external attempts to modify value properties will be ignored or rejected. Instances that are marked with “writeOnly” for the whole document, may produce an error upon retrieval. This keyword can be used to mark sections like password input fields. When these keywords are omitted, then their behavior for a “false” statement will be considered.
- “examples” – The value of this keyword must be an array; no restrictions are placed for the values inside of it. If there are multiple occurrences of this keyword, then the implementation is to provide a flat array of all listed values. This keyword is used to provide sample JSON values that are associated with a particular example. It is recommended that the input values are valid according to the defined schema model. Users can use the “default” value as an additional example.
...
- Regular Expressions – The JSON schema validation is performed on regular expressions. The security implications of this process are that some implementations may include embedding of arbitrary code outside of the JSON schema. This must not be permitted as it can lead to vulnerability exploitation. Attackers can make use of denial-of-service attacks with poorly crafted expressions.
- Content Validation Risks – JSON validation of “contentEncoding” and/or “contentMediaType” are at risk as they can evaluate instance string data in an unsafe way based on misleading data. Potential security issues can be mitigated by performing such processes when e relationship between the schema and the instance is established.
- Media Type Processing – The different media types that are being encoded or processed all have their own security considerations, subject to their own specifications. It is recommended that proper handling is performed.
- Duplicate Names – JSON processing of duplicate names can result in inconsistent behaviour. In this regard improper processing can result in a covert channel. This can be used in penetration testing for a possible intrusion path.
- JSON Name/Value Pairs Ordering – It is possible to encode hidden meaning in the order of the name/value pairs in JSON objects. The reason for this is because there is no concrete definition of how this is done according to the official specifications. To minimise minimize the possibility of security exploitation, standardisation standardization of the order should be considered. When this is done, hashing and the use of digital signatures can be considered.
- JSON Numbering Considerations — JSON exploitation can be done when there is improper handling of the numbering conventions. By specification, there are no restrictions on the number of digits or the precision. Application behaviour can be unpredictable when processing some types of numbers. There is a possibility that an application can crash and potentially lead to exploitation when large numbers of digits are handled improperly.
- Undefined Unicode Characters Use —Unicode characters should be used throughout the JSON schema use. Use The use of defined Unicode characters in notation form can lead to unpredictable processing. In some cases, this can result in application crashing crashes which can lead to vulnerability exploitation.
...