Ochrona XSS w FastAPI

Biorąc pod uwagę, że FastAPI często stosuje się z frame-workami jak NextJS, gdzie nawet sama komunikacja do FastAPI nie idzie bezpośrednio od przeglądarki tylko przez serwerowe komponentny NextJS-a, czy w takim wypadku FastAPI też powinno walidować input który dostaje i potem zwraca (pod kątem XSS), czy już przesada i powinno się to zostawić Next-owi?

B.Eng napisał(a):

Biorąc pod uwagę, że FastAPI często stosuje się z frame-workami jak NextJS, gdzie nawet sama komunikacja do FastAPI nie idzie bezpośrednio od przeglądarki tylko przez serwerowe komponentny NextJS-a, czy w takim wypadku FastAPI też powinno walidować input który dostaje i potem zwraca (pod kątem XSS), czy już przesada i powinno się to zostawić Next-owi?

XSS właściwie można ogarnąć stosując odpowiednie generowanie widoku.

Jeśli zrobisz coś takiego, ze chcesz wyświetlić html, np. taki: return `<b>${userName}</b>`;, i wsadzisz to do miejsca które się spodziewa HTML'a, to się wystawiasz na atak, bo w tym inpucie mogą być znaki specjalne.

Ale jeśli stosujesz odpowiednie narzędzie do widoku, np. JSX, to będziesz bezpieczny jak zrobisz to tak:

function Component() {
  return <b>
    {userName}
  </b>;
}

Wystarczy że nie połączysz plaintextu z htmlem bez odpowiedniego enkodowania.

1. Zasada "Defense in Depth"
   Bezpieczeństwo nie powinno opierać się na jednej warstwie. Jeśli z jakiegoś powodu w NextJS zostanie użyte dangerouslySetInnerHTML albo dane z API trafią do innego systemu (np. panelu admina w czystym JS, generatora PDF-ów czy maili), to FastAPI staje się źródłem ataku.
2. API jako "Single Source of Truth"
   Twoje FastAPI to serce systemu. Dziś komunikuje się z nim tylko NextJS, ale za pół roku możesz dołożyć aplikację mobilną, zewnętrznego bota albo publiczne API dla partnerów. Jeśli zostawisz walidację Next-owi, będziesz musiał ją replikować w każdym nowym kliencie.
3. XSS to nie wszystko
   Pamiętaj, że walidacja w FastAPI (np. przez Pydantic) chroni Cię nie tylko przed XSS, ale też przed SQL Injection czy Mass Assignment. Nawet jeśli NextJS przesyła dane serwer-serwer, to wciąż są to dane pochodzące od użytkownika końcowego, które mogą być zmanipulowane.

Jak to robic z głową w FastAPI?
Zamiast ręcznie czyścić każdy string, warto użyć Pydantica do walidacji typów i długości, a do samej sanityzacji HTML (jeśli musisz go przyjmować) biblioteki typu bleach lub nh3.

Podsumowując: Backend powinien być jak twierdza. Nie obchodzi go, czy strażnik przed bramą (NextJS) sprawdził paszport – on i tak sprawdza go jeszcze raz u siebie.

Kupony Janusza napisał(a):

1. Zasada "Defense in Depth"
   Bezpieczeństwo nie powinno opierać się na jednej warstwie. Jeśli z jakiegoś powodu w NextJS zostanie użyte dangerouslySetInnerHTML albo dane z API trafią do innego systemu (np. panelu admina w czystym JS, generatora PDF-ów czy maili), to FastAPI staje się źródłem ataku.
2. API jako "Single Source of Truth"
   Twoje FastAPI to serce systemu. Dziś komunikuje się z nim tylko NextJS, ale za pół roku możesz dołożyć aplikację mobilną, zewnętrznego bota albo publiczne API dla partnerów. Jeśli zostawisz walidację Next-owi, będziesz musiał ją replikować w każdym nowym kliencie.

To może zadziałać tylko jesli Twoje dane nie będą zawierać znaków które wyglądają jak HTML. Ale gdybyś chciał np. wyświetlić plaintekst który zawiera tekst "Foo <b> Bar", to ciekawe jakbyś to zrobił? Musiałbyś go zaenkodować, nie mógłyś po prostu usunąć znaczników. A skoro tak, to chcąc to zrobić "raz w twierdzy", tak że klienci nie muszą tego duplikować, to klienci musieliby dostać HTML od "twierdzy" i nie enckodować HTML'a samemu, co moim zdaniem jest jeszcze większym problemem.

Kupony Janusza napisał(a):

1. XSS to nie wszystko
   Pamiętaj, że walidacja w FastAPI (np. przez Pydantic) chroni Cię nie tylko przed XSS, ale też przed SQL Injection czy Mass Assignment. Nawet jeśli NextJS przesyła dane serwer-serwer, to wciąż są to dane pochodzące od użytkownika końcowego, które mogą być zmanipulowane.

Jak to robic z głową w FastAPI?
Zamiast ręcznie czyścić każdy string, warto użyć Pydantica do walidacji typów i długości, a do samej sanityzacji HTML (jeśli musisz go przyjmować) biblioteki typu bleach lub nh3.

Podsumowując: Backend powinien być jak twierdza. Nie obchodzi go, czy strażnik przed bramą (NextJS) sprawdził paszport – on i tak sprawdza go jeszcze raz u siebie.

Tylko że nie da się za bardzo machnąć czarodziejską różdżką i sprawic że dane staną się "bezpieczne". Każda dana ma sens w konkretnym kontekście, input który jest niebezpieczny w sql jest bezpieczny w html i odwrotnie. Poza tym, generowanie widoku to w zasadzie jest jedyne miejsce gdzie taki XSS się może zdarzyć. Nie ma sensu go "naprawiać" wcześniej. I tak, takie dane ze "złośliwym inputem" mogą pójść, dalej, ale pójdą do miejsc które też umieją sobie radzić z inputem niewiadomego pochodzenia.

Moim zdaniem wszelka "ochrona" powinna się dziać w miejscu które jest narażone na atak, w przypadku XSS jest to budowanie widoku. W przypadku SQL jest to klejenie queriesów. Tam powinno być to ogarnięte, a nie wcześniej. Nie mówiąc już o tym że różne bazy danych mają różne dialekty, więc dobrze żeby to co enkoduje SQL wiedziało z jakim dialektem gada; coś co jest "wcześniej", np. domena w core aplikacji, żeby poprawnie się przed tym ochronić musiałaby znać ten dialek najpenwiej; przez co łączymy concerns bazy z domeną - słaby pomysł gdyby mnie ktoś spytał.