01/02/2009

Awaria Google (część 3)

Home

I wszystko jasne. Zgodnie z komunikatem od Google, awarii zawinił pracownik, który przez przypadek zablokował wszystkie strony zamiast tylko tych z listy stron niebezpiecznych, które Google otrzymuje od serwisu StopBadware.org. Czyli jak się często zdarza najsłabszym ogniwem jest czynnik ludzki. Nie jestem zwolennikiem spiskowej teorii dziejów, więc takie wytłumaczenie jest dla mnie przekonujące. Zresztą czas to zweryfikuje. Przy tej okazji przypomniały mi się dwie zasłyszane kiedyś historie w tym klimacie.

Dla ustalenia uwagi wyobraźmy sobie niezwykle ważny dla jakiejś firmy serwer. Na serwerze przechowywane są bardzo istotne dane, musi on być dostępny on-line 24 godziny na dobę, chroniony jest najnowszym oprogramowaniem antywirusowym itd. Ale jak w każdej firmie ktoś musi odkurzać, wynosić śmiecie, zmywać podłogi, również w serwerowni. Nie ulega wątpliwości, że leżące na ziemi kable zasilająca mogą utrudnić zadanie sprzątaczce czy też sprzątaczowi. Co "powinien", więc zrobić wykonujący skrupulatnie i dokładnie swoją pracę konserwator powierzchni płaskich? ... Od tego czasu we wspomnianej firmie kable zasilające są na stałe przymocowane do gniazdek.

Druga historia dotyczy pewnego administratora sieci, który jako wygaszacz ekranu na serwerze postanowił użyć słynnego "blue screen". Niestety ale zdarzyło się, że koło serwera przechodził pewien menadżer. Kiedy zobaczył wygaszacz ekranu postanowił wyręczyć administratora w jego pracy i zrestartował serwer. Dodam, że nagły restart tego serwera nie był bez znaczenia dla firmy i jego klientów. Ciekawe kto stracił pracę?

Podsumowując, bez względu na to jakich zabezpieczeń użyjemy, zawsze zapomnimy o jakimś małym szczególe lub nie uwzględnimy czegoś co będzie wydawać się nam absurdalnie niemożliwe, a co doprowadzi do mniejszej lub większej katastrofy.

Swoją drogą zastanawialiście się kiedyś jak to jest, że jeżeli pracownicy danej firmy mają ograniczony dostęp do poszczególnych pomieszczeń to sprzątaczka czy sprzątacz mogą wejść wszędzie (lub prawie wszędzie). No chyba, że prezes będzie sprzątać swoje biuro samemu ;)

31/01/2009

Awaria Google (część 2)

Home

Chłopcy z Google szybko rozwiązali problem. "Awaria" trwała tylko, a może aż, małe kilkanaście minut. Jak widać publikuję tego posta jakieś 10 minut po poście, w którym stwierdziłem, że z serwerami Google mogło sie coś stać. Jestem ciekawy czy zostanie opublikowany oficjalny komunikat wyjaśniający cała sytuację.

Awaria Google

Home

Mam wrażenie, że z serwerami Google stało sie coś niedobrego. Jeszcze kilkanaście minut wyszukiwarka działa bardzo dobrze. W tej chwili chyba dla każdego hasła (łącznie z takimi jak: Google, Microsoft) wyszukane strony oznaczone są jako niebezpieczne; do każdej strony dodawany jest komunikat Ta witryna może wyrządzić szkody na Twoim komputerze. Wynik zaobserwowałem na dwóch komputerach. A może Google padło ofiarą ataku hackerów?

26/01/2009

Environment.CurrentDirectory

Home

Właściwość Environment.CurrentDirectory jest zapewne znana każdemu programiście .Net (przy jej pomocy odczytujemy ścieżkę do bieżącego katalogu roboczego). Co już może nie jest tak bardzo oczywiste właściwość ta posiada setter i może być dowolnie modyfikowana. Jest to ważne jeżeli używamy w naszych projektach ścieżek względnych np.:
./WorkingDir/Temp/log.txt
W takim wypadku aby określić ścieżkę bezwzględną platforma odczytuje właściwość Environment.CurrentDirectory. I tutaj mogą pojawić się problemy. Po pierwsze jeśli to my zmodyfikujemy tą właściwość możemy nieświadomie doprowadzić do wystąpienia błędu gdzieś w innej części projektu. Na przykład plik, do którego została podana ścieżka względna nie zostanie odnaleziony. Sytuacja może być oczywiście odwrotna. Żeby nie szukać daleko, użycie klasy OpenFileDialog spowoduje zmianę katalogu roboczego jeśli po wybraniu pliku użytkownik zatwierdzi swój wybór.
OpenFileDialog ofd = new OpenFileDialog();
ofd.ShowDialog();
Jeśli teraz, po wybraniu pliku przy pomocy klasy OpenFileDialog, spróbujemy uzyskać dostęp do innego pliku, do którego znamy tylko ścieżkę względna operacja zakończy się niepowodzeniem (chyba, że katalog wybrany przez użytkownika okaże się taki sam jak pierwotny katalog roboczy). Używanie ścieżek bezwzględnych jest dobrym rozwiązaniem ale nie zawsze zadziała. Co jeśli ścieżka wczytywana jest z pliku konfiguracyjnego, który może zmienić użytkownik? Wytłumaczenie klientowi żeby nie stosował ścieżek względnych nie jest dobrym pomysłem bo co złego może być w ścieżkach względnych z perspektywy klienta :).

Moim zdaniem należy więc: używać ścieżek bezwzględnych wszędzie tam gdzie jest to możliwe lub też nie bazować na wartości Environment.CurrentDirectory. Mam tu na myśli sytuację, w której używamy ścieżek względnych ale zamieniamy je na bezwzględne korzystając z jakiegoś parametru konfiguracyjnego. Można też pomyśleć o wykrywaniu ścieżek względnych podawanych przez użytkownika i zamianie ich na ścieżki bezwzględne.

Po drugie należy unikać modyfikowania właściwości Environment.CurrentDirectory, a jeśli właściwość ta zostanie zmieniona to przywrócić jej pierwotną wartość chyba, że jej modyfikacja była w 100% zamierzona.

Przyda się też wiedza o tym, że katalog roboczy może zostać zmieniony niejako za naszymi plecami oraz, że właściwość Environment.CurrentDirectory jest używana przez platformę .Net w celu określenia ścieżek bezwzględnych.

24/01/2009

Przerażająca 25

Home

Na stronie CWE pojawiła się bardzo świeże opracowanie opisujące 25 najniebezpieczniejszych i najczęściej spotykanych błędów programistycznych (po szczegóły zapraszam tutaj). Najniebezpieczniejszych w tym sensie, że zwiększających podatność oprogramowanie na wszelkiego rodzaju ataki. Zestawienie zostało stworzone przy współpracy kilkudziesięciu firm z Europy i Stanów Zjednoczonych. Na stronie znajdziemy również opis kilkuset innych błędów wraz dokładnym wyjaśnieniem i wskazówkami jak ich unikać. Naprawdę polecam. Martwi to, że spora część z wymienionych błędów jest dobrze znana od bardzo, bardzo dawna, a więc wydawałoby się, że programiści powinni być świadomi tych zagrożeń. Niektóre z błędów to wręcz przykłady akademickie: brak walidacji danych wejściowych, wstrzykiwanie SQL'a!