Czy front/aplikacja po stronie klienta powinna weryfikować dane z serwera?

Ogólnie chyba nie ma wątpliwości, że serwer powinien sprawdzać/weryfikować dane otrzymane z frontu - bo ich źródło jest niepewne, mogły zostać sfałszowane przez użytkownika itp. Także zasada (z grubsza i ogólna) jest taka, że wstępna weryfikacja danych jest jeszcze po stronie klienta (czy to jest apka desktopowa, web czy np. mobilna), potem to leci na serwer i tam i tak ponownie dane są sprawdzane przed wrzuceniem ich do bazy czy wykonaniem innych czynności. Po prostu - nie ufamy temu, co dostaniemy z frontu/od klienta.

A co w odwrotnej sytuacji? Miałem parę dni temu rozmowę z kumplem i mieliśmy różnicę zdań. Jeden twierdził, że jak coś przyszło z serwera to jest to na 99,99% OK i nie ma co tracić czasu na weryfikację, natomiast drugi że sprawdzić nic nie szkodzi.

Nie będę opisywać naszego konkretnego przypadku, ale wyjaśnię to na 2 przykładach:

1. apka do zarządzania serwisem (coś powiedzmy w stylu CRM). Masz różne rodzaje zgłoszeń: naprawa, montaż, gwarancja, oferta itp. Jest sobie serwisant Mieciu, który tylko zajmuje się naprawami. Jeśli serwer, przesyłając mu listę zadań na dzisiaj, przez pomyłkę prześle także zadanie dot. sporządzenia oferty, to apka kliencka po typie zlecenia może przefiltrować takie coś i nie wyświetlić tego typu zgłoszenia
2. apka dla firm (np. jakiś system ticketowy). Grażynka jest pracownikiem firmy o ID=352, ale serwer miał buga w logice i przesłał jej także zlecenia firm o ID od 200 do 400. Jeśli front wypluje wszystko, co dostanie od serwera, to Grażynka zobaczy także tickety innych firm. Ale w przypadku sprawdzenia danych z serwera, jeśli apka zweryfikuje ID danej firmy to może ukryć dane nie przeznaczone dla tego użytkownika, które trafiły do klienta w ramach błędu.

Zaznaczam - takie sprawdzanie danych na froncie nie ma na celu ochrony przed atakami czy celowym działaniem użytkownika (który np. podmieni sobie w konsoli czy jakimś postmanie nagłówki czy ID zdarzenia/wpisu do bazy), a jedynie ma być taką drugą linią obrony w przypadku, jakby powstał jakiś błąd po stronie serwera, który spowoduje przesłanie danych na front, które nie powinny tam trafić.

Co sądzicie? Które podejście popieracie - pokazywać wszystko co dotarło, czy jeszcze filtrować/sprawdzać na froncie/w apce?

Jeżeli zarówno API jaki i aplikacje klienta są utrzymywane przez ten sam zespół lub są jakoś blisko siebie w jednej firmie to nie robilbym takiej weryfikacji w aplikacji, natomiast jeżeli deweloperzy API nie mają nic wspólnego z deweloperami aplikacji klienta to myślę, że warto rozważyć weryfikację danych.

Ale to jest bardziej kwestia dostępów, czyli Mieciu, jak dostał nieopowidnie zlecenie to nie powinno się mu pokazać ze wzgledu na brak uprawnień.

cerrato napisał(a):

Zaznaczam - takie sprawdzanie danych na froncie nie ma na celu ochrony przed atakami czy celowym działaniem użytkownika (który np. podmieni sobie w konsoli czy jakimś postmanie nagłówki czy ID zdarzenia/wpisu do bazy), a jedynie ma być taką drugą linią obrony w przypadku, jakby powstał jakiś błąd po stronie serwera, który spowoduje przesłanie danych na front, które nie powinny tam trafić.

Co sądzicie? Które podejście popieracie - pokazywać wszystko co dotarło, czy jeszcze filtrować/sprawdzać na froncie/w apce?

Gdybym ja się borykał z takim problemem to rozwiązałbym go inaczej. Jeśli taki bug się przemknął - zacząłbym się zastanawiać: jakim cudem moje testy tego nie wykryły? Zacząłbym szukać dziury w zestawie testów i poprawiłbym je tak, żeby taki błąd znalazły.

