Walidacja danych wejściowych i kodowanie danych wyjściowych

Luki typu injection — SQL, poleceń, LDAP, XPath i inne — powstają, gdy niezaufane dane wejściowe są interpretowane jako kod. Walidacja danych wejściowych gwarantuje, że dane odpowiadają oczekiwanym typom, długościom i formatom, zanim zostaną przetworzone, zapisane lub zwrócone.

Walidacja z użyciem allowlisty (białej listy) określa, co jest akceptowalne: tylko znaki alfanumeryczne, tylko liczby całkowite z zakresu 1–100, tylko prawidłowe formaty adresów e-mail. Denylista (czarna lista) próbuje blokować znane nieprawidłowe dane wejściowe i zawsze jest niekompletna. Należy preferować allowlisty.

Walidacja po stronie klienta poprawia wygodę użytkowania, ale nie zapewnia żadnego bezpieczeństwa — atakujący mogą ją łatwo ominąć za pomocą narzędzi deweloperskich przeglądarki lub curl. Zawsze należy przeprowadzać walidację po stronie serwera. Walidacja po stronie klienta jest udogodnieniem, a po stronie serwera — mechanizmem kontroli bezpieczeństwa.

Liczby: sprawdzać typ i zakres. Ciągi znaków: sprawdzać długość i zestaw znaków. Daty: analizować rygorystycznie i sprawdzać zakres. Pliki: sprawdzać rozszerzenie ORAZ sygnaturę magiczną/typ MIME — nigdy nie ufać samemu rozszerzeniu. Adresy URL: analizować i sprawdzać elementy schematu, hosta oraz ścieżki.

Najważniejszą zasadą walidacji danych wejściowych w bazach danych jest zakaz konkatenowania danych użytkownika z kodem SQL. Należy używać zapytań parametryzowanych (instrukcji przygotowanych), w których dane użytkownika są przekazywane jako parametr, a nie wstawiane do ciągu zapytania.

Ten sam ciąg znaków wymaga innego kodowania w zależności od kontekstu. Treść HTML: kodowanie HTML (< > &). Atrybut HTML: kodowanie atrybutu HTML. JavaScript: kodowanie JS. Parametr URL: kodowanie URL (kodowanie procentowe). Użycie niewłaściwego kodowania pozostawia luki, które mogą wykorzystać atakujący.

Nigdy nie należy wstawiać danych użytkownika bezpośrednio do kodu HTML. Należy używać silnika szablonów lub biblioteki, która automatycznie stosuje escaping HTML. W React wyrażenie {value} jest bezpieczne, natomiast dangerouslySetInnerHTML omija escaping. W Django szablony automatycznie stosują escaping, chyba że jawnie użyje się filtra safe.

Podczas wstawiania danych do JavaScriptu (np. do zmiennej zainicjalizowanej danymi użytkownika) kodowanie HTML jest niewystarczające. Należy używać kodowania JSON: JSON.stringify(value). Zapobiega to wydostaniu się danych poza kontekst literału ciągu znaków JS.

Dane dostarczone przez użytkownika, wstawiane do adresów URL, muszą być kodowane procentowo za pomocą encodeURIComponent() (JS) lub urllib.parse.quote() (Python). Niekodowane dane mogą modyfikować strukturę adresu URL, prowadząc do otwartych przekierowań lub przechodzenia poza dozwolony katalog.

CSP zapewnia dodatkową warstwę ochrony przed XSS. Rygorystyczna CSP wykorzystująca wartości nonce uniemożliwia wykonanie skryptu wbudowanego nawet po wstrzyknięciu ładunku XSS, ponieważ przeglądarka odmawia wykonania skryptów bez prawidłowego atrybutu nonce.

DOM XSS występuje, gdy JavaScript odczytuje dane ze źródeł kontrolowanych przez atakującego (location.hash, document.URL, cookie) i zapisuje je do niebezpiecznych miejsc docelowych (innerHTML, document.write, eval). Należy kontrolować wszystkie przepływy danych od interfejsów API przeglądarki do miejsc docelowych DOM za pomocą narzędzi do analizy statycznej.

Walidacja danych wejściowych (allowlisty, sprawdzanie typów, ograniczenia długości) w połączeniu z kodowaniem danych wyjściowych zależnym od kontekstu (HTML, JS, URL, parametryzacja SQL) stanowią podstawową ochronę przed atakami injection i XSS. Oba mechanizmy bez wyjątku należy stosować po stronie serwera.