Statyczna analiza bezpieczeństwa kodu aplikacji (część 3.) — FxCop

FxCop

FxCop, podobnie jak omówiony w poprzedniej części CAT.NET, analizuje kod pośredni aplikacji w celu znalezienia najpopularniejszych błędów programistycznych. FxCop wykrywa uchybienia związane ze złym użyciem interfejsów, niepoprawnym zwalnianiem zasobów, złą konwencją nazewniczą, niewydajnymi konstrukcjami. Posiada też szereg testów związanych bezpośrednio z bezpieczeństwem aplikacji.

FxCop obecnie występuje wyłącznie jako narzędzie konsolowe, chociaż w starszych wersjach dodawano również nakładkę GUI. FxCop jest dostępny jako element Visual Studio oraz Windows SDK — jest to sprawa nieco zagmatwana, która zostanie wyjaśniona w jednym z kolejnych paragrafów.

Więcej informacji o FxCop można uzyskać, odwiedzając dedykowaną stronę w dokumentacji MSDN. Nas z pewnością interesuje głównie aspekt bezpieczeństwa aplikacji, więc sprawdźmy, co oferuje nam nowo poznane narzędzie.

FxCop w kontekście bezpieczeństwa

FxCop posiada parędziesiąt testów bezpieczeństwa, które wykrywają zarówno podstawowe, jak i bardzo specyficzne błędy. Niektóre testy dotyczą klasycznych luk w oprogramowaniu, takich jak błędy wstrzyknięcia kodu SQL, niektóre zaś bardzo szczegółowo wchodzą w naturę frameworku .NET i bibliotek systemowych.

Lista testów bezpieczeństwa przeprowadzanych przez FxCop dostępna jest w witrynie MSDN (można tam również doczytać o innych kategoriach testów). Dokumentacja jest bardzo szczegółowa — opisywana jest natura każdego błędu, cele weryfikacji, przykłady poprawnego i niepoprawnego kodu, metody poprawy błędów. Dokumentacja jest więc bardzo przydatna i warto do niej zaglądać.

Aby poznać bliżej charakter narzędzia i sposób przeprowadzanej analizy, przyjrzyjmy się jednej z reguł w dokumentacji, przykładowo błędowi CA2100: Review SQL queries for security vulnerabilities.

Reguła CA2100 sprawdza, czy zapytanie SQL w formie ciągu tekstowego jest odpowiednio bezpiecznie przygotowane. Dokumentacja MSDN pokazuje dwa przypadki:

string query = "SELECT TOP " + x.ToString() + " FROM Table";

string query = String.Format("SELECT TOP {0} FROM Table", x);

W pierwszej linii do ciągu tekstowego doklejana jest zmienna, na której bezpośrednio używana jest metoda ToString(). Jest to niebezpieczna praktyka mogąca powodować lukę bezpieczeństwa i zostanie ona zgłoszona przez FxCop jako błąd z rodziny CA2100. Tutaj nie ma żadnych niespodzianek.

Drugi przypadek jest już bardziej skomplikowany, ponieważ metoda ToString() wywoływana jest niejawnie. Oczywiście w tym fragmencie również występuje luka bezpieczeństwa, więc również zostanie zgłoszony błąd CA2100. Jak widać narzędzie wcale nie jest głupie i wykrywa nie tylko najbardziej rzucające się w oczy błędy. Dokumentacja MSDN pokazuje metody usunięcia usterki z kodu — w przypadku błędów SQL Injection Microsoft zaleca użycie zapytań parametryzowanych.

Oczywiście, jeśli zapytania zostaną enkapsulowane lub transformowane przez różnego rodzaju biblioteki lub narzędzia istnieje spora szansa, że FxCop nie wykryje tego rodzaju błędów. Statyczna analiza kodu nie zastępuje inżyniera bezpieczeństwa przeprowadzającego ręczną inspekcję kodu.

FxCop jako element Visual Studio

Program FxCop w wersji 11. dostępny jest jako element przystawki analizy kodu (Code Analysis) w Visual Studio 2012/2013 Professional oraz Ultimate. Darmowe edycje Express posiadają wyłącznie uproszczoną wersję Code Analysis.