cerrato napisał(a):

Jeden twierdził, że jak coś przyszło z serwera to jest to na 99,99% OK i nie ma co tracić czasu na weryfikację, natomiast drugi że sprawdzić nic nie szkodzi.

Zgadzam się połowicznie.

Co do wypowiedzi pierwszego Pana, nie powiedziałbym ze to co przyszło z serwera jest na 99.99% okej (bo bugi i błędy się zdarzają), ale zgadzam się że front mógłby traktować je tak jakby były poprawne. Bo i tak jeśli jakiś błąd jest, to nie front ma je poprawić tylko backend.

Co do wypowiedzi drugiego Pana, to nie brzmi mi jak problem technologiczny Mi to pachnie jak problem ludzki. Myślę że drugi Pan pracował kiedyś w firmie w której zespoły były podzielone na "frontów" i "backendów", które to zespoły się nie lubiły/nie ufały sobie nawzajem (ewentualnie przez strukturę w firmie nie mogli razem pracować). Dlatego przenieśli swój brak zaufania na kod, żeby front podwójnie sprawdzał co "Ci źli backendzi nam wysłali". Jeśli popatrzymy na to w taki sposób, to nic dziwnego że mieli ochotę się zabezpieczyć przed tym (tak samo jak aplikacja zabezpiecza się przed tym że zewnętrzny serwis wyśle coś niepoprawne).

Ja jestem za wyświetlaniem wszystkiego.
Jak jakiś user otrzyma nie swoje dane to powinien to zgłosić i się poprawi. Może zobaczył coś czego nie powinien widzieć, ale przynajmniej bug zostanie od razu wykryty.
Natomiast jeśli front zacznie dodatkowo filtrować dane to trudniej będzie wykryć błędy.

Jedyne co powinien sprawdzać front po otrzymaniu danych z serwera, to czy dane są w prawidłowej formie i czy nie są "wybrakowane" aby aplikacja mogła je prawidłowo przetworzyć. Zawsze backend powinien weryfikować co ma być wysłane na front do danego klienta, dodawanie takiego samego działania po stronie frontu będzie generować niepotrzebny przepływ danych i obciążanie serwera. Dodatkowo jeśli coś już przechodzi z serwera na front, to może to gdzieś zostać złapane podczas przesyłu danych przy słabo zabezpieczonej komunikacji, wtedy filtrowanie na froncie ci nic nie da :)

Jeżeli zarówno API jaki i aplikacje klienta są utrzymywane przez ten sam zespół lub są jakoś blisko siebie w jednej firmie to nie robilbym takiej weryfikacji

OK, niby tak, ale czy to mój człowiek/moja ekipa/ja sam zrobiłem błąd, czy jest on po stronie firmy zewnętrznej - żadna różnica. Efektem jest to, że błędne dane polecą do aplikacji i przed czymś takim chcemy się zabezpieczyć. Oczywiście - nie powinno się tak stać, ale idea błędu jest taka, że się go raczej nie planuje ;)

Jak jakiś user otrzyma nie swoje dane to powinien to zgłosić i się poprawi. Może zobaczył coś czego nie powinien widzieć, ale przynajmniej bug zostanie od razu wykryty.

Ale, zakładając że aplikacja weryfikuje otrzymane ID i stwierdzi, że dostała coś błędnego, to przecież może tych danych nie wyświetlić, ale przesłać do serwera informację, że jakiś błąd/problem został wykryty. Może się to dziać całkowicie w tle, bez powiadamiania klienta o problemie. A przynajmniej unikniemy pokazania danych komuś innemu - zarówno mogłoby to nadwyrężyć zaufanie do aplikacji, jak i w przypadku danych poufnych jakieś kwestie typu RODO itp.

jakim cudem moje testy tego nie wykryły? Zacząłbym szukać dziury w zestawie testów i poprawiłbym je tak, żeby taki błąd znalazły.

