Zapobiegaj wstrzykiwaniu SQL w Go Postgresql

Question

Przeszukałem forum postgresql injection w Go i znalazłem kilka przydatnych informacji w SQL injection jak poniżej:

Jak wykonać wyszukiwanie IN w SQL za pomocą Golanga?

Jak mogę zapobiec atakom typu SQL injection w Go, używając „database / sql”?

ale nadal potrzebuję porady, ponieważ mój kod w Go używa innego rodzaju kodu i innych zastosowań. niektóre przypadki / pytania, dla których potrzebuję porady, są takie

1. INSERT INTO a (a1,a2,a3) VALUES (%d,%d,%s)Wiem, że używanie zapętlenia zapytań do wielokrotnego wstawiania, jak przy użyciu fmt.Sprintf, jest złe. więc czy jest jakieś rozwiązanie dla tego zapytania pętli dla wstawiania? Dawny:INSERT INTO a (a1,a2,a3) VALUES (%d,%d,%s),(%d,%d,%s),(%d,%d,%s)
2. Czy używanie fmt.Sprintf do generowania zapytania jest bezpieczne, jeśli parametr używa %dzamiast %s?
3. Używanie instrukcji Prepare i Query jest bezpieczne, ale co, jeśli używam funkcji Select (używając $1,$2) i funkcja NamedQuery (przy użyciu struktury o nazwie). Np .: Select * from a where text = $1-> Czy używanie tego jest $1bezpieczne? i Ex: Select * from a where text = :text-> czy to jest bezpieczne w funkcji NamedQuery?

Uprzejmie potrzebuję twojej rady. Dziękuję Ci!

Answer 1

Po pierwsze, zazwyczaj wolisz używać symboli zastępczych db? 1 USD itp.

1. Tak, używanie fmt.Sprintf z parametrami całkowitymi do budowania SQL jest bezpieczne, chociaż warto tego unikać, jeśli możesz, ale Twoim trzecim parametrem jest% s - unikaj tego i używaj?
2. Tak, używanie fmt.Sprintf z parametrami całkowitymi jest bezpieczne, ale% s lub% v jest znacznie bardziej ryzykowne i unikałbym tego, nie mogę pomyśleć, dlaczego miałbyś go potrzebować.
3. Użyj tutaj symboli zastępczych, więc tak, jest to bezpieczne.

Główne zasady:

• Używaj domyślnie symboli zastępczych, rzadko używaj% d (na przykład w zapytaniu IN)
• Analizuj parametry na typy takie jak liczba całkowita przed jakąkolwiek walidacją lub użyciem
• Unikaj łączenia ciągów, jeśli możesz, i bądź szczególnie ostrożny w przypadku parametrów ciągów
• Zawsze twardo koduj takie rzeczy, jak nazwy kolumn i tabel, nigdy nie generuj ich na podstawie danych wejściowych użytkownika (np.? Sort = mystringcolname)
• Zawsze sprawdzaj, czy otrzymane parametry są tylko autoryzowanymi dla tego użytkownika