[gull] Requêtes SQL en LIKE ...% avec psycopg3

[Marc SCHAEFER]

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).