OK, jeśli ktoś stosuje testy (oraz robi to z głową, a nie na sztukę - cokolwiek, żeby wyglądało że jest OK i świeciło się na zielono) to tak. ALE po pierwsze - dopiero będziesz wiedział o tym, jak ktoś Ci zgłosi, że widzi zlecenia/tickety, których nie powinien. A zanim do tego dojdzie to nie masz pojęcia co i komu się pokazało. A po drugie - takie coś można też potraktować jako testy - czyli nie wyłapiesz błędu w osobnej procedurze odpalanej w celu sprawdzenia, tylko na bieżąco monitorujesz co się dzieje/czy są problemy.

Ale to jest bardziej kwestia dostępów, czyli Mieciu, jak dostał nieopowidnie zlecenie to nie powinno się mu pokazać ze wzgledu na brak uprawnień.

No ale właśnie o to chodzi - Mieciu nie powinien dostać jakichś danych, ALE z powodu jakiegoś błędu jednak je otrzymał. Dlatego wiem, że tak się stać nie powinno - ale ponieważ coś poszło błędnie z tymi uprawnieniami to jednak dane poleciały na front. I przed czymś takim chcemy się bronić.

Bo i tak jeśli jakiś błąd jest, to nie front ma je poprawić tylko backend.

OK, oczywiście, racja - ale jednak front może doraźnie załatać fakap, zamaskować wyciek i do tego jeszcze zgłosić serwerowi stwierdzoną nieprawidłowość.

Dlatego przenieśli swój brak zaufania na kod, żeby front podwójnie sprawdzał co "Ci źli backendzi nam wysłali"

Ciekawa obserwacja, w sumie - może to wynikać ze złych doświadczeń. Ale akurat ja uważam, że ufać nie powinno się nikomu. Ze sobą samym włącznie. Uważam, że sprawdzać się powinno jak najwięcej rzeczy, niezależnie czy ktoś to pisał, czy ja sam.

Użytkownik może podejrzeć w narzędziach deweloperskich wszystko co przyszło
Zwalkanie na frontend filtrowania czy walidacji to proszenie się o kłopoty i to duże
Gorzej jak ktoś pisze w systemie gdzie nie wie co tak naprawdę jest na frontendzie np. java i Vaadin

Zwalkanie na frontend filtrowania czy walidacji to proszenie się o kłopoty i to duże

Ale żeby była jasność - nie chodzi o to, że baza robi SELECT * FROM... i potem wszystko co jest na serwerze przewala na front, a front/apka ma sobie to filtrować. Chodzi jedynie o to, żeby w razie fakapu/awarii/błędu po stronie serwera takie błędy wyłapać i w miarę możliwości naprawić ich efekty.

Mało popularna opinia ale uważam, że w takim wypadku najlepiej sprawdzają się mechanizmy w stylu Row Security Policy. Bo wtedy własnie możesz zrobić SELECT * FROM i dalej dostaniesz tylko te dane do ktorych masz dostęp.

Czym wiecej front ma logiki biznesowej tym potem go ciężej utrzymywać i optymalizować.

Ja wiem o co chodzi @cerrato. To nie jest po to żeby na froncie napisać drugi backend który robi tą samą logikę. To chodzi o to że jak dostaniesz dane które są oczywiście błędne, np. ujemna data urodzenia, to wtedy to poprawić/zwalidować. A nie po to żeby drugi raz sprawdzać wszystko co się da.

@Riddle Ale na takie pytanie nie da się odpowiedzieć bo frontend to UX, jeżeli ta data jest krytyczna z punktu widzenia flow to można robić walidacje i warunkowe dodatkowe flow biznesowe do poprawiania. I still ta logika nie musi sie dziać na froncie. Bo miejsce nie ma znaczenia. Z drugiej strony, lepiej uzytkownikowi wyświetlić błędne dane niż nic ofc jeżeli ni mowimy tu o błędach autoryzacyjnych.

To chodzi o to że jak dostaniesz dane które są oczywiście błędne, np. ujemna data urodzenia, to wtedy to poprawić/zwalidować. A nie po to żeby drugi raz sprawdzać wszystko co się da

