Niepozorna pomyłka

Home

Regularnie przeglądam różne portale na temat szeroko pojętego bezpieczeństwa w IT i co raz to dziwię się jak pozornie małe błędy programistów doprowadzają do poważnych problemów i awarii. Czytając ostatnio taki artykuł przypomniałem sobie rozmowę na temat implementacji stronicowania (ang. paging), czyli podziału dużej liczby rekordów na mniejsze porcje i przesyłanie tych porcji do klienta m.in. w celu ograniczenia ruchu w sieci.

W tym przypadku domyślna wielkość strony była skonfigurowana po stronie serwera, ale wysyłając żądanie klient mógł ją nadpisać i podać własną wielkość strony. Rozwiązanie w miarę standardowe, coś podobnego można zrobić odpytując Active Directory, o czym pisałem w tym artykule. Problem w tym przypadku polegał na tym, że wartość podana przez klienta nie była w żaden sposób sprawdzana po stronie serwera. Teoretycznie można więc było zażądać zwrócenie z serwera dowolnie dużej porcji danych. Innymi słowy, wysyłając żądanie wielkości kilku kilobajtów można było otrzymać odpowiedzieć wielkości na przykład 10 MB, a to przecież gigantyczne zwielokrotnienie. A gdyby takich żądań wysłać kilkadziesiąt, kilkaset, a może kilkanaście tysięcy, a do tego podmienić w żądaniu adres odbiorcy?

O czymś podobnym można było niedawno przeczytać w kontekście protokołu NTP. Wspomniany przeze mnie przypadek to w porównaniu z tym pikuś, gdyż użyty protokół komunikacyjny był specyficzny dla danej aplikacji, liczba użytkowników była niewielka itd. więc i zakres potencjalnego ataku był bardzo ograniczony. Z drugiej strony, skoro programista napisał taki kod raz, to może go napisać drugi, trzeci i w którymś momencie nie będzie to mała aplikacja. Na takie rzeczy należy, więc zawsze zwracać uwagę, nawet jeśli w danym przypadku wydaje się to nadmiarowe. Możliwe, że twórca kodu wybrał takie rozwiązanie celowo, ale równie dobrze może to być po prostu przeoczenie lub pomyłka.

Co robię z poufnymi...

Home

Post ten jest częściowo powiązany z poprzednim, w którym napisałem, jak podchodzę do bezpieczeństwa swoich danych. Tym razem opiszę, jak pozbywam się poufnych danych...

Zacznijmy od papierowych dokumentów, które są już nam do niczego potrzebne. Pomimo tego, że staram się ograniczyć ich "produkcję", to trochę się tego zbiera: paragony ze sklepów, rachunki, faktury, stare umowy, wyciągi z banków itd. Przynajmniej na części z nich można znaleźć nasze dane teleadresowe i na przykład powiązać wyciąg z banku z mieszkaniem numer X przy ulicy Y. Może i jestem przewrażliwiony, ale ja takich rzeczy nie wyrzucam do kosza. Już dawno temu sprawiłem sobie niszczarkę firmy Fellowers i wszystkie poufne dokumenty lądują właśnie w niej.

Podejście do poufnych dokumentów rozciąga się również na świat elektroniczny. Kiedy jakiś czas temu miałem problemy z telefonem i musiałem oddać go na gwarancję, usunąłem z niego wszystkie dane. Ponieważ jednak nie byłem pewny gdzie dokładnie trzymane są hasła do mojego konta Google oraz kont pocztowych na wszelki wypadek, przed oddaniem sprzętu do serwisu, zmieniłem hasła. Kiedy wyciekły hasła z portalu LinkedIn, to, pomimo tego sądzę, że moje oparłoby się metodzie słownikowej, a jego złamanie zajęłoby trochę czasu, bez zastanowienia je zmieniłem.

Rok temu chciałem zezłomować stary, niedziałający laptop. Niejeden pewnie wyrzuciłby go do kosza lub oddał to wyznaczonego punktu. I jak tak rozbiłem, ale wcześniej wyciągnąłem z niego dysk. Z jednej strony był jeszcze sprawny, a z drugiej po co ryzykować. Jeszcze nie potrzebowałem tego robić ale gdybym chciał się pozbyć dysku to najpierw użyłbym jakiegoś narzędzia do zamazywania danych (na przykład CCleaner), potem go sformatował, a na koniec uszkodził go fizycznie choćby przy pomocy młotka ;)

