Empêcher l'injection SQL dans Go Postgresql

Question

Je recherche autour du forum d'injection postgresql dans Go et j'ai trouvé quelques informations utiles en injection SQL comme ci-dessous:

Comment exécuter une recherche IN dans SQL en utilisant Golang?

Comment puis-je empêcher les attaques par injection SQL dans Go en utilisant "database / sql"?

mais j'ai encore besoin de quelques conseils car mon code dans Go utilise un type de code et des cas d'utilisation différents. certains cas d'utilisation / questions pour lesquels j'ai besoin de conseils sont comme ceci

1. En utilisant la boucle de requête sur plusieurs insertions comme l' INSERT INTO a (a1,a2,a3) VALUES (%d,%d,%s)utilisation de fmt.Sprintf, je sais que l'utilisation de sprinft est mauvaise. alors existe-t-il une solution pour cette requête en boucle pour l'insertion? Ex:INSERT INTO a (a1,a2,a3) VALUES (%d,%d,%s),(%d,%d,%s),(%d,%d,%s)
2. Est-il sûr d'utiliser fmt.Sprintf pour générer une requête si le paramètre utilise à la %dplace de %s?
3. L'utilisation de l'instruction Prepare et Query est sûre, mais que faire si j'utilise la fonction Select (en utilisant $1,$2) et la fonction NamedQuery (en utilisant la structure nommée.) Ex: Select * from a where text = $1-> utilise ce $1coffre-fort? et Ex: Select * from a where text = :text-> est-ce sûr dans la fonction NamedQuery?

Veuillez avoir besoin de vos conseils. Merci!

Answer 1

Tout d'abord, préférez-vous généralement utiliser les espaces réservés db? 1 $ etc.

1. Oui, il est sûr d'utiliser fmt.Sprintf avec des paramètres entiers pour construire SQL, mais cela vaut la peine d'être évité si vous le pouvez, mais votre troisième paramètre est% s - éviter cela et utiliser?
2. Oui, il est sûr d'utiliser fmt.Sprintf avec des paramètres entiers, mais% s ou% v est beaucoup plus risqué et j'éviterais, je ne peux pas penser pourquoi vous en auriez besoin.
3. Utilisez des espaces réservés ici, alors oui, c'est sûr.

Règles générales:

• Utilisez des espaces réservés par défaut, il devrait être rare d'utiliser% d (comme dans votre requête IN par exemple)
• Analyser les paramètres en types comme un entier avant toute validation ou utilisation
• Évitez la concatection de chaînes si vous le pouvez, et méfiez-vous particulièrement des paramètres de chaîne
• Codez toujours en dur des choses comme les noms de colonnes et de tables, ne les générez jamais à partir de l'entrée utilisateur (par exemple? Sort = mystringcolname)
• Vérifiez toujours que les paramètres que vous obtenez sont uniquement ceux autorisés pour cet utilisateur