FxCop  analiza kodu
w .NET
Obrona
Artur Żarski
stopień trudności
Tworzenie oprogramowania jest bardzo złożonym procesem,
bardzo trudno jest napisać aplikację, która będzie pozbawiona
błędów, a co za tym idzie  bezpieczna. Ogromny nacisk
kładziony jest więc na to, aby oprogramowanie zawierało tych
błędów jak najmniej.
apewnienie odpowiedniej jakości kodu, FxCop dysponuje graficznym interfejsem użyt-
czy to przy pomocy różnych metodologii kownika, ale jest też narzędziem dostępnym
Z(np. Extreme Programming), okresowego z wiersza polecenia. Zawiera także pakiet
sprawdzania i analizy kodu (code reviews), czy SDK umożliwiający tworzenie niestandardowych
też kombinacji różnych podejść, jest procesem reguł.
kosztownym i długotrwałym. Jego automatyza-
cja i wplecenie w cykl życia aplikacji, pomimo Jakość tworzonego kodu
iż nie wyeliminuje do końca ingerencji człowie- Kiedy mówimy o tworzeniu bezpiecznego opro-
ka  a także samych błędów  zdecydowanie gramowania, musimy zacząć od samych pod-
usprawnia proces i zwiększa efektywność pra- staw, czyli od jakości tego, co napisaliśmy. Ma
cy całego zespołu. Tu przychodzą nam z pomo- ona fundamentalne znaczenie w przypadku, gdy
cą narzędzia do statycznej analizy kodu, a wśród nasza aplikacja jest kluczowa dla firmy. Spraw-
nich aplikacja FxCop. dzeniem jakości naszego kodu zajmuje się spe-
FxCop jest narzędziem do analizy kodu, cjalna dziedzina inżynierii oprogramowania, nie-
które sprawdza zgodność elementów kodu za- mniej jednak jako programiści sami jesteśmy
rządzanego .NET z wytycznymi projektowymi
dla platformy .NET (Microsoft .NET Framework
Z artykułu dowiesz się
Design Guidelines). Narzędzie wykorzystuje me-
chanizm refleksji, parsowanie MSIL oraz analizę
" jak działa i czym jest narzędzie FxCop,
grafu wywołań do sprawdzenia elementów pod
" czym jest analiza kodu.
kątem występowania ponad 200 często spotyka-
nych wad w następujących obszarach:
Co powinieneś wiedzieć
" projekt bibliotek,
" należy znać zagadnienia związane z programo-
" lokalizacja, waniem przy użyciu platformy .NET ,
" wiedzieć, jak poruszać się w środowisku Visual
" konwencje nazewnictwa,
Studio.
" wydajność,
" bezpieczeństwo.
hakin9 Nr 12/2007
52 www.hakin9.org
FxCop  analiza kodu w .NET
w stanie określać reguły, którym pod-
Listing 1. Definicja reguły w pliku XML
lega tworzony kod aplikacji. Do tego
celu możemy wykorzystać mecha-

nizm statycznej analizy kodu. Okre-

ślenie statyczna analiza kodu to Reguła używana, kiedy pojawiają się puste nazwy
Tutaj nasz opis
specjalny etap kompilacji naszego
Link do opisu
programu, w trakcie którego przy
Sposób rozwiązania
pomocy odpowiednich reguł spraw-
email do osoby odpowiedzialnej
dzane jest to, co napisaliśmy. Regu-
Error
ły te opisują, co jest prawidłowe i jak Breaking
Informacje o właścicielu reguły
powinien wyglądać nasz kod z
ródło-

wy, aby był poprawny i bezpieczny