Co jeśli chcę usunąć jakieś pojedyncze pliki z dysku? W większości wypadków po prostu je usuwam i opróżniam Kosz, choć ta operacja tak naprawdę nie gwarantuje fizycznego usunięcia danych z dysku. W 99.9% przypadków to mi jednak wystarcza. Kiedy zależy mi na bezpowrotnym wymazania danych postępuję inaczej. Kiedyś korzystałem z opcji Wipe programu PGP. W tej chwili przestawiłem się na GPG, który nie posiada tej funkcji, a więc testuję program shred z pakietu GNU CureUtils. Jeśli nie chce się Wam używać takich narzędzi, to, moim zdaniem, przed usunięciem pliku warto przynajmniej otworzyć i nadpisać jego zawartość.

Jak zabezpieczam swoje dane

Home

Post ten będzie dotyczył rzeczy, na której mam chyba drobnego hopla, czyli tego jak zabezpieczyć się przed utratą danych np.: w wyniku kradzieży komputera. Moje podejście jest proste, aby czuć się bezpiecznym muszę posiadać 3 niezależne, fizycznie od siebie oddalone kopie swoich danych: na domowym komputerze oraz na dwóch dyskach przenośnych z czego jeden trzymam daleko poza domem. Tą drugą lokalizacją może być dom rodziców, skrytka bankowa, dom przyjaciela itd. Dysk trzymany w domu, po każdorazowym wykonaniu kopii bezpieczeństwa, zamieniam z tym drugim.

Do tworzenia kopii bezpieczeństwa nie używam jakiegoś specjalnego oprogramowania. Wszystkie dane, które są dla mnie istotne trzymam na komputerze w jednym miejscu, a więc zrobienie kopii polega na podłączeniu dysku i skopiowaniu na niego kilku folderów. Jeśli nie możecie znieść myśli o robieniu czegoś ręcznie ;) to łatwo to zautomatyzować. Dla mnie to zbyteczne, bo te kilka minut mnie nie zbawi. Takie kopie staram się wykonywać raz w miesiącu.

Do tematu szyfrowania kopii swoich danych podchodzę w ten sposób, że szyfruję tylko niektóre rzeczy np.: listy haseł, listy wydatków. W tym celu używam programu PGP/GPG oraz bardzo długiego i skomplikowanego hasła. Nie szyfruję wszystkiego ponieważ zajmuje to czas, a ja nie posiadam danych, których wyciek mógłby mi lub komuś zaszkodzić czy też skompromitować (to najlepsze z możliwych zabezpieczeń).

Jeśli pracuję nad czymś ważnym i nie mogę sobie pozwolić na czekanie do kolejnego backupu wykorzystuję Internet. Kiedyś wysyłałem archiwum na maila, teraz korzystam z dysków w chmurze. Przy czym, jeśli zależy mi na poufności danych, archiwum na wszelki wypadek zabezpieczam hasłem. Nie przypuszczam aby ktoś mnie szpiegował, ale przezorny zawsze zabezpieczony.

To prosty, ale mam nadzieję, że skuteczny system. Z mojej perspektywy najważniejsze jest fizyczne oddalenie od siebie kopii bezpieczeństwa. Jeśli w mój dom trafi meteoryt to zawsze pozostanie ta jedna kopia, nawet jeśli trochę stara. A Wy jak dbacie o swoje dane?

Warto też edukować swoją rodzinę i znajomych. Na przykład kupić im na Święta Bożego Narodzenia przenośny dysk i wytłumaczyć jak ważne jest robienie kopii zapasowej od czasu do czasu. Sądzę, że każdy ma jakieś dane warte zabezpieczenia: zdjęcia rodzinne, praca licencjacka, praca magisterska, kopia dokumentów urzędowych...

Uwierzytelnienie, ASP.NET i IIS

Home

Post ten postanowiłem napisać kiedy zorientowałem się, że kilku kolegów poświęciło sporo czasu aby rozwiązać problem z uwierzytelnieniem usługi sieciowej zainstalowanej na IIS'ie podczas gdy nie posiadali dokładnej wiedzy jak ten mechanizm działa. Problem udało się rozwiązać ale jestem przekonany, że można to było zrobić mniejszym nakładem czasu. Na początku zaznaczę również, że wpis ten dotyczy IIS w wersjach wcześniejszych niż IIS 7.

Jak wszyscy wiemy aplikacje ASP.NET i usługi sieciowe (ang. Web Services) hostowane są na serwerze IIS. Do swojego działania wymagają one dostępu do różnych zasobów. Aby możliwe było określenie czy aplikacja lub usługa posiadają uprawnienie do jakiegoś zasobu muszą one posiadać jakąś tożsamość czyli być uwierzytelnione (ang. authentication). Powstaje pytanie jaką tożsamość posiada aplikacja ASP.NET lub usługa sieciowa?

