Analizując bezpieczeństwo aplikacji internetowych warto spojrzeć czasami na bezpieczeństwo klienta, czyli na przeglądarkę. Warto przeczytać Browser Security Handbook, choćby po to, by zobaczyć jak różnią się między sobą przeglądarki... Kwestia ta będzie miała coraz większe znaczenie, ponieważ coraz więcej kodu aplikacji wykonuje się po stronie klienta (choćby wspominany już AJAX). O ile “środowisko wykonania” w postaci serwera WWW/serwera aplikacyjnego może być dość dobrze kontrolowane, to środowisko wykonania w postaci przeglądarki kontrolowanej w całości przez klienta jest sporym wyzwaniem. Warto więc poznać cechy charakterystyczne głównych przeglądarek, ich mechanizmy bezpieczeństwa oraz słabości.
Część języków programowania zawiera funkcję eval lub jej funkcjonalny odpowiednik. Można tu przywołać (choćby) JavaScript, Python, PHP, Perl, Smalltalk. Problem w tym, że eval jest czasami nadużywany i przez to ZŁY!
Czym są giblets (tak bez spolszczenia pozwolę sobie)? Jest to termin pochodzący z Security Development Lifecycle, który oznacza fragment kodu (nie koniecznie rozumianego jako kod źródłowy) pochodzącego z zewnętrznego źródła. Jest z tym pewien problem: Larry Osterman's WebLog : The Trouble with Giblets. W skrócie – obcy kod może być ZŁY, a wraz z nim dostaje się poniekąd “w prezencie” istniejące w nim podatności.
W przypadku użycia zewnętrznego kodu warto przyglądnąć się jego historii błędów, temu jak jest rozwijany (i czy jest jeszcze rozwijany)... a potem jeszcze śledzić informacje o błędach i aktualizować.
Wczoraj napisałem kilka słów o różnych timestampach zwracanych przez LogParser dla różnych formatów wejściowych. Dziś jeszcze kilka słów w tym temacie.
Tak w formie marudzenia. LogParser jest doskonałym narzędziem, ale czasami bywa irytujący. W sumie może nawet nie tyle sam LogParser , co te wszystkie dziwne strefy czasowe, czasy letnie/zimowe i inne tego typu wynalazki.
Edmond Locard sformułował zasadę mówiącą (mniej więcej), że każdy kontakt pozostawia ślad, innymi słowy, przestępca zostawia coś na miejscu przestępstwa i coś stamtąd zabiera. Zasada ta jest prawdziwa nie tylko dla “tradycyjnej” kryminalistyki, ale i dla informatyki śledczej.
Może mi ktoś wytłumaczyć, dlaczego instalując różnego rodzaju oprogramowanie (a naprawdę wcale nie instaluję go zbyt dużo) jestem na siłę uszczęśliwiany tworami typu Google Update Service czy Java Quick Starter? Tak, wiem, Java Quick Starter robi mi dobrze (na siłę): Prefetches JRE files for faster startup of Java applets and applications Ale ja ich nie chcę! Nie chcę jakiegoś (..) kawałka softu, który pracuje w dodatku z prawami LocalSystem. W dodatku JRE uszczęśliwia mnie tą usługą “po cichu”, nie informując mnie, że wprowadzone zostało to “rewolucyjne” usprawnienie. Ech...
Zabawię się w pogromcę mitów... Dość często różni “znawcy” bezpieczeństwa Windows podają prosty przykład na uruchomienie programu z prawami użytkownika SYSTEM jako dowód na to, że system jest niebezpieczny. Problem w tym, że... nie jest to żadna podatność.