• Najnowsze pytania
  • Bez odpowiedzi
  • Zadaj pytanie
  • Kategorie
  • Tagi
  • Zdobyte punkty
  • Ekipa ninja
  • IRC
  • FAQ
  • Regulamin
  • Książki warte uwagi

XSS gdzie filtrować

VPS Starter Arubacloud
0 głosów
347 wizyt
pytanie zadane 2 lipca 2018 w Inne języki przez marcin99b Szeryf (81,480 p.)
Nie znalazłem na razie odpowiedzy na to pytanie

Sytuacja wygląda tak, że mam api którego głównym klientem jest strona internetowa z frameworkiem, który łączy się z tym api

I teraz na którym etapie powinno być filtrowanie tekstu, żeby nie był podatny na xss?
Czy to jest odpowiedzialność serwera, który odpowiada za zwracanie tekstu za pomocą api (strona jest głównym, ale nie zawsze może być jedynym klientem, nie każdy klient może obsługiwać kod html, przykładowo <)
Czy już aplikacji klienta, która przed wyświetleniem tekstu musi wszystko przefiltrować?

Obecnie jestem za tą drugą opcją, z zaznaczeniem w dokumentacji api że nie filtruje przeciw xss, aby aplikacje takie jak programy okienkowe, nie obsługujące html, mogły normalnie korzystać z api, żeby taki program po wysłaniu < mógł wyświetlić od razu < a nie &lt; które musiałby konwertować

2 odpowiedzi

+2 głosów
odpowiedź 2 lipca 2018 przez Comandeer Guru (599,730 p.)
wybrane 2 lipca 2018 przez marcin99b
 
Najlepsza
API powinno IMO zwracać surowe dane – zwłaszcza jeśli klientami będą nie tylko aplikacje przeglądarkowe. W takim wypadku nie ma sensownego sposobu na filtrowanie treści, bo różni klienci będą mieli różne wymagania.
0 głosów
odpowiedź 2 lipca 2018 przez mbady Obywatel (1,280 p.)

Ogólnie jest to zadanie strony serwerowej ale głównie powinno być przeprowadzone w momencie dodawania czegoś do serwera/bazy/itp, po prostu tych danych nie powinno tam być dlatego serwer w odpowiedzi wysyła wszytko to co "ma" tak długo jeśli spełnia to wymogi API (odpowiedni format itp).

Po za tym, klient przed wrzuceniem danych na serwer też może zrobić sprawdzenie ale główne obciążenie powinno być po stronie serwera.

Dlatego jeśli obawiasz się, że takie dane mogą dostać się do serwera to zabezpiecz jego wejście (API wejściowe) oraz jeśli istnieje podejrzenie, że już tam są to zrób skrypty/kod który sprawdzi aktualny stan serwera i poinformuje lub usunie te dane.

Dodatkowo jeśli chcesz mieć jakiś mechanizm zabezpieczający na wyjściu API tak jak piszesz to możesz sobie zrobić jakieś filtry, które w zależności od tego co chcesz, zablokują te dane i poinformują operatora o potrzebie sprawdzenia, lub tylko wstawią log, do późniejszej analizy itp. ale jest to dodatkowy mechanizm, zasadniczo powinno się sprawdzać dane wejściowe.

komentarz 2 lipca 2018 przez Comandeer Guru (599,730 p.)
A czemu serwer ma filtrować XSS skoro dla niego jest to nieistotne – tak samo jak dla części jego klientów?
komentarz 2 lipca 2018 przez mbady Obywatel (1,280 p.)
Wymieniłem powyżej dwa miejsca filtrowania, pierwsze na wejściu, gdy dodajemy coś do serwera o ile oczywiście jest API, które coś dodaje, wynika to z tego, że serwer powinien "czuwać" nad spójnością danych, które są do niego wprowadzane i wydaje mi się, że taki filtr/validator/cokolwiek powinno być.

Drugi filtr to powiedzmy dodatkowy, prewencyjny itp, nie jest oczywiście wymagany wymieniłem go tylko dlatego, że jak ktoś chce to może dodać coś takiego prewencyjnie aby teoretycznie zabezpieczyć klientów, ale jak pisałem wcześniej takich danych nie powinno tam w ogóle być, bo powinny być one przesiane/sprawdzone w momencie dodawania.

Dlatego ten filtr wyjściowy można potraktować jako taki niepotrzebny dodatek, nie wiem jaka jest dokładnie intencja autora i co chce osiągnąć więc podałem to jako opcję, że tak też można...
1
komentarz 2 lipca 2018 przez Comandeer Guru (599,730 p.)

Tylko po co serwer ma filtrować XSS skoro XSS jest zagrożeniem wyłącznie dla przeglądarki? A przecież nie tylko przeglądarki korzystają z API. To, co jest groźne dla przeglądarki, dla niezależnego parsera DOM czy innego serwera jest całkowicie normalnymi danymi. Dla takiego serwera z kolei zagrożeniem może być np. załączony kod PHP – który z kolei jest niczym szczególnym dla przeglądarki.

Dlatego też nie da się sensownie filtrować tego typu zagrożeń na wejściu, zwłaszcza jeśli robimy jedno spójne API dla wielu frontendów. Takie filtrowanie musi odbywać się po stronie klienta. Tym bardziej, że te dane są groźne dopiero w chwili ich wyświetlania.

I to nie jest żaden problem, bo obecnie przeglądarki dostarczają choćby Content Security Policy, które – dobrze zaimplementowane – pozwala ominąć większość takich zagrożeń niejako z automatu.