FxCop od wersji 11. dostarczany jest wyłącznie w wersji konsolowej, chociaż w przeszłości istniały jeszcze wersje z graficznym interfejsem użytkownika. GUI FxCop po prostu okazało się zbędne, gdyż od dłuższego czasu narzędzie do analizy kodu Visual Studio jest oparte właśnie na FxCop, co oznacza, że całą analizę można wyklikać z poziomu IDE.

Uruchomienie analizy z poziomu solucji Visual Studio jest bardzo proste i zostało zilustrowane na rysunku 1. Wszystko, co trzeba zrobić, to z menu Build wybrać opcję Run Code Analysis (na wybranym projekcie lub całej solucji) i poczekać na przebudowanie projektu oraz analizę. W panelu Code Analysis zostaną pokazane uwagi zwrócone przez narzędzie.

Rysunek 1. Uruchamianie FxCop przez Visual Studio 2013.

Trzeba pamiętać, że domyślne ustawienia reguł FxCop nie przeprowadzają wszystkich możliwych testów z każdej kategorii, włączając w to kategorię bezpieczeństwa. Zbiór testowanych reguł może być zdefiniowany w pliku konfiguracyjnym lub we właściwościach solucji. Drugi wariant widać na rysunku 2., który pokazuje sposób konfiguracji predefiniowanych reguł dla każdego projektu w solucji Visual Studio. Aby wykonać wszystkie testy, należy wybrać opcję Microsoft All Rules (lub Microsoft Security Rules, jeśli chcemy wykonać wyłącznie wszystkie testy z kategorii bezpieczeństwa). Zbiory reguł znajdują się w katalogu RuleSet Visual Studio, ale o tym za chwilę.

Rysunek 2. Konfiguracja reguł FxCop dla każdego projektu w solucji Visual Studio.

1. FxCopCmd.exe

Dla inżynierów bezpieczeństwa oraz testerów automatyzujących pracę przystawka FxCop w Visual Studio nie wnosi zbyt wiele. Dla tych osób dużo bardziej wartościowe są narzędzia, które można uruchomić z poziomu konsoli, dzięki czemu automat można zintegrować z wieloma innymi narzędziami.

Zdecydowanie najłatwiejszym sposobem pozyskania FxCop jest instalacja Visual Studio i wyłuskanie binarek z katalogu instalacji IDE. FxCop w wersji 11. znajduje się w następujących ścieżkach domyślnych:

• C:\Program Files (x86)\Microsoft Visual Studio 11.0\Team Tools\Static Analysis Tools\FxCop\ (Visual Studio 2012),
• C:\Program Files (x86)\Microsoft Visual Studio 12.0\Team Tools\Static Analysis Tools\FxCop\ (Visual Studio 2013).

Obecnie najnowszą wersją jest FxCop 11., którego używa Visual Studio 2012 oraz 2013. Visual Studio 2010 używa jeszcze FxCop 10. — program ten można znaleźć jeszcze w Windows SDK 7.1 — ale o tym jeszcze sobie powiemy. Narzędzie z numerem dziesiątym jest gorsze od swojego młodszego brata — pracuje wolniej i posiada mniej reguł — jednak dalej można używać go w produkcji. Wcześniejsze wersje FxCop nosiły  numery 1.36 oraz 1.35 i nie zaleca się ich używania.

2. Struktura programu FxCop

Konsolowy program FxCopCmd.exe jest głównym elementem narzędzia, przez które wywołujemy testy — można go znaleźć w katalogu FxCop.

Kolejnym ważnym elementem FxCop, oprócz samych silników wyszukiwania (zlokalizowanych w katalogu FxCop\Engines), są reguły, umieszczone w katalogu FxCop\Rules.

W wersji FxCop 11. domyślnie instalowane reguły sprawdzają następujące elementy programu:

