Post
#1
|
|
|
Grupa: Zarejestrowani Postów: 5 Pomógł: 0 Dołączył: 20.04.2022 Ostrzeżenie: (0%)
|
Czołem!
Jaki jest Waszym zdaniem najlepszy sposób na przyjmowanie i przygotowywanie danych otrzymanych od użytkownika, np. przez formularz? Trochę szperałem w sieci, ale zawsze konkretna odpowiedź od konkretnych osób i dyskusja wokół tego jest dla mnie najbardziej wiarygodnym i aktualnym źródłem wiedzy. 1. W ostatnim czasie popularne stały się tzw. sanityzery (oczyszczacze? (IMG:style_emoticons/default/wink.gif) ), np. HTMLSanitizer, który jest pakietem Symfony od wersji 6 (chociaż działa też chyba samodzielnie), opracowany na podstawie dokumentu HTML Sanitizer W3C Standard Proposal.. Polega to na tym, że tylko niektóre tagi HTML uznane domyślnie za bezpieczne (np. <b>, <i> itp.), lub bezpośrednio zdefiniowane w konfiguracji, są przepuszczane łącznie z ich zawartością, natomiast te uznane za potencjalnie niebezpieczne całkowicie wylatują z przetwarzanej treści lub ewentualnie jest pozostawiana ich treść (w przypadku ich blokowania. Z jednej strony wydaje się, że jest to bardzo dobre rozwiązanie, bo po (1) zdajemy się na wiedzę i doświadczenie twórców takiej klasy sanityzującej, a po (2) niektóre tagi są puszczane, co jest korzystne, jeśli pozwalamy na proste manewrowanie tekstem (chociaż można do tego użyć jakiegoś innego kodu, np, markdown, zamiast bezpośrednio HTML). Z drugiej strony możemy stracić jakąś treść, która była zawarta między potencjalnie niebezpiecznymi tagami, ale w sumie jak ktos użył podejrzanych tagów, to chyba nie ma powodu brać takich danych jako wartych uwagi z punktu widzenia biznesowego (IMG:style_emoticons/default/wink.gif) . Czy w takim razie może macie jakąś "swoją ulubioną" konfigurację takiego oczyszczacza? Może jakieś połączenie pomiędzy allowSafeElements() i dodaniem do tego zestawu niektórych blokowanych elementów, żeby usunąc nadmiarowe zbędne tagi? 2. Stary, dobry (?) htmlspecialchars() i/lub w połączeniu ze strip_tags() - czy aby na pewno bezpieczne przeciwko próbom XSS? Wydaje się, że chyba tak, ale chętnie poznam Waszą wiedze w tym temacie. Wadą jest to, że wszystkie znaki potencjalnie specjalne, np. cudzysłowy, są zamieniane na encje HTML, co w przypadku połączenia z dodatkowym escapowaniem przez system szablonów wygląda potem średnio, bo staje się to faktycznie encjami, a nie znakami, jakie reprezentują. Ponadto w przypadku chęci zachowania niektórych tagów jest to problem, bo trzeba je potem odkodowywać itp., ale wtedy odkodujemy też te potencjalnie niebezpieczne, więc lipa. Zaletą jest z kolei to, że nie utracimy treści, którą ktoś chciał nam przekazać, ale zaplątała się w tagi HTML, które przez Sanitizera mogłyby być uznane za niebezpieczne. 3. Niektórzy twierdzą, że bez sensu jest w ogóle procesować i modyfikować treści od użytkownika, bo należy skupić się, aby odpowiednio je przeprocesować wtedy, gdy ich używamy, czyli np. escapować z użyciem mechanizmów, jakie mają systemy szablonów (np, Twig) lub parsować do JSONa, kiedy potrzebujemy JSON i wtedy funkcja przygotowująca JSON też odpowiednio przetworzy znaki specjalne i tak dalej, czyli generalnie w momencie użycie dopiero martwimy się, czy ktoś nie próbował przesłać złośliwego kodu. Niby nie trzeba nic robić na wejściu, ale z kolei trzeba uważać przy wyświetlaniu czy przesyłaniu takiej treści. A zatem jak najlepiej radzić sobie z odpowiednim przetwarzaniem treści nadesłanej przez użytkownika? Może są jeszcze jakieś inne sposoby? Jak Wy przetwarzacie treści napływające od użytkowników? Liczę na owocną dyskusję i/lub konkretne rozwiązania (IMG:style_emoticons/default/wink.gif) . |
|
|
|
![]() |
Post
#2
|
|
|
Grupa: Zarejestrowani Postów: 578 Pomógł: 6 Dołączył: 21.07.2008 Ostrzeżenie: (0%)
|
"pozwalanie na częściowy HTML" - nie za bardzo wiem o co chodzi,
ale generalnie nie raz mam podobny dylemat i nie ma tu jednoznacznej odpowiedzi, ponieważ to zależy... Jeżeli myślisz tutaj, że np. zezwalasz na pogrubienie tekstu, to nie tak, że częściowy HTML, a używasz edytora i ustawisz BBCode [ b ]pogrubienie[ /b ] i tak zapisujesz do bazy, przy wyświetlaniu zmieniasz [ b ] na <strong> lub <b>, [ url ] zamieniasz na odsyłacz itd., lub coś podobnego, przykład użycia stosowałeś już wyżej w postach na forum przy pogrubieniu. Na HTML zezwalasz, albo nie, żadne częściowe HTML. Przy formularzu, walidacja i dalej to już nospor napisał, że można zapisywać HTML do bazy bez jakiegoś czyszczenia, ważne co wyświetlasz i abyś przy wyświetlaniu zabezpieczył Patrząc na Symfony, o którym wspominasz, tutaj domyślnie jest printf('Hello %s', htmlspecialchars($name, ENT_QUOTES, 'UTF-8')); ponieważ tak jest bezpiecznie: https://symfony.com/doc/current/create_fram...foundation.html wygląda, więc że podeszli do zagadnienia w sposób, o którym pisałem, że lepiej zapobiegać niż leczyć. Nie zawsze jednak takie rozwiązanie mi pasuje, no i pojawia się dylemat oczyszczania (IMG:style_emoticons/default/wink.gif) Zrób jak chcesz tylko bezpiecznie, a będzie dobrze (IMG:style_emoticons/default/smile.gif) Ten post edytował Malinaa 27.03.2024, 20:35:42 |
|
|
|
Rotmistrz Przyjmowanie danych od użytkownika w 2024 roku 25.02.2024, 14:42:38
nospor Wszystko zalezy co potrzebujesz. Jesli potrzebujes... 25.02.2024, 20:27:10
Rotmistrz Dzięki za odpowiedź! Nie napisałem, że używam ... 25.02.2024, 23:41:40
nospor nigdzie nie napisalem ze uzywasz na pale. Ustosunk... 26.02.2024, 09:30:04
Malinaa Przy danych otrzymywanych z formularza filtruje te... 26.02.2024, 16:08:03
nospor CytatPrzy formularzu z polami: imię i nazwisko, ad... 26.02.2024, 16:10:29
Malinaa Racja, przy formularzu wystarczy walidacja (filtro... 26.02.2024, 23:13:59
Rotmistrz Dzięki za odpowiedzi! Oczywiście chodzi o pola... 17.03.2024, 00:42:02
nospor nie rozumiem problemu. Albo uzywasz sanitizera, al... 18.03.2024, 10:12:48
Rotmistrz No więc właśnie do tego zmierzałem, bo jakoś chyba... 21.03.2024, 23:48:52 ![]() ![]() |
|
Aktualny czas: 28.12.2025 - 17:03 |