Jak pewnie zauważyliście blog zaczął wyglądać nieco inaczej. Jest to sygnał, że migracja (chyba) została zakończona. Niedługo zmienione rekordy DNS rozejdą się po sieci i ruch będzie kierowany tutaj, zamiast na starą instancję bloga. Wówczas spróbuję przenieść kilka komentarzy, które pojawiły się w trakcie migracji, do nowej instancji bloga.
Może pojawiać się błąd 403 (na razie nieobsłużony). To wynik ograniczeń, które nałożyłem w .htaccess, być może zbyt restrykcyjnych. Z czasem wprowadzę potrzebne poprawki. Kilka innych zmian również czeka w kolejce, ale nie wszystko na raz. No dobra, jeszcze RSS na FeedBurner puściłem i prosiłbym o aktualizację.
EDIT : w przyszły weekend zablokuję “stary” kanał RSS, dostęp będzie możliwy tylko przez FeedBurner. Stary adres będzie przekierowywał na FeedBurner, ale nie wiem jak się zachowają różne czytniki RSS gdy natrafią na przekierowanie...
Wciąż nikt nie poradził sobie z wyzwaniem http://bootcamp.threats.pl/lesson08/, a przynajmniej nikt się tym nie chwali. Cóż, pora na kolejną podpowiedź. Skoro wiadomo już, że można rozróżnić między sytuacją nieprawidłowy użytkownik a prawidłowy użytkownik, nieprawidłowe hasło , to co się stanie, gdy do nazwy istniejącego użytkownika (dwie z nich podane są w komentarzach) doda się coś w stylu ' and 1=1 — lub ' and 1=0 —?
Jakiś czas temu pojawiła się informacja o podatności w implementacji protokołu WebDAV w IIS. Microsoft wydał stosowne Security Advisory: Vulnerability in Internet Information Services Could Allow Elevation of Privilege. Pojawił się również stosowny exploit (zresztą nie jest zbyt wyrafinowany): http://milw0rm.com/exploits/8704, pojawiły się również nieco złośliwe komentarze: Smells like teen spirit. Fakt, błąd z gatunku głupich, ale proponuję rzucić okiem na listę podatności wykrytych w IIS 6.0 i porównać to z czasami IIS 5.0. Jak dla mnie duża zmiana, na plus oczywiście. Swoją drogą jestem ciekawy jak ten błąd przeszedł niezauważony, korzystanie z fuzzerów jest wymogiem SDL. Mogło po prostu nie być takiego przypadku testowego, zdarza się, to nie koniec świata. Trzeba tylko wyciągnąć z tego naukę na przyszłość, lepiej uczyć się na cudzych błędach, ale na swoich też trzeba.
Jednym z podstawowych testów wykonywanych w trakcie testów mechanizmu uwierzytelnienia (formatki logowania) jest sprawdzenie, czy można odróżnić przypadek podania prawidłowej nazwy użytkownika i nieprawidłowego hasła, od podania nieprawidłowej nazwy użytkownika i nieprawidłowego hasła. Jeśli taka różnica istnieje, możliwe jest określenie nazw użytkowników istniejących w aplikacji, co czasami pozwala na dalsze ataki. Jak jest w przypadku http://bootcamp.threats.pl/lesson08/?
Nie mam i przynajmniej do końca miesiąca nie będę miał czasu na napisanie wyjaśnienia do odcinka dotyczącego SQL Injection: http://bootcamp.threats.pl/lesson07/. Podam jednak kilka wskazówek.
Dziś udostępniam już pełną wersję lekcji Bootcamp: Home-brewed Crypto. Przesłanie jest jedno: zostawmy wymyślanie algorytmów kryptograficznych ekspertom , ograniczmy się do prawidłowego z nich korzystania.