z naszego punktu widzenia.
FxCop w działaniu
No dobrze, jeśli już dowiedzieliśmy
się czegoś na temat jakości kodu
oraz jego statycznej analizy, to nie
pozostaje nam nic innego jak tylko
napisanie czegoś co pozwoli ana-
lizować i sprawdzać nasz kod. Jest
to wykonalne, ale bardzo skompliko-
wane do oprogramowania. Dlaczego
jest to takie trudne? Ponieważ bar-
dzo często zdarza się, że ten sam
problem może być opisany w różny
sposób. Z pomocą przychodzą nam
kody operacji języka pośredniego
(Intermediate Language). Ich zapis
po stronie systemu operacyjnego,
po kompilacji, jest bardziej przewi-
dywalny i bardziej jednoznaczny niż
Rysunek 1. Okno Code Analysis w VisualStudio
sam kod z
ródłowy, nawet przy uży-
ciu różnych języków programowania Reguły w FxCop da działania dotyczy FxCop. Narzę-
dostępnych w platformie .NET. Jak już wcześniej wspominaliśmy, dzie to zawiera standardowo wbudo-
W taki właśnie sposób  przy analiza składni polega na sprawdze- wane pewne reguły określające, jak
pomocy analizy kodu pośredniego niu kodu według wcześniej określo- powinien wyglądać nasz kod. Regu-
 działa narzędzie pod nazwą FxCop. nych reguł. Dokładnie ta sama zasa- ły te są umieszczone w kilku grupach
Tabela 1. Grupy reguł dla FxCop
Grupa Zakres analizy
Design Poprawność architektury bibliotek pod kątem zgodności z zasadami nakre-
ślonymi w dokumencie Design Guidelines for Class Library Developers
Globalization Globalizacja, czyli gotowość aplikacji do lokalizacji
Interoperability Współpraca z kodem niezarządzanym (głównie COM)
Maintainability Konserwacja kodu
Naming Zgodność z konwencjami nazewniczymi opisanymi w dokumencie Design
Guidelines for Class Library Developers
Performance Wydajność kodu
Reliability Niezawodność aplikacji oraz odporność na problemy, np. związane z ilością
użytej pamięci
Security Bezpieczeństwo
Usage Poprawne użycie .Net Framework
y
ródło: http://msdn2.microsoft.com/en-us/library/ee1hzekz(VS.80).aspx
www.hakin9.org hakin9 Nr 12/2007 53
Obrona
funkcjonalnych. Tabela 1. zawiera
zestawienie grup wraz ze specyfika-
Pełna lista możliwych parametrów
cją, jakiemu zakresowi analizy pod-
legają umieszczone reguły. public virtual ProblemCollection Check(Member member);
public virtual ProblemCollection Check(Module module);
Sama reguła jest tylko jednym
public virtual ProblemCollection Check(Parameter parameter);
z elementów całej analizy. Istotną
public virtual ProblemCollection Check(Resource resource);
sprawą jest stwierdzenie, czy to
public virtual ProblemCollection Check(TypeNode type);
co dana reguła wykryje, jest waż-
public virtual ProblemCollection Check(string namespaceName,
ne, czy nie i jak to zdarzenie zakla-
TypeNodeList types);
syfikować. W związku z tym musi-
my określić jeszcze dwa parametry.
Są nimi poziom istotności oraz pew-
ność. Występują trzy główne czynni- zweryfikowane na podstawie staty- informację o rodzaju reguły, jej naz-
ki determinujące poziom istotności: cznej analizy. Współczynnik pew- wie, identyfikatorze oraz poziomie
ności określany jest w procentach pewności.
" widzialność znalezionego pro- (0-99%). Im wyższa wartość, tym W drugim kroku tworzymy biblio-
blemu, większe prawdopodobieństwo, że tekę, do której dodajemy następują-
" prawdopodobieństwo tego, czy dana reguła poprawnie identyfiku- ce referencje:
wykryty problem będzie miał ne- je problem.
gatywny skutek na całość apli- using Microsoft.Cci;
kacji i jej zachowania, Własne reguły using Microsoft.FxCop.Sdk;
" ryzyko powiązane z nie napra- Bardzo dobrze, jeśli proces spraw- using Microsoft.FxCop.Sdk.Introspect
wieniem problemu. dzania naszego oprogramowania jest ion;
w pełni opisany dostarczonymi regu-
Dodatkowo każda reguła musi cecho- łami. Zdarzają się jednak sytuacje, oraz tworzymy klasę o nazwie takiej
wać się jednym z pięciu poziomów kiedy standardowe opcje nam nie wy- jak nazwa reguły:
istotności. Poziomy te przedstawiają starczają. W takim przypadku mamy
się następująco: możliwość dopisania własnej reguły public class RegulaPusteNazwy :
i podpięcia jej do istniejącego zesta- BaseIntrospectionRule
" Critical Error (Błąd krytyczny) / wu. Jak się do tego zabrać? W tym
Error (Błąd)  wiadomości, któ- celu pomocne są dwie biblioteki: Następnie musimy zaimplementować
rym nadano ten poziom, dotyczą FxCopSdk.dll oraz Microsoft.Cci.dll. obsługę sprawdzania danej reguły, nad-
problemów, które mogą zagrozić Proces tworzenia nowej reguły pisując w tym celu metodę Check. Jej
stabilności kodu, składa się z dwóch etapów. Pierw- parametrem może być moduł, para-
" Critical Warning (Ostrzeżenie kry- szy z nich to stworzenie definicji metr, zasób, etc. Pełna lista możliwych
tyczne) / Warning (Ostrzeżenie) reguły  określonej w pliku XML parametrów znajduje się w Ramce.
 w tej grupie problemy zwykle  oraz napisanie kodu, który będzie Ostatnim krokiem jest kompilacja
