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,
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,
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.
Aide via F1 - FAQ - Guide du développeur Delphi devant un problème - Pensez-y !
Attention Troll Méchant !
"Quand un homme a faim, mieux vaut lui apprendre à pêcher que de lui donner un poisson" Confucius
Mieux vaut se taire et paraître idiot, Que l'ouvrir et de le confirmer !
L'ignorance n'excuse pas la médiocrité !
L'expérience, c'est le nom que chacun donne à ses erreurs. (Oscar Wilde)
Il faut avoir le courage de se tromper et d'apprendre de ses erreurs
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
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 !
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.
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
Code : Sélectionner tout - Visualiser dans une fenêtre à part
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 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().
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
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
- 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)
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
enfin la gestion des exceptions est normalement à un plus haut niveau mais peu importe.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
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;
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
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager