Czy dobrze jest "wielokrotnie" dane xss-clean w CodeIgniter?

Question

następujące sposoby XSS-czystych danych w CodeIgniter:

• ustawić global_xss_filtering w config do TRUE
• użytku xss_clean()
• użytku xss_clean reguły walidacji
• ustawić drugi parametr do TRUE w $this->input->post('something', TRUE)

Czy można używać wszystkich lub więcej niż jednego z nich na jednym kawałku danych?

Na przykład, byłoby w porządku, gdybym nadal używane $this->input->post('something', TRUE) nawet jeśli dane zostały już oczyszczone przez global_xss_filtering i xss_clean reguły walidacji?

Answer 1

Tak. Załóżmy, że twoje wejście to "A". Następnie, powiedzmy uruchomieniu xss_clean dostać XSS-bezpieczną zawartość:

B = xss_clean(A) 

Teraz, powiedzmy, że mogę to zrobić ponownie, aby dostać C:

C = css_clean(B) 

Teraz, jeśli B i C różnią, a następnie musi to oznaczać, że B ma pewną zawartość niebezpieczną dla XSS. Co oczywiście oznacza, że ​​xss_clean jest uszkodzony, ponieważ nie wyczyścił prawidłowo A. Dopóki założysz, że funkcja zwraca zawartość bezpieczną dla xss, dobrze jest iść.

Jednym z argumentów, które można zrobić, jest to, że funkcja modyfikuje nawet zawartość bezpieczną dla XSS? Cóż, to by było do dupy, a to nadal oznaczałoby, że funkcja jest zepsuta, ale tak nie jest (mówiąc po prostu z mojego doświadczenia, ponieważ nie widziałem, aby zachowywał się tak jak zawsze).

Jedyną wadą, jaką widzę, jest dodatkowe obciążenie przetwarzania, ale dwukrotne wykonanie jest w porządku (raz przy globalnym filtrowaniu, a gdy robi to jawnie, na wypadek, gdyby globalne filtrowanie zostało wyłączone przez kogoś) i jest ładne ok koszty ogólne dla zapewnienia bezpieczeństwa.

Ponadto, jeśli mogę dodać, codeigniters xss clean nie parsuje HTML i upuszcza znaczniki i takie tam. Po prostu konwertuje < i > na < i . Mając to na uwadze, nie widzę niczego, co mogłoby pójść nie tak.

Answer 2

Nie zaszkodzi ci to, ale zdecydowanie jest bezcelowe.

Istnieje bardzo duża szansa, że ​​w końcu osiągniesz punkt, w którym globalny filtr XSS będzie nieporęczny. Ponieważ nie można go wyłączyć na kontroler bez dużych hacków, a dostęp do surowych danych $_REQUEST będzie niemożliwy, będziesz musiał wyłączyć to globalnie. Nastąpi to w momencie, w którym chcesz przetworzyć pojedynczy kawałek zaufanych danych lub dane, które nie są wyjściami HTML i muszą pozostać nienaruszone.

Używanie go jako reguły sprawdzania poprawności formularza jest bezcelowe i potencjalnie destrukcyjne. Wyobraź sobie, jaka byłaby ta strona, gdyby za każdym razem, gdy wpiszesz <script>, została ona zastąpiona przez [removed], bez możliwości jej przywrócenia w przyszłości.Dla innego przykładu, co jeśli użytkownik używa jakiejś treści "XSS" w swoim haśle? Twoja aplikacja zakończy się cichą zmianą danych wejściowych.

Wystarczy użyć filtra XSS tam, gdzie jest to potrzebne: na wyjściu HTML, miejsca, w których można wykonywać javascript.

Answer 3

Użycie xss_clean nawet raz jest złe, o ile mi wiadomo. Ta procedura próbuje zdezynfekować dane przez usunięcie części lub wymianę części. Jest stratny i nie gwarantuje powrotu tej samej treści po uruchomieniu wiele razy. Trudno też przewidzieć i nie zawsze będzie działać właściwie. Biorąc pod uwagę ilość rzeczy, które robi, aby spróbować zdeitalizować ciąg, istnieje potężne uderzenie wydajności dla użycia tego na wejściu. Nawet najmniejsza część danych wejściowych, takich jak a = b, wywoła falę aktywności dla xss_clean.

Chciałbym powiedzieć, że nigdy nie należy używać xss_clean, ale realistycznie nie mogę tego powiedzieć. Ten system jest przeznaczony dla niedoświadczonych programistów, którzy nie wiedzą, jak bezpiecznie zarządzać treściami użytkowników. Jestem doświadczonym programistą, więc mogę powiedzieć, że żaden projekt nad którym pracuję nie powinien nigdy używać xss_clean. Faktem jest, że problemy związane z korupcją będą mniej problematyczne dla twórców niedoświadczonych z prostszym użyciem i ostatecznie zapewne sprawią, że ich kod będzie bezpieczniejszy, nawet jeśli powinni oni sami zabezpieczać swój kod, zamiast polegać na szybkich, brudnych i tanich hakach. Z drugiej strony, xss_clean nie gwarantuje pełnego bezpieczeństwa kodu i może ostatecznie pogorszyć sytuację, dając fałszywe poczucie bezpieczeństwa. Zaleca się, aby naprawdę się uczyć, aby upewnić się, że rozumiesz dokładnie wszystko, co robi twój kod, dzięki czemu możesz go naprawdę zabezpieczyć. xss_clean nie kompensuje błędów kodu, kompensuje błędy kodera.

Idealnie xss_clean chce być wykonane tylko na wyjściu (i chce zostać zastąpione przez htmlentities, itp.), Ale większość ludzi nie będzie się tym przejmować, ponieważ prostsze jest dla nich naruszenie czystości danych poprzez filtrowanie wszystkich danych wejściowych zamiast filtrowania (coś można wprowadzić raz, ale wyprowadzić dziesięć razy). Znowu niezdyscyplinowany programista nie może wstawić xss_clean dla jednego z tych dziesięciu przypadków wyjścia.

Realistycznie jednak, jedyną przyzwoitą metodą jest prawidłowe kodowanie wszystkiego w widoku w momencie, gdy ma być wyświetlane na stronie. Problem z kodowaniem wyprzedzającym polega na tym, że przechowujesz dane, które mogą być niepoprawnie zakodowane i możesz podwójnie kodować dane, jeśli są wprowadzane, a następnie wyprowadzać je do formularza, a następnie wprowadzać ponownie. Jeśli myślisz o czymś w rodzaju pola edycji, możesz mieć poważne problemy ze wzrostem ilości danych. Nie wszystkie urządzenia sanitarne usuwają zawartość. Na przykład, jeśli dodasz, to doda treść. Jeśli masz slash w swoich treściach za każdym razem, gdy uruchamiasz addslashes, dodaje się nowy slash powodujący jego wzrost. Chociaż istnieje duża szansa, że ​​twoje dane zostaną osadzone w HTML-u, nie zawsze będziesz wiedzieć, gdzie ostatecznie znajdą się dane. Nagle pojawia się nowe wymaganie, które dotyczy poprzednich danych i to wszystko, jesteś wkręcony, ponieważ zastosowałeś i filtr stratny do danych przychodzących przed przechowywaniem. Strata, w tym przypadku, może oznaczać twoją pracę po uszkodzeniu wszystkich danych użytkownika w bazie danych. Twoje dane są zazwyczaj najcenniejsze dla aplikacji internetowej. Jest to duży problem z kodowaniem wyprzedzającym. Łatwiej jest pracować, jeśli zawsze wiesz, że twoje dane są czyste i mogą uciec przed nim w zależności od sytuacji, ale jeśli twoje dane mogą być w jakimkolwiek stanie, może to być bardzo problematyczne. Filtrowanie może również powodować sporadyczne logiczne przerwy. Ponieważ na przykład sanitacja może usunąć treść, można dopasować dwa łańcuchy, które nie pasują do siebie.

Wiele problemów z xss_clean na wejściu są takie same lub podobne do tych, dla magic_quotes: http://en.wikipedia.org/wiki/Magic_quotes

Podsumowanie: Nie powinno się używać, ale zamiast blokować złe dane na wejściu użytkownika i uciec odpowiednio na wyjściu. Jeśli chcesz odseparować dane użytkownika, powinno to nastąpić w kliencie (przeglądarce, formularzu sprawdzania poprawności), aby użytkownik mógł go zobaczyć. Nigdy nie powinieneś mieć niewidzialnej zmiany danych. Jeśli musisz uruchomić xss_clean. Powinieneś uruchomić go tylko raz, na wyjściu.Jeśli zamierzasz użyć go do sprawdzania poprawności danych wejściowych, to $ posortowane_danie! == xss_clean ($ posted_data), a następnie odrzuć.