nie dotyczą stabilności aplikacji. realizował sprawdzenie danej reguły. biblioteki i umieszczenie jej w katalo-
Niemniej jednak powinny zostać Plik XML powinien wyglądać tak, gu z innymi regułami (FxCop\Rules),
dokładnie przeanalizowane pod jak na Listingu 1. i powinien zawierać a także przetestowanie jej.
kątem optymalności kodu,
" Informational (Informacja)  sto-
sowany do wiadomości, które
dostarczają jedynie informacji
o przedmiocie analizy, nie iden-
tyfikują zaś potencjalnych proble-
mów z nim związanych.
Współczynnik pewności określa praw-
dopodobieństwo, z jakim problem zo-
stał poprawnie zidentyfikowany. Po-
dobnie, jak poziom istotności, jest to
wartość określana subiektywnie przez
autora reguły, jednak powinna ona za-
leżeć od algorytmu użytego do wykry-
cia problemu oraz cech specyficznych
dla problemu, które nie mogą zostać Rysunek 2. Lista Ostrzezeń po analizie kodu
www.hakin9.org
54 hakin9 Nr 12/2007
FxCop  analiza kodu w .NET
FxCop w praktyce
Wiemy już, czym jest FxCop i jakie jest jego zastosowa-
nie. Zobaczmy teraz, w jaki sposób możemy praktycznie
wykorzystać to narzędzie i jak się do tego zabrać. Poniżej
chciałbym przedstawić sposób wykonania statycznej ana-
lizy kodu przy użyciu Visual Studio.
Aby rozpocząć pracę z FxCop i statyczną analizą
kodu, należy uruchomić właściwości projektu w Visual
Studio, a następnie z lewego menu wybrać opcję Co-
de Analysis. Otrzymamy okno takie, jak na Rysun-
ku 1. Następnie w tym oknie wybieramy opcję Enable
Code Analysis, która spowoduje włączenie analizy kodu.
W tym momencie możemy jeszcze raz wykonać zbudo-
wanie naszej aplikacji.
W trakcie kompilacji będziemy dostawać ostrzeżenia
(o ile się takie pojawią) dotyczące jakości utworzonego
kodu. Przykład takiej listy ostrzeżeń przedstawiony jest
na Rysunku 2. Jeśli przyjrzymy się temu obrazkowi, bę-
dziemy mogli dostrzec błędy o numerach zaczynających
się od liter CA  jak Code Analysis. W drugiej kolum-
nie zobaczyć można kolejną bardzo ważną informację,
mówiącą o kategorii, do której należy dana reguła, np.
Microsoft.Usage.
Dla przykładu linia 4 zawiera następujące informacje:
CA2210 : Microsoft.Design : Sign FxCop-Sample with
a strong name key.
Oznacza to, że nasz projekt nie jest podpisany, a co
za tym idzie  klient może mieć problem z instalacją lub
uruchomieniem wynikowej aplikacji, ponieważ system nie
będzie wiedział, czy można zaufać bibliotekom wcho-
dzącym w skład programu (lub samemu programowi).
Oczywiście nie ma potrzeby wykorzystania wszyst-
kich reguł. Jeśli celowo chcemy pominąć jakąś grupę re-
guł lub konkretny numer błędu (bo tego wymaga nasza
aplikacja), to w oknie, w którym uruchamialiśmy anali-
zę kodu, możemy wybierać interesujące nas reguły. Na
Rysunku 3. przedstawiony jest przykład wyłączenia ze
sprawdzania reguły mówiącej o tym, że nasza bibliote-
ka powinna mieć zadeklarowany minimalny stopień bez-
pieczeństwa.
Jeśli teraz ponownie przekompilujemy nasz projekt, to
zobaczymy, że ostrzeżenie o błędzie CA2209 nie będzie
Rysunek 3. Wyłączenie jednej z reguł
www.hakin9.org hakin9 Nr 12/2007 55
Obrona
już widoczne  pokazuje to Rysu-
nek 4. Oczywiście nie musimy się
ograniczać do włączania lub wyłą-
czania pojedynczych reguł. Mamy
również możliwość wyłączenia ze
sprawdzania całej ich grupy, tak jak
widać na Rysunku 5.
Jeśli dobrze zwrócimy uwagę
na opcję konfiguracji analizy kodu,
łatwo dostrzeżemy, że możliwe jest
przygotowanie takich ustawień, które
będą odpowiednie dla różnych konfi-
guracji. Co innego może być spraw-
dzane dla konfiguracji Debug, a co
innego dla konfiguracji Release.
Od czasu do czasu zdarza się,
że z jakiś powodów nie chcemy
pozwolić na kompilację programu,
jeśli pojawią się ostrzeżenia z anali- Rysunek 5. Wyłączenie ze sprawdzania całej grupy
zy kodu. W takiej sytuacji warto za-
mienić ostrzeżenie w błąd. Dzię-
ki temu, jeśli napotkamy na ta-
ki problem, to nie będziemy mogli
przejść nad nim do porządku dzien-
nego, tylko będziemy zmuszeni do
jego poprawy. Jak to wykonać?
Nic prostszego. Na liście z reguła-
mi po prawej stronie mamy wykrzyk-
nik symbolizujący ostrzeżenie. Jeśli
teraz klikniemy w niego i zmienimy
ostrzeżenie na błąd, to w momencie
napotkania na opisany regułą pro-
blem otrzymamy błąd. Taką sytuację
Rysunek 6. Zamiana ostrzeżenia na błąd
przedstawia Rysunek 6. Po kom-
pilacji przypadek spełnienia reguły Podsumowanie około dwustu reguł, ale również dla-
CA2100 będzie wykryty jako błąd, co Mamy do dyspozycji coraz więcej tego, że pozwala na rozbudowę tego
spowoduje, że będziemy musieli tak narzędzi wspomagających tworze- zestawu. Jeśli nasza firma korzysta
poprawić składnię SQLa, aby nie ak- nie bezpieczniejszych aplikacji. Jed- z własnych reguł poprawności ko-
ceptowała dowolnie wpisanego cią- nym z nich jest FxCop. Narzędzie to du, to mamy możliwość dopisania ich
gu znaków. Pozwoli nam to na napi- jest bardzo potężne i to nie tylko dzię- do już istniejących. Gdybyśmy chcie-
sanie bezpieczniejszej aplikacji. ki wbudowaniu w nie standardowo li dodać własny algorytm analizy,
także mamy taką możliwość. Pole-
cam zapoznać się z tym narzędziem,
a tworzenie bezpieczniejszych aplika-
cji stanie się łatwiejsze. l
O autorze
Autor jest pracownikiem firmy Micro-
soft. Na co dzień zajmuje się m. in. two-
rzeniem rozwiązań w oparciu o SQL
Server w różnych aspektach  bazy
relacyjne, usługi integracyjne, usługi
analityczne. Jest certyfikowanym admi-
nistratorem baz danych (MCDBA).
Kontakt z autorem:
[e-mail]
Rysunek 4. Wynik kompilacji po wyłączeniu reguły
www.hakin9.org
56 hakin9 Nr 12/2007