Paweł Goleń, blog

Bezpieczeństwo w standardzie

Microsoft wciąż nie ma zbyt dobrej opinii jeśli chodzi o kwestie związane z bezpieczeństwem. Moim zdaniem niesłusznie. Praca jaką wykonała ta firma naprawdę robi wrażenie. Wdrożenie SDL czy modelowanie zagrożeń naprawdę owocuje lepszymi produktami. Pomijając to, ASP.NET pojawiło się trochę później niż konkurencja, w produkcie uwzględnione zostało kilka spraw związanych z bezpieczeństwem, które są problematyczne w innych środowiskach.

Kilka przykładów

Wymienię tylko kilka przykładów ciekawych rozwiązań:

• mechanizm validateRequest oraz łatwość tworzenia walidatorów,
• identyfikatory "lokalne",
• mechanizm eventValidation,

validateRequest i walidatory

Samo validateRequest to w pewnym stopniu technologia automagiczna. Nie jest w 100% skuteczna, można ją obejść, aczkolwiek jest fajną pierwszą linią obrony. Dodatkowo tworzenie walidatorów w ASP.NET jest dość proste, o czym można poczytać na przykład tu. W rezultacie muszę stwierdzić, że w przypadku próbki aplikacji, które miałem okazję testować, statystycznie trudniej było przemycić XSS w przypadku ASP.NET, niż w przypadku J2EE.

Identyfikatory lokalne

W aplikacjach tworzonych w ASP.NET kilka razy spotkałem się ze sprytną techniką obsługi wszelkich list prezentowanych użytkownikowi. Każdy z elementów miał swój identyfikator lokalny na danej liście. W innych rozwiązaniach często są wykorzystywane identyfikatory globalne, na przykład id będące kluczem w bazie danych. Zmusza to programistę (albo i nie, w końcu kto będzie zmieniał jakieś identyfikatory?!) do zbudowania warstwy, która kontroluje, czy dany użytkownik ma prawo dostępu do danego elementu. W przypadku, gdy te identyfikatory są "lokalne" powierzchnia ataku jest znacznie zmniejszona. Mogę sobie modyfikować identyfikatory do skutku - nic mi to nie da...

Nie jestem programistą ASP.NET, nie wiem dokładnie jak to jest robione. Mam wrażenie, że jest to funkcja kontrolki prezentującej dane. Oczywiście, zawsze można to zepsuć. Trafiła się i aplikacja w ASP.NET, w której ta technika nie była stosowana, wykorzystywane były identyfikatory globalne, a kontrola dostępu po prostu nie istniała. Cóż, technologia nie zastąpi myślenia...

eventValidation

Formatki to nie tylko pola do wpisywania danych, ale również różnego rodzaju pola wyboru jedno lub wielokrotnego, czy "dropdowny". Bardzo często w przypadku tego typu pól walidacja nie jest przeprowadzana. Być może programiści są przekonani, że otrzymają tylko te wartości, które sami wcześniej wypisali na stronę (w pole dropdown). Problem w tym, że tak wcale nie musi być.

W ASP.NET jest mechanizm EventValidation, który ten problem może nie "rozwiązuje", ale ułatwia jego rozwiązanie. Po prostu istnieje mechanizm, który sprawdza, czy otrzymane zdarzenie (bo ASP.NET w znacznym stopniu jest oparte o zdarzenia) mogło zostać wygenerowane przez stronę, z której zostało odebrane. Dla przykładu jeśli w polu dropdown są cztery elementy indeksowane od 0 do 3, to otrzymanie z niego wartości 4 spowoduje wyjątek.

A skąd wiadomo jakie zdarzenia mogą być generowane przez daną stronę? Cóż, proponuję zajrzeć do kodu strony. Są tam dwa dodatkowe ukryte pola. Pierwsze z nich to __VIEWSTATE, drugie to __EVENTVALIDATION. I właśnie w polu __EVENTVALIDATION zaszyte są informacje potrzebne do weryfikacji zdarzenia. Co ciekawe akurat ten mechanizm wydaje mi się niezbyt dobrze udokumentowany. Najlepszy opis, który kiedyś znalazłem znajduje się tu. Przy czym akurat głównym tematem wpisu jest nie sam mechanizm, lecz problemy jakie powoduje on przy wykorzystaniu AJAX.

I by nie było zbyt różowo...

Czasami rozczulają mnie programiści, którzy "wrzucają" do __VIEWSTATE wszystko, co się rusza. Pominę fakt, że strony ładują się wówczas nieco przydługo, ale też zdarza się ujawnienie pewnych informacji. Jak? Na przykład jest sobie kontrolka, która prezentuje zawartość jakiejś tabeli. Z różnych względów prezentowana jest tylko część kolumn, bo dane zawarte w innych kolumnach są nieprzeznaczone dla wszystkich. Tylko z uwagi na sposób oprogramowania kontrolki dane z tych ukrytych kolumn i tak trafiają do __VIEWSTATE. Znalezienie ViewState Decoder nie jest jakimś strasznym zadaniem. Swoją drogą poza tym, że __VIEWSTATE jest chronione przez HMAC (integralność, ale warto zapoznać się z tym wątkiem), to jest również możliwość jego szyfrowania. Nie zmienia to jednak faktu, że ładowanie wszystkiego do __VIEWSTATE jest głupie.