Tak, dokładnie - nie chodzi o przerzucenie logiki biznesowej na front, ale o (jak na drodze) zasadę ograniczonego zaufania - nie wierzyć na 100% że otrzymane dane są prawidłowe. Przy czym akurat nie chodziło mi o sprawdzanie ujemnej daty urodzin (chociaż to też można robić) co raczej o kwestie bezpieczeństwa/ACL/dostępu do danych, do których nie powinno się mieć wglądu. Czyli np. podczas logowania serwer przekazuje w ramach jakiejś sesji (czy jakkolwiek inaczej byłoby to zorganizowane) ID firmy, do której się zalogowałeś (oczywiście - może, a nawet powinno nie być to ID z bazy, ale jakiś hash czy w inny sposób obrobione), a potem przesyłając dane - np. zestawienie ticketów czy akcji do wykonania, przesyła także to ID (czy to będzie ID firmy, czy np. typ zgłoszenia) i jeśli front stwierdzi, że firma o ID 438 dostała dane dla ID 947 to ich nie pokaże, a przy okazji jeszcze powiadomi serwer, że taki problem został stwierdzony.

bo frontend to UX

W moim pytaniu w ogóle nie chodzi o UX, użytkownik nie ma o niczym wiedzieć, pisząc "front" mam na myśli aplikację działającą na urządzeniu użytkownika - w odróżnieniu od części serwerowej/backend'u.

ta logika nie musi sie dziać na froncie. Bo miejsce nie ma znaczenia.

Ma znaczenie o tyle, że właśnie chcemy sprawdzić, czy serwer zwraca prawidłowe rzeczy - więc raczej logiczne jest, że najlepiej jest to robić NIE na serwerze. Chyba, że chcesz wprowadzać jakieś middleware, które będzie sobie siedziało na serwerze, albo gdzieś po drodze (jakieś proxy itp.) i to ten byt miałby prowadzić walidację. Ale wydaje mi się, że prościej jest jednak zrobić sprawdzenie w aplikacji/po stronie frontu.

Z drugiej strony, lepiej uzytkownikowi wyświetlić błędne dane niż nic ofc jeżeli ni mowimy tu o błędach autoryzacyjnych.

No nie do końca, zależy jakie to dane. Wyobraź sobie, jaka by była afera, jakbyś np. miał takie podejście w jakimś systemie, który obsługuje przychodnię czy laboratorium medyczne i nagle wchodzi Jan Nowak, a dostaje wyniki wszystkich Nowaków - bo ktoś na serwerze coś schrzanił i zapytanie zwraca więcej, niż powinno, a po stronie apki nikt tego nie weryfikuje, tylko wypluwa na ekran wszystko tak, jak dostał. OK, w przypadku strony typu demotywatory, jakiegoś bloga czy pudelka to nic się nie stanie, jak pod artykułem o Dodzie dostaniesz wpis o Sanah. Tylko pamiętaj, że wiele aplikacji ma dostęp do o wiele ważniejszych i bardziej poufnych informacji.

Ale na takie pytanie nie da się odpowiedzieć bo frontend to UX

Backend to też UX.

cerrato napisał(a):

ta logika nie musi sie dziać na froncie. Bo miejsce nie ma znaczenia.

Ma znaczenie o tyle, że właśnie chcemy sprawdzić, czy serwer zwraca prawidłowe rzeczy - więc raczej logiczne jest, że najlepiej jest to robić NIE na serwerze. Chyba, że chcesz wprowadzać jakieś middleware, które będzie sobie siedziało na serwerze, albo gdzieś po drodze (jakieś proxy itp.) i to ten byt miałby prowadzić walidację. Ale wydaje mi się, że prościej jest jednak zrobić sprawdzenie w aplikacji/po stronie frontu.

W sumie to się zgadzam z przedmówcą, bo sam to chciałem napisać wcześniej - że nie ważne gdzie ta "warstwa korygująca" będzie.

nie ważne gdzie ta "warstwa korygująca" będzie.