Można też skorzystać tutaj z middleendu, który będzie pośredniczył pomiędzy API a klientem i na którym będzie się odbywać wstępne filtrowanie.

komentarz 2 lipca 2018 przez mbady Obywatel (1,280 p.)

Ogólnie prywatnie jestem zdania, że każde dane dodawane do serwera poprzez API powinny być sprawdzane w jakikolwiek sposób i do tego zaliczam też problemy związane z tematem XSS.

Jeśli damy możliwość wprowadzania danych do serwera bez sprawdzania ich to dodajemy podatność na tego typu ataki.

Na szybko znalazłem kilka postów w necie, które omawiają ten problem, czyli sprawdzanie podatności XSS po stronie serwera.

Być może wszystko zależy też od "rangi" serwisu jaki się tworzy, bo oczywiście nie każdy endpoint trzeba sprawdzać pod kątem podatności ale warto mieć na uwadze lub mieć świadomość, że ten problem nie jest błachy.

Decyzja należy do tego kto robi API oraz co i w jaki sposób udostępnia, być może wystarczy zastanowić się jak dane API będzie używane i być może faktycznie nie ma problemu jeśli dane nie będą sprawdzane na wejściu ale zawsze powinno się mieć to na uwadze.

Chciałem raczej nakreślić możliwy problem, a nie narzucać konkretne rozwiązanie.

2
komentarz 2 lipca 2018 przez Comandeer Guru (599,730 p.)

Tylko zauważ, że w linkach, które podałeś, nie ma warstwy API. W tym wypadku serwer jest równocześnie miejscem renderowania odpowiedzi – zatem tak naprawdę odgrywa rolę middleendu, o jakim mówiłem.

Co więcej, ostatnie 2 linki nie są na temat. Przedostatni traktuje o Markdownie, w którym raczej nikt nie serwuje danych z API. Ostatni z kolei jest jakimś dziwnym obejściem, które obecnie można z powodzeniem zastąpić przez Content Security Policy.

2
komentarz 2 lipca 2018 przez Comandeer Guru (599,730 p.)

BTW, w linku o Markdown (który nie jest na temat ochrony API, jedynie ogólnie porusza temat XSS) napisano wprost:

The answer is not to filter the input, but rather the output.

A w przypadku API output jest generowany dopiero na etapie middleendu albo bezpośrednio na kliencie.

Zresztą w linku o Railsach też jest podobny motyw:

To avoid this, by default, Rails sanitizes every string that you throw into the view templates. You have to manually declare your string as safe if you want to render its unfiltered raw content.

Znów filtrowanie odbywa się na wyjściu, nie na wejściu. A wyjście – czyli rendering – odbywa się po stronie middleendu albo klienta. 

komentarz 2 lipca 2018 przez mbady Obywatel (1,280 p.)
Po ponownym przeczytaniu pytania i odpowiedzi tu zawartych faktycznie z funkcjonalności API wynika, że zwraca ono taką właśnie treść i w tym konkretnym przypadku serwer nie powinien interpretować/filtrować danych, bo po prostu są one w takiej formie i ewentualne zabezpieczenie takiego API powinno być po stronie odbiorcy, czyli przeglądarka lub jakiś DOM parser.

Po prostu za bardzo skupiłem się na zabezpieczeniu danych dodawanych do serwera w miejscu gdzie faktycznie funkcjonalność jest taka, że można otrzymać od serwera treść html.

Podobne pytania

0 głosów
1 odpowiedź 210 wizyt
pytanie zadane 1 lutego 2023 w Bezpieczeństwo, hacking przez michal6656 Nowicjusz (120 p.)
–1 głos
0 odpowiedzi 204 wizyt
pytanie zadane 17 września 2021 w Ogłoszenia, zlecenia przez Bzytek Użytkownik (810 p.)
0 głosów
3 odpowiedzi 513 wizyt
pytanie zadane 29 czerwca 2021 w PHP przez mat19 Obywatel (1,580 p.)

92,455 zapytań

141,263 odpowiedzi

319,099 komentarzy

61,854 pasjonatów

Motyw:

Akcja Pajacyk

Pajacyk od wielu lat dożywia dzieci. Pomóż klikając w zielony brzuszek na stronie. Dziękujemy! ♡

Oto polecana książka warta uwagi.
Pełną listę książek znajdziesz tutaj.

Akademia Sekuraka

Akademia Sekuraka 2024 zapewnia dostęp do minimum 15 szkoleń online z bezpieczeństwa IT oraz dostęp także do materiałów z edycji Sekurak Academy z roku 2023!

Przy zakupie możecie skorzystać z kodu: pasja-akademia - użyjcie go w koszyku, a uzyskacie rabat -30% na bilety w wersji "Standard"! Więcej informacji na temat akademii 2024 znajdziecie tutaj. Dziękujemy ekipie Sekuraka za taką fajną zniżkę dla wszystkich Pasjonatów!

Akademia Sekuraka

Niedawno wystartował dodruk tej świetnej, rozchwytywanej książki (około 940 stron). Mamy dla Was kod: pasja (wpiszcie go w koszyku), dzięki któremu otrzymujemy 10% zniżki - dziękujemy zaprzyjaźnionej ekipie Sekuraka za taki bonus dla Pasjonatów! Książka to pierwszy tom z serii o ITsec, który łagodnie wprowadzi w świat bezpieczeństwa IT każdą osobę - warto, polecamy!

...