Ciekawostka: uparty XSS
Prosta historia – w aplikacji wykryto XSS, według programistów błąd został usunięty poprzez wprowadzenie encodingu wartości parametrów na wejściu. Przy reteście okazuje się, że XSS nadal jest. Co poszło nie tak?
Przede wszystkim na wejściu powinna być walidacja, a nie encoding. Encoding powinien być stosowany bezpośrednio przed tym, kiedy input będzie używany. W przeciwnym wypadku zastosowany encoding może być niewłaściwy dla kontekstu, w którym dane będą użyte. Takie podejście to proszenie się o problemy, nie tylko problemy security, ale również najnormalniej problemy funkcjonalne. Ale tym razem nie tutaj był problem.
Jakieś pomysły? Nie? To podpowiem:
(...) błąd został usunięty poprzez wprowadzenie encodingu wartości parametrów na wejściu (...)
A co z nazwą parametru? Nazwa jest bezpieczna, prawda? No właśnie nie.
Jeśli aplikacja pobiera określone parametry z requestu (po nazwie), wówczas nazwa parametru nie jest kontrolowana przez atakującego, o payloady w nazwach parametrów nie trzeba się martwić, bo nieznane parametry zostaną po prostu zignorowane.
Ale co się stanie, gdy aplikacja zapragnie z jakiegoś powodu parametry przekazane w kroku pierwszym przekazać do kroku drugiego jako pola hidden? Jak? Poprzez pobranie z requestu listy kontrolowanych przez użytkownika nazw parametrów, a następnie wypisanie wartości parametru dla każdego parametru z listy.
Efekt? XSS. Kurtyna. Oklaski.
Oryginał tego wpisu dostępny jest pod adresem Ciekawostka: uparty XSS
Autor: Paweł Goleń