Valider une entrée JSON avec JSON Schema

Version imprimable

06/12/2022, 13h51
Zatoobux

Valider une entrée JSON avec JSON Schema

Bonjour,

Pour un service web implémenté en Delphi (11), est il possible de valider les paramètres JSON via un JSON Schema afin de respecter les règles de sécurités ?

merci,
06/12/2022, 17h52
ShaiLeTroll

En dehors de prendre les quelques TJSONSchema qui traine sur Github, on ne trouve pas grand chose, même plutôt l'inverse, un peu comme l'Expert WSDL SOAP, on trouve plutôt des Expert générant le code mappant le JSON à partir de son Schéma.
06/12/2022, 18h27
Paul TOTH

oh mon dieu !

je me doutais bien que quelqu'un avait du faire ça...quand on bouffe du XML / XDS à longueur de journée, JSON semble doux et apaisant à côté...il fallait donc bien que quelqu'un réimplémente la lourdeur du SOAP dans JSON :aie:
07/12/2022, 09h52
Zatoobux

La vérification des entrées avec un schéma permet de protéger facilement des vulnérabilités mass assignment https://cheatsheetseries.owasp.org/c...eat_Sheet.html

Si on utiliser REST.JON pour la conversion en objet Delphi, les propriétés non définies dans l'objet Delphi sont ignorées.
Par contre, lors d'un test intrusion, il est attendu que le web service renvoie une erreur "bad request". Mais à aucun moment Delphi n'indique que l'entrée ne correspond pas à ce qui est attendu.
(en regardant le code, Delphi parcours les propriétés de l'objet à créer et recherche les paires dans le JSON, donc il ne "voit" pas qu'il y a des propriété en plus).

Nos webservices ne sont pas sensible à cette attaque grâce à une isolation des objets de l'interface par rapport aux objets manipulés dans les services.
Par contre comme ils ne renvoient pas "Bad Request" on se fait insulter lors des tests d'intrusion (erreur critique)

Je ne suis pas très "composant TJSONShema qui trainent sur github" ;). La sécurité est un point critique, je me serais attendu a quelque chose d'intégré à Delphi et que Delphi permette de facilement respecter un maximum de recommandations OWASP.

Citation:

Envoyé par Paul TOTH

oh mon dieu !

je me doutais bien que quelqu'un avait du faire ça...quand on bouffe du XML / XDS à longueur de journée, JSON semble doux et apaisant à côté...il fallait donc bien que quelqu'un réimplémente la lourdeur du SOAP dans JSON :aie:

C'est vrai que sans validation des entrées on évite bcp de lourdeur :roll: !
07/12/2022, 10h07
pprem

Citation:

Envoyé par Paul TOTH

oh mon dieu !

je me doutais bien que quelqu'un avait du faire ça...quand on bouffe du XML / XDS à longueur de journée, JSON semble doux et apaisant à côté...il fallait donc bien que quelqu'un réimplémente la lourdeur du SOAP dans JSON :aie:

à l'occasion d'une journée calme et ensoleillée où tu n'as personne à maudire, jette un oeil aux specs de JSON LD ;)

Citation:

Envoyé par Zatoobux

La vérification des entrées avec un schéma permet de protéger facilement des vulnérabilités mass assignment https://cheatsheetseries.owasp.org/c...eat_Sheet.html

Si on utiliser REST.JON pour la conversion en objet Delphi, les propriétés non définies dans l'objet Delphi sont ignorées.
Par contre, lors d'un test intrusion, il est attendu que le web service renvoie une erreur "bad request". Mais à aucun moment Delphi n'indique que l'entrée ne correspond pas à ce qui est attendu.
(en regardant le code, Delphi parcours les propriétés de l'objet à créer et recherche les paires dans le JSON, donc il ne "voit" pas qu'il y a des propriété en plus).

Nos webservices ne sont pas sensible à cette attaque grâce à une isolation des objets de l'interface par rapport aux objets manipulés dans les services.
Par contre comme ils ne renvoient pas "Bad Request" on se fait insulter lors des tests d'intrusion (erreur critique)

Je ne suis pas très "composant TJSONShema qui trainent sur github" ;). La sécurité est un point critique, je me serais attendu a quelque chose d'intégré à Delphi et que Delphi permette de facilement respecter un maximum de recommandations OWASP.

C'est vrai que sans validation des entrées on évite bcp de lourdeur :roll: !

tu n'as pas besoin que le JSON soit schématisé pour valider les entrées...d'ailleurs Let's Encrypt ajoute délibérément un membre aléatoire dans une réponse JSON pour s'assurer que le client supporte les variations de structures :)

personnellement j'utilise mon unité JSON qui converti un Record en JSON ou alimente un Record d'après une chaîne JSON, le record étant typé, soit je peux lire la valeur, soit j'ai une erreur de type que je peux capturer pour retourner un Bad Request...et ensuite je fais un contrôle de validité des données (comme avec tout ce qui vient du net).

alors en effet, tu peux utiliser un schema pour contraindre les données et t'éviter ce travail...mais appliquer un schema ça implique un moteur de schema, et si je regarde les XDS, c'est une horreur à parser...les outils de l'ANS en Java prennent plusieurs dizaines de secondes pour valider une seule requête...je ne sais pas si c'est aussi lourd en JSON

si tu le fais par code, tu peux très bien utiliser des attributs ou d'autres techniques qui t'évitent de tout coder à chaque fois.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 type TRequest = record [NotNull] id: Cardinal; [NotEmpty] Name: UTF8String; [BeforeNow] Date: TDate; [CountBetween(1, 10)] Items: TArray<TItem>; end;
oui ça veux dire que tu codes cette logique sous Delphi d'un côté, et si l'autre côté est dans un autre langage c'est à lui de coder la chose...mais à la rigueur on peut imaginer un générateur de schéma à partir des attributs Delphi ... et en théorie du pourrais avoir un générateur d'attributs à partir du Schéma... c'est ce que propose Delphi pour SOAP de façon plus ou moins heureuse car tu peux mettre vraiment n'importe quoi dans un WSDL, et le formaliser dans une structure de programmation c'est parfois coton, même à la main :)

07/12/2022, 14h20
Zatoobux

oui pour le contenu de chaque membre pas vraiment de problème.

Par contre je suis étonnée de la remarque à propos Let's Encrypt qui ajoute un membre aléatoire pour d'assurer qu'un changement est supporté. En effet un test d'application avec appScan considère comme une vulnérabilité (mass assignment) du plus haut niveau le support d'un membre aléatoire.

Par contre mes déclarations d'entrée sont basées sur des descendants de TObject. La lecture ce fait avec TJSON.JsonToObject().
07/12/2022, 16h35
Paul TOTH

ACME is designed to be extensible by adding new JSON fields, which should be ignored by clients that do not understand them.

https://community.letsencrypt.org/t/...irectory/33417
07/12/2022, 17h16
Zatoobux
La non conformité obtenu pour ce point peut être justifié auprès du client car nous respectons une partie des préconisations OWASP et CWE (des objets de transfert non lié au code; ça nous semble même le plus important et j'ai l'impression que nous nous rejoignons sur ce point).

Je cherche à ce que mon serveur (pas le client) soit conforme a ce qu'attend appScan pour éviter les discussions pas toujours agréables :aie:
- référentiel CWE (CWE-915 : https://cwe.mitre.org/data/definitions/915.html)
- référentiel OWASP (https://cheatsheetseries.owasp.org/c...eat_Sheet.html)
Les 2 suggèrent une liste de champs autorisés parmi les corrections.

Sommes bon pour rédiger un document justifiant l'absence de risque de notre fonctionnement et le ressortir à chaque test d'intrusion (de plus en plus fréquents) :mrgreen:

je vais conserver le lien vers letsencrypt. Il sera a mettre dans la balance des discussions.

alors justement, voilà comment je traite ce genre de requête
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 procedure processAddUser(const Params: string); type TAddUser = record userid: string; password: string; email: string; end; var request: TAddUser; user: TUser; begin try JSON.fromJSON(request, Params); except BadRequest; Exit; end; if (request.userid = '') or (request.password = '') then begin BadRequest; Exit; end; user := Defaul(TUser); user.userid := request.userid; user.password := request.password; user.email := request.email; userService.add(user); end;
enfin la gestion des exceptions est normalement à un plus haut niveau mais peu importe.

Et dans mon cas, isAdmin est ignoré, car je considère que JSON permet justement plus de souplesse...mais on pourrais imaginer une exception EFieldNotFound qui retournerai une BadRequest