Addslashes() w służbie bezpieczeństwa przed XSS?… NIE!

Mniej więcej dwa miesiące temu poinformowałem rejestratora domen 2be.pl o możliwości potencjalnego wycieku danych osobowych ich klientów z bazy danych. Dostałem wtedy po uszach, że jednocześnie opublikowałem na ten temat wpis na łamach mojego bloga, nie dając obsłudze technicznej czasu na reakcję. W tamtym okresie powiadomiłem teź Pana Administratora o poważnym błędzie XSS w ich serwisie. Co zrobili z tą informacją po dwóch miesiącach? Nic. Co zrobili po poinformowaniu o zakolejkowaniu tego wpisu? Naprawili błąd w przeciągu 24 godzin.

Najciemniej pod latarnią

Wadliwe pole tekstowe znajduje się na stronie głównej. Po wpisaniu nazwy domeny, którą chcemy zarejestrować oraz dodaniu na jej końcu znaku zakończenia inputa tekstowego (example.com”/>) i przesłaniu formularza naszym oczom ukaże się kilka dodatkowych atrybutów znacznika, który przed chwilą zamknęliśmy.

Zważywszy na to, że nazwa domeny przekazywana jest w adresie URL, ryzyko potencjalnego ataku phishingowego na nic nie świadomą ofiarę jest bardzo duże. Wystarczy ukryć nadmiar informacji, dodać przyjazny link, który przekieruje na spreparowaną domenę i nieszczęście gotowe.

Co jest nie tak z tym polem tekstowym?

Analizując dane input/output na stronie zauważyłem, że dane przekazywane przez zmienną GET są wyświetlane na stronie po uprzednim przefiltrowaniu ich funkcją addslashes(). Funkcja ta dodaje znak backslasha (\) przed takimi znakami jak cudzysłów (), albo inny backslash. Podsumowując: hemoglobina, addslashes, taka sytuacja… Osoby, które nie wiedzą, jak poradzić sobie z podobnym problemem, odsyłam do manuala PHP i funkcji htmlspecialchars().

Stanowisko 2be.pl

Po otrzymaniu zgłoszenia od Pana zostały podjęte czynności zmierzające do wyjaśnienia opisanej sytuacji.

W wyniku tych czynności system został sprawdzony oraz zostały wykonane liczne testy. Błąd, który Pan wskazał został wyfiltrowany nie nosi on znamion krytycznego.  Problem występował w jednym miejscu, nie stanowił zagrożenia zarówno dla  bezpieczeństwa danych użytkowników jak i bezpieczeństwa samego systemu.

2 thoughts on “Addslashes() w służbie bezpieczeństwa przed XSS?… NIE!

  1. Wydaje mi się, że addslashes jednak jest w służbie bezpieczeństwa sql injection… bo do xss nie trzeba slaszy wykorzystywać.

    Dla osób które zawiniły zawsze coś jest „nie krytyczne”… -,-

Skomentuj HakerEduPL Anuluj pisanie odpowiedzi

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *