No to co jeżeli w takie "bezbronne" pole tekstowe użytkownik wprowadzi jakiś złośliwy kod? Przecież jak ktoś ma bloga, to raczej nie pozwoli, by w polu komentarz ktoś wpisał dowolny tekst?
Jeśli aplikacja jest napisana poprawnie, to nie ma czegoś takiego jak "złośliwy kod". Nawet jak wpiszesz najbardziej "złośliwe znaki" jakie się tylko da, do pola w komentarzu, to one powinny być poprawnie dodane do bazy oraz do widoku.
Weź na przykład edytor na 4programmers. Możemy tu wpisywać dowolne SQL'e i XSS jakie się nam tylko nie śniły, ale nie zobaczysz nigdy komunikatu "Nie możesz dodać znaku &
w poście".
Jeżeli dobrze rozumiem, to jest to właśnie XSS.
Nie, to nie jest po to.
Sporo ludzi Ci tutaj opowiada o "escape'owaniu" złośliwych znaków - to jest z pewnością to jak praktycznie to należałoby to zrobić.
Ale ostatecznie, całość sprowadza się do bardzo prostego rozrachunku. Zadaj sobie pytanie - czy jest jakiś ciąg znaków/bajtów, które nie da się dodać do bazy? (np takiego z apostrofami, --
, ==
, etc.). Jeśli tak, to faktycznie musiałbyś odrzucić te dane w interfejsie użytkownika. Ale we wszystkich bazach jakie znam, dowolny ciąg znaków zawsze można do niego dodać - więc i każdy input usera można dodać do takiej bazy, nie ma więc powodu czemu również tych znaków które określiłbyś "złośliwymi" miałoby się nie dać dodać. To o czym Ty mówisz, podatność na SQL Injection, to jest właściwie tylko i wyłącznie to błąd programisty, który niepoprawnie połączył plain text (np treść komentarza) z językiem SQL, przez co jego query wymieszało się z potencjalnym query w komentarzu. To jest przyczyna tego błędu - niepoprawne łączenie tych dwóch formatów, nie "znaki" same w sobie.
Odpowiadająć na Twoje pytanie No to co jeżeli w takie "bezbronne" pole tekstowe użytkownik wprowadzi jakiś złośliwy kod?
- jeśli użyjesz odpowiedniego budowania query i odpowiedniego budowania widoku - nic się nie stanie.