2007.12_FxCop – analiza kodu w .NET.pdf - Analiza - teresarobert

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.

czy to przy pomocy różnych metodologii

(np. Extreme Programming ), okresowego

sprawdzania i analizy kodu ( code reviews ), czy

też kombinacji różnych podejść, jest procesem

kosztownym i długotrwałym. Jego automatyza-

cja i wplecenie w cykl życia aplikacji, pomimo

iż nie wyeliminuje do końca ingerencji człowie-

ka – a także samych błędów – zdecydowanie

usprawnia proces i zwiększa efektywność pra-

cy całego zespołu. Tu przychodzą nam z pomo-

cą narzędzia do statycznej analizy kodu, a wśród

nich aplikacja FxCop.

FxCop jest narzędziem do analizy kodu,

które sprawdza zgodność elementów kodu za-

rządzanego .NET z wytycznymi projektowymi

dla platformy .NET ( Microsoft .NET Framework

Design Guidelines ). Narzędzie wykorzystuje me-

chanizm releksji, parsowanie MSIL oraz analizę

grafu wywołań do sprawdzenia elementów pod

kątem występowania ponad 200 często spotyka-

nych wad w następujących obszarach:

FxCop dysponuje graicznym interfejsem użyt-

kownika, ale jest też narzędziem dostępnym

z wiersza polecenia. Zawiera także pakiet

SDK umożliwiający tworzenie niestandardowych

reguł.

Jakość tworzonego kodu

Kiedy mówimy o tworzeniu bezpiecznego opro-

gramowania, musimy zacząć od samych pod-

staw, czyli od jakości tego, co napisaliśmy. Ma

ona fundamentalne znaczenie w przypadku, gdy

nasza aplikacja jest kluczowa dla irmy. Spraw-

dzeniem jakości naszego kodu zajmuje się spe-

cjalna dziedzina inżynierii oprogramowania, nie-

mniej jednak jako programiści sami jesteśmy

Z artykułu dowiesz się

• jak działa i czym jest narzędzie FxCop,

• czym jest analiza kodu.

Co powinieneś wiedzieć

• projekt bibliotek,

• lokalizacja,

• konwencje nazewnictwa,

• wydajność,

• bezpieczeństwo.

• należy znać zagadnienia związane z programo-

waniem przy użyciu platformy .NET ,

• wiedzieć, jak poruszać się w środowisku Visual

Studio.

hakin9 Nr 12/2007

www.hakin9.org

Z apewnienie odpowiedniej jakości kodu,

FxCop – analiza kodu w .NET

w stanie określać reguły, którym pod-

lega tworzony kod aplikacji. Do tego

celu możemy wykorzystać mecha-

nizm statycznej analizy kodu. Okre-

ślenie statyczna analiza kodu to

specjalny etap kompilacji naszego

programu, w trakcie którego przy

pomocy odpowiednich reguł spraw-

dzane jest to, co napisaliśmy. Regu-

ły te opisują, co jest prawidłowe i jak

powinien wyglądać nasz kod źródło-

wy, aby był poprawny i bezpieczny

z naszego punktu widzenia.

Listing 1. Deinicja reguły w pliku XML

< Rules >

< Rule TypeName= "RegulaPusteNazwy" Category= " Naming" CheckId= "Reg5000" >

< Name > Reguła używana, kiedy pojawiają się puste nazwy < /Name >

< Description > Tutaj nasz opis < /Description >

< Url > Link do opisu < /Url >

< Resolution > Sposób rozwiązania < /Resolution >

< Email > email do osoby odpowiedzialnej < /Email >

< MessageLevel Certainty= "95" > Error < /MessageLevel >

< FixCategories > Breaking < /FixCategories >

< Owner > Informacje o właścicielu reguły < /Owner >

< /Rule >

< /Rules >

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ż

sam kod źródłowy, nawet przy uży-

ciu różnych języków programowania

dostępnych w platformie .NET.

W taki właśnie sposób – przy

pomocy analizy kodu pośredniego

– działa narzędzie pod nazwą FxCop.

Rysunek 1. Okno Code Analysis w VisualStudio

Reguły w FxCop

Jak już wcześniej wspominaliśmy,

analiza składni polega na sprawdze-

niu kodu według wcześniej określo-

nych reguł. Dokładnie ta sama zasa-

da działania dotyczy FxCop. Narzę-

dzie to zawiera standardowo wbudo-

wane pewne reguły określające, jak

powinien wyglądać nasz kod. Regu-

ł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

Źródło: http://msdn2.microsoft.com/en-us/library/ee1hzekz(VS.80).aspx

www.hakin9.org

hakin9 Nr 12/2007

Obrona

funkcjonalnych. Tabela 1. zawiera

zestawienie grup wraz ze specyika-

cją, jakiemu zakresowi analizy pod-

legają umieszczone reguły.

Sama reguła jest tylko jednym

z elementów całej analizy. Istotną

sprawą jest stwierdzenie, czy to

co dana reguła wykryje, jest waż-

ne, czy nie i jak to zdarzenie zakla-

syikować. 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-

ki determinujące poziom istotności:

Pełna lista możliwych parametrów

public virtual ProblemCollection Check(Member member);

public virtual ProblemCollection Check(Module module);

public virtual ProblemCollection Check(Parameter parameter);

public virtual ProblemCollection Check(Resource resource);