• DataflowRules.dll —przepływ danych (nowość FxCop 11),
• DesignRules.dll — poprawność wykorzystania bibliotek zgodnie z zaleceniami .NET Framework Design Guidelines,
• GlobalizationRules.dll — rozwiązania lokalizacji (L10n) i internacjonalizacji (i18n),
• InteroperabilityRules.dll — interakcje z klientami COM,
• MaintainabilityRules.dll — problemy powodujące duże koszty utrzymania aplikacji, np. zbyt duża złożoność pętli czy zbyt skomplikowane dziedziczenie,
• MobilityRules.dll — problemy z nieefektywnym zużyciem energii,
• NamingRules.dll — podstawowe testy zgodności nazw z konwencjami nazewniczymi,
• PerformanceRules.dll — wskazówki dotyczące problemów wydajnościowych, np. nieużywane zmienne lokalne czy wskazówki efektywnego użycia funkcji popularnych bibliotek,
• PortabilityRules.dll — problemy z przenośnością kodu,
• ReliabilityRules.dll— testy powodujące błędy pamięci lub wątków
• SecurityRules.dll — najważniejsze reguły w kontekście bezpieczeństwa .NET,
• SecurityTransparencyRules.dll — testy dotyczące użycia tzw. Security-Transparent Code wprowadzonego w .NET 2.0 i rozszerzonego w .NET 4.0 (nowość FxCop 11),
• UsageRules.dll — testy sprawdzające poprawność użycia wielu popularnych .NET Framework.

Jeśli mowa o regułach, warto również zwrócić uwagę na następujący katalog Visual Studio:

C:\Program Files (x86)\Microsoft Visual Studio xx.0\Team Tools\Static Analysis Tools\Rule Sets\

W powyższym katalogu znajdują się zbiory reguł *.ruleset — są to pliki xml definiujące rodzaj testów FxCop dla projektów Visual Studio. Reguły z tego katalogu widoczne są we właściwościach solucji, tak jak pokazano to na rysunku 2.

