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?
Ciekawostka: uparty XSS
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.