public virtual ProblemCollection Check(TypeNode type);

public virtual ProblemCollection Check(string namespaceName,

TypeNodeList types);

zweryikowane na podstawie staty-

cznej analizy. Współczynnik pew-

ności określany jest w procentach

(0-99%). Im wyższa wartość, tym

większe prawdopodobieństwo, że

dana reguła poprawnie identyiku-

je problem.

informację o rodzaju reguły, jej naz-

wie, identyikatorze oraz poziomie

pewności.

W drugim kroku tworzymy biblio-

tekę, do której dodajemy następują-

ce referencje:

• widzialność znalezionego pro-

blemu,

• prawdopodobieństwo tego, czy

wykryty problem będzie miał ne-

gatywny skutek na całość apli-

kacji i jej zachowania,

• ryzyko powiązane z nie napra-

wieniem problemu.

Własne reguły

Bardzo dobrze, jeśli proces spraw-

dzania naszego oprogramowania jest

w pełni opisany dostarczonymi regu-

łami. Zdarzają się jednak sytuacje,

kiedy standardowe opcje nam nie wy-

starczają. W takim przypadku mamy

możliwość dopisania własnej reguły

i podpięcia jej do istniejącego zesta-

wu. Jak się do tego zabrać? W tym

celu pomocne są dwie biblioteki:

FxCopSdk.dll oraz Microsoft.Cci.dll .

Proces tworzenia nowej reguły

składa się z dwóch etapów. Pierw-

szy z nich to stworzenie deinicji

reguły – określonej w pliku XML

– oraz napisanie kodu, który będzie

realizował sprawdzenie danej reguły.

Plik XML powinien wyglądać tak,

jak na Listingu 1. i powinien zawierać

using Microsoft.Cci;

using Microsoft.FxCop.Sdk;

using Microsoft.FxCop.Sdk.Introspect

ion;

Dodatkowo każda reguła musi cecho-

wać się jednym z pięciu poziomów

istotności. Poziomy te przedstawiają

się następująco:

oraz tworzymy klasę o nazwie takiej

jak nazwa reguły:

public class RegulaPusteNazwy :

BaseIntrospectionRule

• Critical Error (Błąd krytyczny) /

Error (Błąd) – wiadomości, któ-

rym nadano ten poziom, dotyczą

problemów, które mogą zagrozić

stabilności kodu,

• Critical Warning (Ostrzeżenie kry-

tyczne) / Warning (Ostrzeżenie)

– w tej grupie problemy zwykle

nie dotyczą stabilności aplikacji.

Niemniej jednak powinny zostać

dokładnie przeanalizowane pod

kątem optymalności kodu,

• Informational (Informacja) – sto-

sowany do wiadomości, które

dostarczają jedynie informacji

o przedmiocie analizy, nie iden-

tyikują zaś potencjalnych proble-

mów z nim związanych.

Następnie musimy zaimplementować

obsługę sprawdzania danej reguły, nad-

pisując w tym celu metodę Check . Jej

parametrem może być moduł, para-

metr, zasób, etc. Pełna lista możliwych

parametrów znajduje się w Ramce.

Ostatnim krokiem jest kompilacja

biblioteki i umieszczenie jej w katalo-

gu z innymi regułami ( FxCop\Rules ),

a także przetestowanie jej.

Współczynnik pewności określa praw-

dopodobieństwo, z jakim problem zo-

stał poprawnie zidentyikowany. 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 specyicznych

dla problemu, które nie mogą zostać

Rysunek 2. Lista Ostrzezeń po analizie kodu

hakin9 Nr 12/2007

www.hakin9.org

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

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ę koniguracji analizy kodu,

łatwo dostrzeżemy, że możliwe jest

przygotowanie takich ustawień, które

będą odpowiednie dla różnych koni-

guracji. Co innego może być spraw-

dzane dla koniguracji Debug , a co

innego dla koniguracji 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-

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ę

przedstawia Rysunek 6. Po kom-

pilacji przypadek spełnienia reguły

CA2100 będzie wykryty jako błąd, co

spowoduje, że będziemy musieli tak

poprawić składnię SQLa, aby nie ak-

ceptowała dowolnie wpisanego cią-

gu znaków. Pozwoli nam to na napi-

sanie bezpieczniejszej aplikacji.

Rysunek 5. Wyłączenie ze sprawdzania całej grupy

Rysunek 6. Zamiana ostrzeżenia na błąd

Podsumowanie

Mamy do dyspozycji coraz więcej

narzędzi wspomagających tworze-

nie bezpieczniejszych aplikacji. Jed-

nym z nich jest FxCop. Narzędzie to

jest bardzo potężne i to nie tylko dzię-

ki wbudowaniu w nie standardowo

około dwustu reguł, ale również dla-

tego, że pozwala na rozbudowę tego

zestawu. Jeśli nasza irma korzysta

z własnych reguł poprawności ko-

du, to mamy możliwość dopisania ich

do już istniejących. Gdybyśmy chcie-

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 irmy 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 certyikowanym admi-

nistratorem baz danych (MCDBA).

Kontakt z autorem:

arturz@microsoft.com

Rysunek 4. Wynik kompilacji po wyłączeniu reguły

hakin9 Nr 12/2007

www.hakin9.org

2007.12_FxCop – analiza kodu w .NET.pdf

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: