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? ), 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 . 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 .

Wszystko zalezy co potrzebujesz. Jesli potrzebujesz obslugiwac kod html wprowadzony przez uzytkownika, to logicznie ze nie uzyjesz htmlspecialchars tylko wlasnie jakiegos sanityzera.
A jesli user moze tyko podac jakis kometnarz bez kodow html to mozesz uzyc i jedno i drugie. No wszystko zalezy od ciebie


No skoro dwa razy escapujesz to masz co masz. Skoro uzywasz htmlspecialchars w kodzie php to juz w szablonie wysietlaj tylko RAW data a nie przerobone jeszcze przez szablon.
NO a skoro szablon za ciebei odwala robote to po co robisz htmlspecialchars w ogole?

Dzięki za odpowiedź! Nie napisałem, że używam konkretnego sposobu wszędzie na pałę. Chciałem zebrać dobre praktyki w danych sytuacjach i rozważyć różne podejścia podczas dyskusji, np. (3) jest dosyć w opozycji do (1) i (2)..

Jak rozumiem, można przyjąć, że:
A. Przyjmujemy dane, gdzie nie powinno być HTMLa -> sanityzer z allowSafeElements() + (htmlspecialchars() lub escapowanie przez szablon)
Wolicie całkiem pozbyć się wtedy tagów HTML, które zostały (blockElement() z sanityzera lub strip_tags()), czy raczej puścić je wolno i tylko escape'ować?

B. Przyjmujemy dane, gdzie może być HTML -> tylko sanityzer z dozwolonymi elementami

Co ze sposobem (3), czyli brakiem jakiegokolwiek filtrowania podczas odbioru danych, a dopiero na wyjściu? Stosuje ktoś takie rozwiązanie?

nigdzie nie napisalem ze uzywasz na pale. Ustosunkowywalem sie jedynie do tego co pisales.


Jak juz pisalem: wszystko zalezy. Ja osobiscie niegdy nie pozbywam sie html bo mi to wisi. Ale tobie, czy twojemy klientowi, moze zalezec by sie pozbywac. No nie ma na to pytanie jednoznacznej odpowiedzi.


A co rozumiesz przez wyjscie? Bo dla mnie wyjscie to juz np. szablon, ktory escepauje dane za mnie. Wiec tak, dane u mnie sa escapowane na wyjsciu

Przy danych otrzymywanych z formularza filtruje te pola, w których wiem co chcę zapisać do bazy, a "oszukane" dane są niepożądane przy przetwarzaniu.
Przy formularzu z polami: imię i nazwisko, adres e-mail, temat oraz treść artykułu - tylko dla treści zezwalam na HTML itd., pozostałe wiemy co powinno być zapisane w polu imię, e-mail albo telefon, więc po co zaśmiecać bazę tonami KB w postaci linków do stron, albo odnośników w html'u, czy reklamą.

Od tego to chyba mamy walidacje? Ze email ma miec okreslona struktrue, to bylo dla mnie logiczne ze w email nie wloze kodu html. Sadzilem ze mowimy tutaj o ogolnym polu, ala komentarz

Racja, przy formularzu wystarczy walidacja (filtrowanie przed zapisaniem do bazy) poza polami ogólnymi typu komentarze, albo treść artykułu, gdzie prawie zawsze dodaje filtrowanie.
Hipokrates głosił, że lepiej zapobiegać, niż leczyć

Dzięki za odpowiedzi! Oczywiście chodzi o pola "swobodne", nie o np. e-mail czy numer telefonu, który jest walidowany, bo spodziewamy się konkretnych wartości.

Trochę jeszcze sobie eksperymentowałem z tym oczyszczaczem od Symfony i chyba wychodzi na to, że jeśli na froncie mam jakiś system szablonów, który escapuje przekazane dane, to właściwie trochę bez sensu jest używanie go? Bo nawet takie znaki jak + czy " poza tagami HTML są zamieniane na encje, np. & #43; czy & #34;. Niestety nie znalazłem opcji typu allowSign/allowCharacter, żebym mógł niektóre dopuścić... Trzeba-by chyba sobie zrobić małą nakładkę, żeby eliminować niepożądany HTML, a jednocześnie z powrotem zamieniać te encje na znaki? Chyba trochę tego nie rozumiem, dlaczego tagi HTML są zostawiane nieruszane i niezmienione w encje, a tylko eliminowane są potencjalnie niebezpieczne, natomiast zwykłe znaki bez kontekstu HTML są zamieniane na encje? Mam ochotę powiedzieć: bez sensu, ale pewnie kryją się za tym jakieś przemyślenia..

Podpowiecie o co tutaj chodzi? Opcja Sanityzera wydawała mi się bardzo interesująca właśnie ze względu na to, że nie przemiela mi HTMLa na encje, a tylko wyrzuca potencjalnie niebezpieczne tagi, ale jeśli proste znaki typu + są zamieniane na encje, które system szablonów mi potem escapuje, to powoduje to trochę zamieszania... Bo nie po to używam tego oczyszczacza zamiast htmlspecialchars() żeby potem niektóre znaki mieć w postaci encji, które są escapowane przez system szablonów, a tagi HTML jako czysty HTML (?)...

nie rozumiem problemu. Albo uzywasz sanitizera, albo escapujesz dane. Sie zdecyduj,

No więc właśnie do tego zmierzałem, bo jakoś chyba tak w pełni to nie wybrzmiało. Czyli rozumiem, że można podsumować tę dyskusję i wymianę doświadczeń następująco:
1. Escapujemy w szablonie, więc nie trzeba ani oczyszczacza, ani htmlspecialchars(), ewentualnie możemy użyć oczyszczacza i część znaków ręcznie przywrócić po procesie oczyszczenia (np. +) lub strip_tags(), żeby wywalić szpecące tagi, które i tak zostaną wyescapowane.
2. Pozwalamy częściowo na HTML, więc używamy oczyszczacza i w danym miejscu nie escapujemy tych danych.
3. Szablon nie escapuje, ale nie chcemy żadnego HTMLa, więc używamy htmlspecialchars() i oczyszczacz też nie zaszkodzi.
4. Szablon nie escapuje, a HTML jest częściowo dozwolony, więc używamy oczyszczacza.

Przepraszam, jeśli męczę bułę za bardzo, ale ostatnio sporo nad tym myślałem i chciałem rozwiać wątpliwości w szerszym gronie.

Pozdrowienia

"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
Zrób jak chcesz tylko bezpiecznie, a będzie dobrze