Niby tak, ale po co wprowadzać kolejny byt, jakim będzie to "proxy" od wyłapywania błędów, skoro można to dodać do aplikacji.
Poza tym - takie proxy musi pamiętać/kojarzyć wszystkie połączenia - kto skąd się łączy, jakie ma uprawnienia, z jaką firmą/bazą jesteś powiązany itp. A w przypadku sprawdzania tego po stronie aplikacji - każda apka jest odpalona w ramach jednej instancji i interesuje się tylko sobą samą. Nie obciąża serwera, nie musi praktycznie niczego pamiętać. Jedynie dostaje na początku "swoje ID" i potem porównuje, czy otrzymane dane pasują do wcześniej otrzymanego klucza. Chyba jest to o wiele mniejsza komplikacja, niż dodawanie jakiegoś rozbudowanego mechanizmu monitorujacego cały ruch wychodzący z serwera.

cerrato napisał(a):

Poza tym - takie proxy musi pamiętać/kojarzyć wszystkie połączenia - kto skąd się łączy, jakie ma uprawnienia, z jaką firmą/bazą jesteś powiązany itp. A w przypadku sprawdzania tego po stronie aplikacji - każda apka jest odpalona w ramach jednej instancji i interesuje się tylko sobą samą. Nie obciąża serwera, nie musi praktycznie niczego pamiętać. Jedynie dostaje na początku "swoje ID" i potem porównuje, czy otrzymane dane pasują do wcześniej otrzymanego klucza. Chyba jest to o wiele mniejsza komplikacja, niż dodawanie jakiegoś rozbudowanego mechanizmu monitorujacego cały ruch wychodzący z serwera.

Nie koniecznie, to nie musiałby być osobny proces, to mogłaby być zwykła klasa w backendzie która czyta response.

cerrato napisał(a):

nie ważne gdzie ta "warstwa korygująca" będzie.

Niby tak, ale po co wprowadzać kolejny byt, jakim będzie to "proxy" od wyłapywania błędów, skoro można to dodać do aplikacji.

Ten "byt" jest wprowadzony tak czy tak. A to czy jest na froncie czy backendzie to nie ma większego znaczenia. Żeby tego "bytu" nie było, to ani front ani backend musiałby nie sprawdzać nic; tak jak większość aplikacji działa.

Ma wielkie znaczenie to, gdzie tą walidację wsadzimy: jeśli sprawdzam na poziomie aplikacji u klienta/użytkownika końcowego, to sprawdzam tylko w zakresie danych, które ta aplikacja otrzyma, po prostu - dodajemy w miarę prostą logikę do aplikacji. Za to zrobienie proxy na serwerze wymaga filtrowania całego ruchu, pamiętania która apka z jakimi poświadczeniami działa, kto co powinien móc widzieć, kontrola czy przesyłane dane są na pewno przewidziane dla danej końcówki itp. Moim zdaniem to jest 100x więcej zamieszania.

Po prostu - na froncie dodajemy dodatkowe sprawdzenie po stronie aplikacji u klienta, ale nie jest to nowy byt, tylko poszerzenie czegoś, co mamy. Po stronie serwera - tworzymy nowy byt (jakiś middleware, proxy, API czy jakkolwiek byśmy to nazwali).

Riddle napisał(a):

Backend to też UX.

Chodzi mi o prowadzenie, użytkownika przez procesy biznesowe w sposób jawny i przejrzysty w jakim stanie jest proces.

@cerrato

A jaki problem zrobić middelwara na backendzie (wiekszosc znanych mi frameworkow i bibiliotek do obsługi api daje interfejs do tego) ? Albo zrobić metode do walidacji która woła front ? Tak czy siak jest to dodatkowy element który musisz napisać i możesz popełnic bład.

Po prostu - na froncie dodajemy dodatkowe sprawdzenie po stronie aplikacji u klienta, ale nie jest to nowy byt

Jeżeli ten proces nie wpływa na zmianę flow użytkownika to IMO jest to bez sensu, umieszczać to na froncie. Bo wtedy ten sam kod musisz umieścić w każdym kliencie. A użytkownik nie ma zadnej wartości dodanej z tego.

który obsługuje przychodnię czy laboratorium medyczne i nagle wchodzi Jan Nowak, a dostaje wyniki wszystkich Nowaków

Dlatego napisałęm, oprócz błedów w autoryzacji. Dostanie błednych danych to tego typu błąd.

Dodatkowo jakbys chciał dodawać logikę sprawdzania na froncie to na 99% będziesz musiał ciągać jakieś dodatkowe dane.