Trzeba pamiętać, że zbiory reguł z katalogu Rules/*.dll są przystosowane do konkretnej wersji FxCop i nie wolno ich mieszać. Oznacza to, że np. reguły z FxCop 10. nie działają w FxCop 11.

3. FxCop standalone — czy potrafisz go znaleźć?

FxCop w wersji „standalone” jest dostępny jako element Windows SDK — przynajmniej taka informacja podawana jest na blogach Microsoft. Niestety gigant nie ma w zwyczaju ułatwiania życia programistom oraz administratorom, więc również i w tym wypadku ściągniecie instalatora FxCop wymaga sporej gimnastyki.

Ze względów licencyjnych trudno w sieci znaleźć bezpośredni link do instalatorów lub binarek FxCop w którejkolwiek wersji. Zostaje więc własnoręczna instalacja narzędzia, którą należy zacząć od ściągnięcia Windows SDK, najlepiej w wersji Windows 7 (nawet mimo pracy na innych systemach). Opis oraz odnośniki do instalatorów dla poszczególnych wersji SDK w przejrzysty sposób opisuje angielska Wikipedia.

Po znalezieniu SDK należy ściągnąć pliki instalacyjne na dysk przez wybranie odpowiedniej opcji instalatora .msi — zamiast instalować SDK, chcemy je po prostu najpierw ściągnąć na dysk. Na końcu należy ręcznie wydobyć instalator FxCop z pliku .cab, co zostało opisane na wielu blogach (np. tutaj lub tutaj).

W taki sposób jesteśmy w stanie stać się szczęśliwym posiadaczem FxCop, jednak w wersji 10. (w wypadku SDK 7.1). W nowszych wersjach SDK, np. dla systemu Windows 8.1, zrezygnowano z dodania FxCop (mimo informacji, że istnieje w SDK) — Microsoft tłumaczy się odchudzaniem pakietów SDK oraz przeniesienia FxCopa do paczek Visual Studio.

Niestety okazuje się, że zamiast przechodzić przez piekiełko Microsoftu, najlepiej pozyskać binarki od znajomego programisty .NET lub po prostu ściągnąć wersję testową Visual Studio. Gdy już będziemy szczęśliwymi posiadaczami FxCop — warto zachować go w osobnym miejscu, aby nie przechodzić przez wszystko od nowa.

Przykład użycia

W pocie czoła przeszliśmy przez „instalację” FxCop, sprawdźmy teraz, w jaki sposób narzędzie poradzi sobie w naszym środowisku testowym.

Analiza przy wykorzystaniu FxCopCmd jest bardzo prosta i w większości wypadków polega na podaniu następujących parametrów:

• /file — zestaw plików do analizy, akceptowany jest znak gwiazdki (*) w celu wyboru kilku plików pasujących do wzorca (przełącznik może być użyty wielokrotnie);
• /rule — lokalizacja pliku .dll z regułami  lub ścieżka do katalogu z regułami (przełącznik może być użyty wielokrotnie);
• /out — nazwa pliku raportu będącego plikiem xml.

Analiza programem FxCop jest bardzo szybka i nie powinna zabrać więcej niż kilkanaście sekund, nawet przy skomplikowanych projektach. Listę wszystkich przełączników wraz z dokładnym opisem można znaleźć na stronach MSDN.

Znając powyższe opcje, przeprowadzimy analizę aplikacji HacmeBank_v2, przedstawioną w części 2. Aby to zrobić, wystarczy uruchomić narzędzie FxCopCmd ze wskazaniem testowanych bibliotek. Przy wykorzystaniu przełączników /file możemy za jednym podejściem wybrać zarówno pliki .dll z web aplikacji, jak i z web serwisów.

W związku z tym, że testowana aplikacja posiada bardzo zaniedbany kod, ograniczmy analizę wyłącznie do kluczowych testów bezpieczeństwa. W tym celu przełącznikiem /rule wskazujemy regułę SecurityRules.dll. Plik raportu zapiszemy do lokalizacji zdefiniowanej przez przełącznik /out.

Ostatecznie wywołanie analizatora kodu dla całej solucji testowej wygląda następująco:

E:\bridge\Tools\FxCop>FxCopCmd.exe /out:"HackMeBank-FxCopReport.xml" /file:"E:\Source Hacme Bank v2.0\HacmeBank_v2_Website\bin\*.dll" /file:"E:\Source Hacme Bank v2.0\HacmeBank_v2_

WS\bin\*.dll" /rule:Rules\SecurityRules.dll

Wyniki powyższego polecenia przedstawia rysunek 3.:

Rysunek 3. Analiza FxCop z poziomu konsoli.

Raport zwrócony przez narzędzie wskazuje wiele błędów — nie jest niespodzianką, że istnieją duplikaty. Co ciekawe w raporcie nie znalazła się luka SQL Injection, którą wykrył w poprzedniej części CAT.NET — widocznie wywołanie metod bazodanowych jest tutaj zbyt zagmatwane. Trzeba nadmienić, że błędy XSS (które również wykrył CAT.NET) nie są sprawdzane przez FxCop. Raport skupia się na opisywaniu uwag bardzo specyficznych dla języka .NET. Wskazówki i dokładny opis przyczyny błędu powodują, że z tego narzędzia również można wiele wynieść.

Zainteresowanym osobom polecam przejrzenie raportu i wyciągnięcie z niego wniosków o rodzajach uchybień w kontekście bezpieczeństwa zwracanych przez FxCop. W analizie raportu przyda się m.in. dokumentacja MSDN o błędzie CA2102.

ASP.NET Security Rules

FxCop ASP.NET Security Rules jest inicjatywą tworzoną w duchu Open Source. Jest to zbiór dodatkowych reguł dla FxCop 10., które pozwalają przeprowadzać analizę bezpieczeństwa projektów ASP.NET oraz ASP.NET MVC.

ASP.NET Security Rules wprowadza parędziesiąt przydatnych testów, które głównie sprawdzają wykonanie podstawowego hardening projektu w pliku web.config. Analizowane są również atrybuty, takie jak choćby atrybuty wprowadzające tokeny anty-CSRF w aplikacjach MVC i kilka innych.

Lista nowych testów, których nazwy jasno opisują ich cel, jest następująca:

• EnableEventValidationShouldBeTrue,
• ValidateRequestShouldBeEnabled,
• ViewStateEncryptionModeShouldBeAlways,
• EnableViewStateMacShouldBeTrue,
• EnableViewStateShouldBeTrue,
• ViewStateUserKeyShouldBeUsed,
• DebugCompilationMustBeDisabled,
• CustomErrorPageShouldBeSpecified,
• FormAuthenticationShouldNotContainFormAuthenticationCredentials,
• EnableCrossAppRedirectsShouldBeTrue,
• FormAuthenticationProtectionShouldBeAll,
• FormAuthenticationRequireSSLShouldBeTrue,
• FormAuthenticationSlidingExpirationShouldBeFalse,
• HttpCookiesHttpOnlyCookiesShouldBeTrue,
• HttpCookiesRequireSSLShouldBeTrue,
• TraceShouldBeDisabled,
• AnonymousAccessIsEnabled,
• RoleManagerCookieProtectionShouldBeAll,
• RoleManagerCookieRequireSSLShouldBeTrue,
• RoleManagerCookieSlidingExpirationShouldBeTrue,
• PagesEnableViewStateMacShouldBeTrue,
• PagesEnableEventValidationMustBeTrue,
• HttpRuntimeEnableHeaderCheckingShouldBeTrue,
• PagesValidateRequestShouldBeEnabled,
• PagesViewStateEncryptionModeShouldBeAlways,
• CustomErrorsModeShouldBeOn,
• MarkVerbHandlersWithValidateAntiforgeryToken,
• ControllerActionShouldValidateInput.

Użycie powyższych reguł jest bardzo proste: projekt reguł wystarczy ściągnąć ze strony Codeplex i przekopiować pliki: AspNetConfigurationSecurityRules.dll, AspNetMvcSecurityRules.dll oraz AspNetSecurityRules.dll do wybranego folderu, najlepiej do FxCop/Rules. Następnie podczas uruchamiania testów wystarczy wskazać nazwę powyższych bibliotek przez przełącznik /rule.

Niestety reguły dostarczone w projekcie są zgodne wyłącznie z FxCop w wersji 10. i nie mogą być uruchamiane w nowszych wersjach narzędzia (w szczególności z FxCop 11. z Visual Studio 2012/2013). Należy więc zaopatrzyć się w wersję FxCop 10., którą można między innymi ściągnąć przez Windows SDK 7 w opisany powyżej sposób.

ASP.NET Security Rules dodaje wiele przydatnych testów i uczy zwracania uwagi na hardening projektu już we wczesnej fazie wytwarzania aplikacji. Niestety, projekt od 2010 roku nie jest rozwijany i skuteczność powyższych testów maleje wraz z rozwojem chociażby frameworku MVC. Obecnie reguły potrafią dręczyć błędami false positive, jednak i tak warto z nich korzystać.

Wdrożenie do projektów

FxCop, a w zasadzie narzędzie do analizy kodu Visual Studio, jest obecne w większości projektów .NET i wystarczy je tylko odpowiednio przystosować. Jeśli nawet FxCop nie jest używany w Twoim projekcie, jego włączenie jest bardzo proste, oczywiście gdy potrafisz go znaleźć :).

FxCop, dzięki FxCopCmd, może z powodzeniem trafić jako element narzędzi sprawdzających codzienną pracę programistów lub jako element skryptów budujących (msbuild). W kontekście bezpieczeństwa, FxCop nie posiada bardzo dużej liczby testów, jednak nawet najmniejszy błąd wykryty we wczesnym stadium wart jest inwestycji w to narzędzie. FxCop przydaje się nie tylko inżynierom bezpieczeństwa, ale również programistom — przy tak dużej liczbie różnego rodzaju testów aplikacja będzie dużo stabilniejsza, dzięki czemu i bezpieczniejsza.

Warto zainteresować się również projektem ASP.NET Security Rules, który wprowadza dodatkowe testy bezpieczeństwa projektów ASP. Obecnie najlepszym wyjściem jest stosowanie dwóch FxCopów: w wersji 11. dla wszystkich wbudowanych reguł oraz osobnego w wersji 10., sprawdzającego wyłącznie reguły bezpieczeństwa ASP. Jest to tylko jedna komenda więcej do uruchomienia, a błędy wykrywane już podczas pisania kodu, szybko zwrócą czas zainwestowany w automatyzację procesu bezpieczeństwa.

 Adrian “Vizzdoom” Michalczyk