Odpowiedź.

Zapytania parametryzowane pozwalają na przekazywanie wartości do zapytania za pomocą specjalnych parametrów, a nie bezpośrednio przez podstawianie zmiennych. To zwiększa bezpieczeństwo i chroni przed atakami SQL injection, a także przyspiesza wykonywanie powtarzających się zapytań dzięki cachowaniu planu.

Dynamiczny SQL pozwala na budowanie i wykonywanie zapytań w locie (na przykład za pomocą EXEC sp_executesql w MS SQL lub PREPARE/EXECUTE w PostgreSQL). Należy być bardzo ostrożnym: podstawianie wartości bezpośrednio do tekstu zapytania może prowadzić do ataków SQL injection, błędów składniowych i złej wydajności.

Przykład zapytania parametryzowanego (w Pythonie z biblioteką psycopg2):

cursor.execute("SELECT * FROM users WHERE id = %s", (user_id,))

Przykład dynamicznego SQL w PostgreSQL:

EXECUTE format('SELECT * FROM %I WHERE value = %L', tablename, value);

Pytanie z podtekstem.

Pytanie: Dlaczego samo escapowanie cudzysłowów ('), jak robią to niektóre stare aplikacje, nie jest wystarczające, aby zabezpieczyć przed atakami SQL injection?

Odpowiedź:

Escapowanie cudzysłowów nie zabezpieczy przed wszystkimi typami iniekcji, szczególnie gdy atakujący wstawi strukturę zapytania SQL (na przykład "; DROP TABLE users;"). Ponadto, nie obejmuje to wszystkich szczególnych cech różnych typów danych i nie chroni przed omijaniem filtrów przez kodowanie lub znaki specjalne. Zawsze należy używać zapytań parametryzowanych.

---

Historia

W jednym z systemów obliczania wynagrodzeń dynamiczny SQL generował raporty. Z powodu braku wsparcia dla parametryzacji w starej ramowej aplikacji ręcznie sklejaliśmy ciągi. Pewny użytkownik przypadkowo (lub nie do końca) przekazał w polu "nazwisko" fragment SQL — co pozwoliło uzyskać dostęp do cudzych wynagrodzeń.

Historia

Mały sklep internetowy używał dynamicznego SQL do filtrowania produktów bez odpowiedniej walidacji. Przy próbie podania nietypowej wartości użytkownik wywołał błąd parsera SQL, co na chwilę "położyło" wyświetlanie wszystkich produktów.

Historia

W CRM litera “O'Connor” spowodowała błąd w aplikacji, która budowała zapytania SQL poprzez proste dodawanie ciągów. Z powodu nieescapowanej pojedynczej cudzysłowu żadna karta z takim nazwiskiem nie była zapisywana, co zauważono dopiero po roku.