Na początek przyjrzyjmy się poniższemu scenariuszowi:

• Użytkownik uruchamia przeglądarkę internetową i wpisuje adres aplikacji.
• Serwer IIS otrzymuje żądanie i w zależności od ustawień żąda lub nie uwierzytelnienia.
• Serwer IIS sprawdza czy użytkownik uwierzytelniony (bądź anonimowy) może uzyskać dostęp do żądanego zasobu.
• Żądanie przekazywane jest do obsługi do silnika ASP.NET.
• Aplikacja w zależności od ustawień ponownie żąda lub nie uwierzytelnienia się użytkownika.
• Aplikacja obsługuje żądanie w razie potrzeby legitymując się pewną tożsamością.

Poziom IIS

Na poziomie IIS domyślnie włączone jest uwierzytelnienie anonimowe czyli innymi słowy brak uwierzytelnienia. W takim wypadku zgodnie z domyślnymi ustawieniami przyjmuje się, że użytkownik uwierzytelnił się jako IUSR_machinename. Dostępne są oczywiście inne tryby uwierzytelnienia np.: uwierzytelnienie zintegrowane z Windows (ang. Integrated Windows Authentication) czy uwierzytelnienia podstawowe (ang. Basic) gdzie hasło przekazywane jest czystym tekstem.

Uwierzytelnienia na poziomie IIS jest potrzebne aby stwierdzić czy użytkownik może żądać danego zasobu znajdującego się na serwerze. Zasobem tym może być aplikacja ASP.NET ale również inne rzeczy np.: obrazki, archiwa itd. Uwierzytelnienia na tym poziomie konfigurowne jest przy pomocy aplikacji administratora IIS: Control Panel -> Administrative Tools -> Internet Information Services.

Poziom silnika ASP.NET

Następnie mamy uwierzytelnienia na poziomie silnika ASP.NET. W tym przypadku można włączyć uwierzytelnienie anonimowe, zaimplementować cały mechanizm samemu czy użyć uwierzytelnienia Windows. Należy jednak zaznaczyć, że nie należy mylić uwierzytelnienia Windows na poziomie ASP.NET z uwierzytelnienia zintegrowanym z Windows na poziomie IIS.

Włączenie uwierzytelnienia Windows na poziomie ASP.NET oznacza, że silnik ASP.NET będzie widział użytkownika pod tożsamością wyznaczoną przez IIS. Innymi słowy IIS uwierzytelni użytkownika i przekaże jego tożsamość do ASP.NET. Metoda jaka zostanie użyta przez IIS do uwierzytelnienia zależy od ustawień. W szczególności, tak jak napisałem wyżej, może to być uwierzytelnienia zintegrowane z Windows ale również podstawowe czy inne. W przypadku braku uwierzytelnienia do silnika ASP.NET zostanie natomiast przekazana tożsamość anonimowa. Uwierzytelnienia na tym poziomie konfigurowane jest przy pomocy pliku web.config w sekcji <authentication>.

Tożsamość silnika ASP.NET

Teraz dochodzimy do setna sprawy czyli z jaką tożsamością działa silnik ASP.Net. Odpowiedź: „To zależy” :) Już odpowiadam ale zanim przejdziemy dalej należy jeszcze wyjaśnić czym jest impersonacja. Otóż impersonacja to mechanizm pozwalający przyjąć cudzą tożsamość i wykonywać w jej kontekście różne działania.

A więc jeśli wyłączona jest impersonacja (ustawienia domyślne) to silnik ASP.NET w przypadku systemów Windows Server 2000 i Windows XP działa na koncie o nazwie ASPNET, a przypadku Windows Server 2003 używa konta Network Service. Natomiast jeśli impersonacja jest włączona ASP.NET działa z tożsamością uwierzytelnionego użytkownika nawet jeśli jest to tożsamość anonimowa. Za te kwestie odpowiada sekcja <identity>.

Sprawa wygląda trochę inaczej w przypadku IIS 7, który posiada mocno zmienioną, a właściwie zupełnie inną architekturę w stosunku do IIS 6 i wcześniejszych. W szczególności w IIS 7 nie ma podziału na uwierzytelnienia na poziomie serwera i ASP.NET. Serwer IIS7 może być również konfigurowany z poziomu sekcji <system.WebServer> w pliku web.config. To jednak temat na kolejny wpis.

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!