plik

www.hakin9.org

hakin9 Nr 12/2007

Obrona

apewnienie odpowiedniej jakości kodu,
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 refleksji, 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:

•   projekt bibliotek,
•   lokalizacja,
•   konwencje nazewnictwa,
•   wydajność,
•   bezpieczeństwo.

FxCop dysponuje graficznym 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 firmy. Spraw-
dzeniem jakości naszego kodu zajmuje się spe-
cjalna dziedzina inżynierii oprogramowania, nie-
mniej jednak jako programiści sami jesteśmy

FxCop – analiza kodu

w .NET

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.

Z artykułu dowiesz się

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

Co powinieneś wiedzieć

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

waniem przy użyciu platformy .NET ,

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

Studio.

FxCop – analiza kodu w .NET

hakin9 Nr 12/2007

www.hakin9.org

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.

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.

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

Listing 1.

Definicja 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 do osoby odpowiedzialnej

/Email

MessageLevel Certainty=

"95"

Error

/MessageLevel

FixCategories

Breaking

/FixCategories

Owner

Informacje o właścicielu reguły

/Owner

/Rule

/Rules

Rysunek 1.

Okno Code Analysis w VisualStudio

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

hakin9 Nr 12/2007

www.hakin9.org

Obrona

funkcjonalnych. Tabela 1. zawiera
zestawienie grup wraz ze specyfika-
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-
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-
ki determinujące poziom istotności:

• 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.

Dodatkowo każda reguła musi cecho-
wać się jednym z pięciu poziomów
istotności. Poziomy te przedstawiają
się następująco:

• 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-
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ć

zweryfikowane  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  identyfiku-
je problem.

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  definicji
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ć

informację o rodzaju reguły, jej naz-
wie, identyfikatorze oraz poziomie
pewności.

W drugim kroku tworzymy biblio-

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

using Microsoft.Cci;
using Microsoft.FxCop.Sdk;
using Microsoft.FxCop.Sdk.Introspect

ion;

oraz tworzymy klasę o nazwie takiej
jak nazwa reguły:

public class RegulaPusteNazwy :
BaseIntrospectionRule

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.

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);

Rysunek 2.

Lista Ostrzezeń po analizie kodu

FxCop – analiza kodu w .NET

hakin9 Nr 12/2007

www.hakin9.org

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ł

hakin9 Nr 12/2007

www.hakin9.org

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

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  firma  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

Rysunek 5.

Wyłączenie ze sprawdzania całej grupy

Rysunek 6.

Zamiana ostrzeżenia na błąd

Rysunek 4.

Wynik kompilacji po wyłączeniu reguły

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:
arturz@microsoft.com