O ile SQLi w formatce logowania nie jest zbyt powszechny, przynajmniej nie był w tej próbce aplikacji, które miałem okazję testować, to XSS w loginie użytkownika zdarzał się już częściej (patrz: Lekcja 21: Przykład - phishing na formatce logowania z wykorzystaniem XSS).
Okazuje się, że ten przykład również jest "zaimplementowany" w Altoro Mutual. I tak, ktoś musiał się odrobinę postarać by taki błąd tam umieścić, ponownie odsyłam do mojego dawnego wpisu Niekonsekwencje w ASP.NET.
Generalnie samo ASP.NET dba o to, by w tekście pól input XSS nie było, oczywiście jeśli ktoś używa standardowej kontrolki. A jak jest tutaj?
<input name="uid" id="uid" style="width: 150px;" type="text" value="">
Tak, w pewnej chwili (jeśli aplikacji w ASP.NET przetestowało się wystarczająco wiele) intuicyjnie widać, że najprawdopodobniej nie jest to standardowa kontrolka ASP.NET, tylko coś robionego "ręcznie". Po prostu narzędzia używane do tworzenia stron (np. Visual Studio) mają pewną konwencję nazewniczą kontrolek, a ta formatka (to pole) ewidentnie jej nie stosuje.
Dobrze, po pierwsze sprawdźmy co się stanie, gdy do strony login.aspx przekaże się w parametrze nazwę użytkownika: http://demo.testfire.net/bank/login.aspx?uid=pmq'"<>.
<input type="text" id="uid" name="uid" value="pmq'"<>" style="width: 150px;">
A teraz zobaczmy dlaczego tak jest, w końcu możemy czytać dowolny plik, prawda?
<input type="text" id="uid" name="uid" value="<%=GetUserName()%>" style="width: 150px;">
Czyli tak jak mówiłem, nie jest to standardowa kontrolka, nazwa użytkownika jest wpisywana bezpośrednio. Dla porządku zobaczmy co się dzieje w funkcji GetUserName:
protected string GetUserName()
{
HttpCookie UserInfo = Request.Cookies["amUserInfo"];
if (Request.Params["uid"] != null) {
return Request.Params["uid"].ToString();
}
if (UserInfo != null) {
return new Base64Decoder(UserInfo["UserName"]).GetDecoded();
} else {
return "";
}
}
Czyli można jeszcze sprawdzić co się stanie, gdy payload XSS zostanie osadzony w Cookie...