front stwierdzi, że firma o ID 438 dostała dane dla ID 947 to ich nie pokaże, a przy okazji jeszcze powiadomi serwer, że taki problem został stwierdzony.

Dobrze wiemy, że takich casów jest mało zazwyczaj potem masz reguły RBAC albo ABAC które np dają dostęp warunkowy do jakiś danych na przykład z tą przychodnią. Masz pacjenta który ma widzieć swoje dane, pielęgniarkę która jakis wycinek, lekarza inny wycinek, administratora danych ktory widzi wszystko itd.
Dodatkowo jak wchodzimy w tematy multitanacy to ja bym wybrał zabezpieczenie na poziomie bazy danych.

Czy front/aplikacja po stronie klienta powinna weryfikować dane z serwera?

Tylko jeśli serwer nie jest częścią tego samego systemu co front/aplikacja. A co to oznacza w praktyce to już inna kwestia :)

Część serwerowa z założenia nie ma w procesie czynnika ludzkiego dlatego powinna możliwie dużo sprawdzać sama. Cześć frontendowa ma ten czynnik i hydraulik powinien rozumieć co należy do jego obowiązków, a ew task którego nigdy nie powinien wykonywać powinien być zgłoszony na support jako błąd.

Co się tyczy miksowania danych klientów to jest to sytuacja zahaczająca o tematy prawne i sam serwer powinien się powstrzymać przez zwróceniem czegoś takiego. W dalszym ciągu nie widzę powodu dla którego aplikacja powinna o to dbać

Szczególnie, że - bądźmy szczerzy - wobec człowieka który ma złe intencje, cokolwiek wyjdzie z serwera należy traktować jako pokazane. Nieważne czy widok to filtruje czy nie

Moim zdaniem nadużycie. Jeżeli do klienta nie mają trafiać jakies tam informacje, to nie powinny tam trafiać. Jedyna "obrona" po stronie klienta systemu jaka powinna mieć miejsce, to kulturalne wysypanie się, jeżeli dostanie danych, których nie potrafi obsłużyć.
Możesz oczywiście implementować po stronie FE jakąś logikę, która wie, że jest zalogowany Mietek, a nie Kazik, a dostanie dane dla Kazika, to je pominie, ale moim zdaniem to rozmywanie odpowiedzialności.
Prędzej czy później dojdzie do sytuacji, w której teoretycznie i backend i frontend powinny coś zrobić, a w praktyce nikt tego nie zrobi, bo bakusie stwierdzą, że frątasie sobie to ogarną i na odwrót.

Ja się zgodzę, że frontend nie powinien odpowiadać za nic w kwestii walidacji / filtrowania danych.

Wysyłanie zbędnych danych jest marnotrawstwem, szczególnie w przypadku aplikacji mobilnych z których często korzysta się ze słabym internetem i to zaczyna kopać.

Potencjalnie to może być też problem security, jeśli ktoś pojedzie po będzie bandzie i zwróci dane, których nie powinien zobaczyć użytkownik. Sprytny użytkownik użyje devtools albo stuknie prosto do API i te dane zobaczy.

Ogólnie to godzi też, poza podziałem odpowiedzialności, w spójność danych i kompatybilność między wersjami aplikacji frontendowej.

A aplikacje mobilne to w ogóle czasem masakra do zaktualizowania, bo użytkownicy niekoniecznie chcą co rusz pobierać nową wersję. Backend łatwiej zmienić.

Dlatego maksimum, które front powinien robić, to upewnienie się że dane które przyszły pasują do ustalonego kontraktu, bo ten lubi się rozjechać, albo ktoś decyduje się robić breaking change (czasem trzeba) i starsze wersje przestają działać poprawnie. Lepiej to obsłużyć w elegancki sposób.

Nie ma sensu dodatkowe filtrowanie danych po stronie frontu.
To dodatkowy kod, który trzeba utrzymywać, kolejne potencjalne błędy.

Oczywiście front powinien dbać o bezpieczne wyświetlanie danych np. web musi się przejmować XSS (eskejpowanie/sanitacja itp) (ale to specyfika web i większość normalnych frameworków (Anular, React) i tak to załatwia).

Są przypadki kiedy mamy paranoje security (np. dane medyczne), ale wtedy też dodatkowe filtrowanie na froncie... to i tak za późno. Są dodatkowe filtry/reguły, które można umieścić w ramach API Gateway itd. Czyli po tym jak backend wypluje dane, to muszą jeszcze przejść przez dodatkowy zestaw reguł (ale to naprawde niszowe sytuacje - raz pracowałem przy takim systemie - to było straszne, ale niestety miało sens).

@jarekr000000 Według mojego rozumienia (może za dużo bakusiowania) za ochronę przed XSS (i w sumie innymi podobnymi atakami), tak czy inaczej w pierwszej kolejności powinien odpowiadać backend. Czy robi to prawidłowo napisany kod aplikacji, czy jak to opisujesz jakieś wymyślne api gatewaye/WAF'y i inne cuda jest sprawą drugorzędną a raczej kod backendu powinien być bezpieczny sam z siebie, a te dodatkowe zabezpieczenia to raczej dmuchanie na zimne i czasami spełnianie formalnych wymogów ze strony firmowego/klienckiego security. Ale może za bardzo bakusiowo patrzę na to.

@piotrpo teraz już każdy w miarę się nauczył (poza firmami, które jeszcze się tego uczą na fakapach) że jedna linia obrony może zabraknąć, jeśli chodzi o security.

Owszem, backend powinien za to odpowiadać i to jeszcze przy zapisie, ale w sumie jaką masz gwarancję, że nikt nie zepsuł i jednak wrócą dane z XSS - więc co zaboli zrobić raz jeszcze taki sanity check. Podobnie jak przy zapisie do bazy możesz zrobić sanitację (jak to nazwać po polsku?) danych, by nikt nie zrobił SQLi, ale jednak nie ma co temu ufać i jednak się robi prepared statememt.

Bardzo ciekawe zagadnienie, ale mam wrażenie, że strasznie teoretyzujemy i pomijamy, jak można by to zaimplementować w rzeczywistości. Weźmy przykłady:

... który obsługuje przychodnię czy laboratorium medyczne i nagle wchodzi Jan Nowak, a dostaje wyniki wszystkich Nowaków - bo ktoś na serwerze coś schrzanił i zapytanie zwraca więcej, niż powinno, a po stronie apki nikt tego nie weryfikuje, tylko wypluwa na ekran wszystko tak, jak dostał. OK

Eee... no nie wiem. W sensie, skąd apka ma wiedzieć, że to co dostała, jest błędne? Serwer wysłał listę zamiast obiektu? Spodziewała się 1 rekordu a dostała 100? To jeszcze się da zakodzić. Ale np. dostała dane innej osoby - co wtedy? Porównywać czy request.lastName == response.lastName? A co jak nazwisko się zgadza, ale jest to inna osoba? Za dużo przypadków.

front stwierdzi, że firma o ID 438 dostała dane dla ID 947 to ich nie pokaże, a przy okazji jeszcze powiadomi serwer, że taki problem został stwierdzony.

To się jeszcze da zakodzić, podobne porównanie jak wyżej. Ale co, jak dostanę id ten sam, ale dane innej firmy? Albo spieprzy się CDN i dostanę za każdym odświeżeniem dane różnych firm? Nie wiem, skąd frontend mógłby się domyślić tego.

Ja myślę że na 99% @Riddle ma rację - był sobie ambitny zespół frontów, który musiał pracować z nieco mniej ambitnym zespołem bakusiów, a jako że frontendzi zawsze są na pierwszej linii ognia jeśli chodzi o widoczne błędy w aplikacji, to zaczęli chronić swoje 4 litery i programować skrajnie defensywnie.

piotrpo napisał(a):

@jarekr000000 Według mojego rozumienia (może za dużo bakusiowania) za ochronę przed XSS (i w sumie innymi podobnymi atakami), tak czy inaczej w pierwszej kolejności powinien odpowiadać backend.

Nie wszystkie klienty to Web. I nie wszystkie klienty są podabne na webowe XSS, więc nadgorliwe (np. eskejpowanie) po stronie backendu może wręcz czasem napsuć.

