...
Introduction
This function Function is designed to validate data according by processing the received data according to the designated rules and conventions in UDPUsage Engine Cloud Edition. 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 Usage Engine Cloud Edition documentation.
A list of the prescribed considerations is the following:
- 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.
...
- maxLength – The entered value must be a non-negative integer. Validation is performed when the string instance is equal to a length that is less than, or equal to the designated keyword value.
- minLength – The entered value must be a non-negative integer. Validation is performed when the string instance is greater than, or equal to the designated keyword value. When this keyword is omitted, the UDP Usage Engine Cloud Edition service will treat it as being a value with “0” length.
- pattern – The entered value must be a valid string expression. Validation is performed if the expression matches the defined instance.
...
- maxItems – The entered value must be a non-negative integer. Validation is performed when the array size is less than, or equal to the value of the input keyword.
- minItems – The entered value must be a non-negative integer. Validation is performed when the array size is greater than, or equal to the value of the input keyword. When this keyword is omitted, the UDP Usage Engine Cloud Edition service will treat it as being a value with “0” length.
- uniqueItems – The entered value must be a Boolean. Validation will be done if the value is “false”. “True” validation is done only when all of the array instances are unique. When this keyword is omitted, the UDP Usage Engine Cloud Edition service will treat it as having a value of “false”.
- maxCointains – The entered value must be a non-integer. The keyword will have no effect if the “contains” values are not present within the same schema object. Validation is performed, depending on the annotation results of the adjacent “contains” keyword in two ways. Validation will pass if the annotation results is an array with a length that is less or equal to the “maxContains” value. The other validation option is by having the annotation result as a “true” boolean value with an array instance with a length that is less or equal to the “maxContains” value.
- minContains – The entered value must be a non-negative integer. The keyword will have no effect if the “contains” values are not present within the same schema object. Validation is performed, depending on the annotation results of the adjacent “contains” keyword in two ways. Validation will pass if the annotation result is an array with a length that is greater or equal to the “minContains” value. The other validation option is by having the annotation result as a “true” Boolean value with an array instance that is greater or equal to the “minContains” value. When this keyword is omitted, the UDP Usage Engine Cloud Edition service will treat is having the same behavior as a value of “1”. Validation allows a value of “0”, but that is only useful for setting up a range a of occurrences from “0” going up to the value of “maxContains”.
...
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.
...
This section lists the validation requirements for the contents that comprise of string-encoded data. There are specific implementation rules that need to be followed to perform a successful validation. For security purposes, the entered implementations must not perform decode, parse and/or validate the string contents automatically. Each string-encoded document is to be evaluated according to the set standards on a conditional basis. All keywords in this section apply only to string data types and have no effect on other data types. Validation is performed for the following data contents:
...
- “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 behavior 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.
...