W Windows XP pojawił się Prefetch. Można o niej przeczytać między innymi tutaj. Autorzy tego artykułu gwarantują, że będzie merytorycznie, a nie marketingowo. Swoją drogą w zamierzchłych czasach wchodzenia na rynek Windows XP (Tomek, pamiętasz, jak pisaliśmy książkę?) system ten był atakowany, jako “wizualnie podrasowany Windows 2000”. Ten artykuł wyraźnie pokazuje, że tak nie było. I analogicznie jest teraz, gdy Windows Vista jest “niczym więcej jak XP z glutożerkami”. Ale wracając do tematu, poza zwiększeniem wydajności systemu, Prefetch jest przydatny w przypadku, gdy trzeba zbadać co się stało w systemie (bo ktoś/coś wlazło).
Postanowiłem napisać kilka słów na temat testów penetracyjnych , głównie w celu uporządkowania pojęć i wyobrażeń odnośnie tego tematu. Trochę temat zawężę skupiając się na aplikacjach internetowych (webowych), choć można to wprost przenieść na przykład na testy penetracyjne infrastruktury sieciowej.
Opieranie bezpieczeństwa na ukrywaniu informacji o wykorzystanych rozwiązaniach nie ma prawa być skuteczne. Z drugiej jednak strony przyjęło się, że należy minimalizować ilość informacji, jakie system dostarcza o sobie, swoim działaniu, występujących błędach i wykorzystywanych komponentach. W przypadku aplikacji webowej komponentem, który jest najbardziej chyba widoczny, jest serwer WWW. Zwykle usuwa się ze zwracanych przez serwer nagłówków informację nie tylko o wersji serwera, ale również o jego typie. Często również wstawia się informację fałszywą, po to, by zmylić atakującego, lub raczej narzędzia/skrypty opierające się na zwracanej przez serwer identyfikacji wykorzystanego oprogramowania.
(...) stale pracuje podwyższyć bezpieczeństwo dla wszystko online liczące użytkownicy. Żeby zapewnić całość naszego online systemu wpłaty, my okresowo recenzujemy rachunki.
Wasz rachunek był umieszczany na trzymają należne do licznych login zakusów do waszego rachunku. Skrępujcie rachunki nie potrafią otrzymać wpłaty, posyłają wpłaty albo cofają szkatułę
Wszystko ograniczyło rachunki mają ich billing informacja unconfirmed, dopóki updated na registratorze.
Żeby zapoczątkować update bierzmowanie proces, wy teraz czytujecie spotrzebowane żeby pójść za ogniwem poniżej i podsadzacie potrzebne pola. Uprzejmie trzasnąć na ogniwie poniżej dalej ciągnąć z procesem sprawdzenia i zapewniają bezpieczeństwo waszego rachunku.
Po pierwsze – nie lubię tego filmu. Albo inaczej – zupełnie nie rozumiem jego kultowości. Ale ja nie o tym. Podobnież żyję we własnym matriksie (znaczy się w swoim małym, własnym świecie). Tak dzisiaj usłyszałem w wyniku dyskusji o:
Był sobie projekt o nazwie tcgina. Niestety, okazuje się, że wraz z nadejściem wersji 5.0 TrueCrypt został on ubity...
This third-party project has been removed since it no longer extends the functionality of TrueCrypt. Note that TrueCrypt 5.0 introduced the ability to encrypt a system partition or entire system drive, which is more secure and more reliable than the methods used by the removed projects (for more information, see the chapter System Encryption in the TrueCrypt User Guide).
Ciekawe, czy projekt rzeczywiście “przestał istnieć”, czy tylko stracił status “oficjalnego” third-party project. Zupełnie nie zgadzam się ze stwierdzeniem, że tcgina wraz z pojawieniem się wersji TrueCrypt 5.0 straciła rację bytu.
Dlaczego klucze warto mieć na karcie, a nie “w sofcie” (czyli na dysku w postaci pliku)? To proste, z karty klucz nie może zostać “wyciągnięty” (pomijając te przypadki, kiedy może, ale to już specyfika implementacji), a i użytkownik ma lepszą kontrolę nad tym, kiedy klucze na karcie są używane, bo musi podać kod PIN w celu ich “odblokowania”.
Ostatnio przeglądałem sobie statystyki mojego bloga (permanentna inwigilacja, a co!). Jednym z ciekawych obszarów jest analiza słów kluczowych, za pośrednictwem których goście trafiają na stronę. Oczywiście głównym “źródłem odwiedzin” są wszelakie kombinacje słowa wep z łamaniem. Ostatnio jednak pojawił się również nowy obszar zainteresowania. Tak, to nasza-klasa. Ktoś (i to więcej niż jedna osoba) usiłuje się dowiedzieć jak złamać hasło do naszej klasy. No to zabawmy się :)
Ostatnio pisałem o usuwaniu plików. Wyszło na to, że sdelete jest lepszy niż cipher. Ale jak się okazuje, nawet sdelete może zostawić na dysku sporo ciekawych danych...
Jakiś czas temu Microsoft wprowadził w IE obsługę dodatkowej flagi httpOnly dla cookies. Mówiąc obrazowo zastosowanie tej flagi ukrywało oznaczone nimi cookies przed skryptami, co znacznie zmniejszało skutki ewentualnego wykrycia jakiegoś XSS na stronie. Po prostu “wstrzyknięty” za pośrednictwem XSS skrypt nie jest w stanie wykraść oznaczonego tą flagą cookie z identyfikatorem sesji, a więc przejęcie sesji nie jest możliwe (w ten sposób). Przez długi czas flaga ta była obsługiwana wyłącznie przez IE. Okazuje się jednak, że uznawanie w chwili obecnej tej flagi za rozszerzenie specyficzne dla IE jest błędem. Jest ona obsługiwana zarówno przez Firefoxa (od wersji 2.0.0.5) jak i będzie obsługiwana przez Operę (od wersji 9.5 b1). Innymi słowy – cookie sesyjne poza flagą secure powinno mieć również flagę httpOnly.