Hello, On Mon, Apr 22, 2024 at 04:47:55PM +0200, Philippe Strauss via gull wrote: > Le code (pour le framework Flask) d'un de ces support d'autocomplete est:
Je ne connais pas :) Le risque principal avec LIKE c'est que des % peuvent être injectés. C'est surtout dangereux dans du code comme: SELECT COUNT(*) FROM login WHERE (email LIKE ?) AND (password LIKE ?) Ici, il faut utiliser "=" et pas "LIKE" pour éviter une attaque qui permettrait de passer outre l'authentification. Dans le cas présent, deux recommandations: a) j'utiliserais une whitelist style ^[A-Z][a-z][0-9]$ ou une blacklist interdisant % -> ceci devrait limiter le risque sur le LIKE b) consulter le manuel de l'ORM utilisé pour voir comment on associe de manière sûre des variables ici (genus.upper()+'%' à des paramètres positionnels ou nommés, dans mon exemple ci-dessus j'ai utilisé des paramètres positionnels ? -> ceci devrait limiter le risque d'injection SQL En regardant le code, j'ai l'impression qu'il s'agit d'un simple printf où la valeur genus.upper()+'%', est simplement concaténée (traitement de texte SQL). Donc, si genus.upper() contient "%"; TRUNCATE myco.genus; et que l'interface à la BD utilisée supporte des commandes multiples via l'interface utilisée, c'est abusable. Et même sans commandes multiples, c'est probablement abusable quand même dans une certaine mesure (requêtes imbriquées par exemple). Mais peut-être que je me trompe et que l'expression sera non seulement échappée, de manière compatible avec la BD utilisée, mais en plus mise dans une chaîne ... dans ce cas, le seul risque qui reste est le a). Dans des cas de doutes, j'ai tendance à activer le debug sur la BD pour voir les requêtes SQL effectivement traitées, on voit parfois que certains ORM fabriquent des horreurs (en sécurité & performance). _______________________________________________ gull mailing list gull@forum.linux-gull.ch https://forum.linux-gull.ch/mailman/listinfo/gull
