Walidacja danych wejściowych przeciwko wstrzyknięciom

Każda wartość wysłana przez klienta może być złośliwa. Traktowanie wszystkich danych wejściowych jako niezaufanych to sposób myślenia, który zapobiega większości ataków.

Injection występuje, gdy dane użytkownika są traktowane jak kod lub polecenie. Atakujący przemyca instrukcje do zapytania albo powłoki.

Wklejanie danych wejściowych bezpośrednio do SQL to klasyczny błąd. Odpowiednio przygotowana wartość może zmienić zapytanie query i wyświetlić całą tabelę.

Rozwiązaniem jest przekazywanie wartości jako parameters, a nie konkatenowanie ciągów znaków. Sterownik bezpiecznie je wtedy escapuje.

W SQLAlchemy używa się filter_by i wartości powiązanych, dzięki czemu zapytania są domyślnie parametryzowane, a injection staje się znacznie trudniejszy.

Przed użyciem sprawdź, czy dane wejściowe odpowiadają oczekiwaniom. Potwierdź type i zakres, aby ciąg znaków nie pojawił się tam, gdzie powinna być liczba.

Wskazanie kilku akceptowanych wartości jest lepsze niż śledzenie każdej nieprawidłowej. Allowlist odrzuca wszystko, na co wyraźnie nie zezwolono.

Biblioteka schematów, taka jak Marshmallow, sprawdza pola za Ciebie. Zgłasza ValidationError, gdy dane mają nieprawidłowy kształt.

Injection może również trafić do HTML. Autoescapowanie w Jinja2 zamienia tekst użytkownika na bezpieczne znaki, dzięki czemu skrypty nie mogą uruchomić się na stronie.

Oznaczenie treści filtrem safe wyłącza escapowanie. Używaj go tylko dla tekstu, któremu w pełni ufasz, nigdy dla nieprzetworzonych danych użytkownika.

Waliduj dane natychmiast po ich otrzymaniu, zanim dotkną logiki aplikacji. Szybkie zakończenie działania (fast) kodem 400 zapobiega rozprzestrzenianiu się nieprawidłowych danych.

Nauczono się nie ufać danym wejściowym, zapobiegać SQL injection za pomocą zapytań parametryzowanych, walidować dane schematami, stosować allowlisty i escapować dane wyjściowe. To solidna praca nad bezpieczeństwem!