Myślę że jeżeli koszt wydajnościowy jest minimalny, to nie ma nic złego w zrobieniu czegoś takiego na wszelki wypadek.

Taki check na frontendzie mógłby nawet później pingnąć jakiś alert

@piotrpo

Według mojego rozumienia (może za dużo bakusiowania) za ochronę przed XSS (i w sumie innymi podobnymi atakami), tak czy inaczej w pierwszej kolejności powinien odpowiadać backend.

wtf? to frontend ma wyrenderować bezpiecznie treść, a nie backend usuwać jakieś znaczki i inne głupotki :D

superdurszlak napisał(a):

@piotrpo teraz już każdy w miarę się nauczył (poza firmami, które jeszcze się tego uczą na fakapach) że jedna linia obrony może zabraknąć, jeśli chodzi o security.

No i się robi te "linie obrony". Zaczynając od napisania porządnego kodu na backendzie.

Owszem, backend powinien za to odpowiadać i to jeszcze przy zapisie,

No i to właśnie jest gwóźdź programu. Backend nie powinien na pałę zapisywać czegoś, co później zwraca.

ale w sumie jaką masz gwarancję, że nikt nie zepsuł i jednak wrócą dane z XSS - więc co zaboli zrobić raz jeszcze taki sanity check

Gwarancji nie masz nigdy i dlatego masz wiele poziomów zabezpieczeń. Zaczynając od rozumienia przez programistę podstawowych typów zagrożeń, poprzez skanery kodu (prosty flow zapis-odczyt wychwytuje każdy, z którym miałem do czynienia), WAFna warstwie 7'ej, jakieś tam firewalle na 3 itd. Ale tak jak nie masz gwarancji, że programista nie strzeli babola, tak zdawanie się na infrastrukturę, że zrozumie twoją aplikację i wychwyci jakieś skrypty skądś tam już kompletnie nie budzi mojego zaufania.

. Podobnie jak przy zapisie do bazy możesz zrobić sanitację (jak to nazwać po polsku?) danych, by nikt nie zrobił SQLi, ale jednak nie ma co temu ufać i jednak się robi prepared statememt.

Nie wiem kto się jeszcze daje złapać na wstrzyknięciach SQL'a. Klejone kwerendy to coś, co wyłapuje każdy możliwy skaner.

@WeiXiao

wtf? to frontend ma wyrenderować bezpiecznie treść, a nie backend usuwać jakieś znaczki i inne głupotki :D

Backend nie ma nic usuwać. Backend ma nie utrwalić tych głupotek. jeżeli gdzieś wychwyci niebezpieczną treść wprowadzoną przez użytkownika, to ma jej nie wpuścić dalej. Z punktu widzenia backendu frontend nie istnieje. Jest jedynie coś, co wysyła żądania HTTP i dostaje odpowiedzi. Nie wiem, czy to "zaufana aplikacja", czy ktoś strzela spreparowane żądania z postmana.Ogólnie atak na stronę kliencką jest dość trudny, jchyba edyny naprawdę poważny problemto używanie cudzych bibliotek i dynamiczne treści stron trzecich (np. reklamy).

@jarekr000000 Fakt, są różne wektory ataku:

@piotrpo

Backend nie ma nic usuwać. Backend ma nie utrwalić tych głupotek. jeżeli gdzieś wychwyci niebezpieczną treść wprowadzoną przez użytkownika, to ma jej nie wpuścić dalej.

Co to jest ta niebezpieczna treść? takie stringi? <script> alert('dupa') '; DROP DATABASE;?

Backend ma to zapisać w bazie i tyle. To nie są czasy budowania SQLa za pomocą łączenia stringów i braku narzędzi do bezpiecznego wyrenderowania czegoś na frontendzie.

Następnie backend zwraca to na front, a front ma to bezpiecznie wyrenderować (zakładając webowy frontend).

Ta cała "input sanitization" to jakiś zbiór mitów i pomysłów na dzikie obrabianie stringów zamiast zrobienia czegoś poprawnie

https://benhoyt.com/writings/dont-sanitize-do-escape/

https://kevinsmith.io/sanitize-your-inputs/