Helix 2.0
Kilka dni temu pojawił się Helix 2.0. Informacje o zmianach w stosunku do poprzedniej wersji dostępne są w release notes.
Kilka dni temu pojawił się Helix 2.0. Informacje o zmianach w stosunku do poprzedniej wersji dostępne są w release notes.
W 2000 roku pojawił się esej 10 Immutable Laws of Security. Dziś, 8 lat później można zastanawiać się, czy te prawa nadal pozostają niezmienne. Pierwszy odcinek serii dostępny jest tu: Security Watch Revisiting the 10 Immutable Laws of Security, Part 1.
Nie lubię korków. Irytują mnie. Chciałbym, by ich nie było, by nie było tych, by ulice nie były zastawione samochodami wożącymi głównie powietrze. Zwykle jeździłem autobusem (w lecie rowerem). Nawet wtedy, gdy wejście do autobusu wiązało się z walką taką, jaką nasi praprzodkowie musieli toczyć o ogień (śmierdzących ludzi nie byłem w stanie znieść, stąd ucieczka w rower). Znam serię listów motorniczego krakowskich tramwajów (Zwierzenia krakowskiego motorniczego ). Ale nawet moja cierpliwość ma swoje granice. Byłem w stanie zaakceptować nawet to, że rozkład jazdy to fikcja, trudno, byłem gotowy na 10 minut oczekiwania (częstotliwość kursowania autobusu), ale teraz, gdy wartość ta zwykle przekracza 20 minut (czas jazdy rowerem), a często podziwiam okolice przystanku 30 i więcej minut, czas powiedzieć dość. Trudno, przeboleję wstawanie godzinę wcześniej (by uciec przed korkami i znaleźć miejsce parkingowe). Od jutra przesiadam się na samochód (moje zatoki źle znoszą “złotą polską jesień”)...
Ciąg dalszy tematu haseł. Tym razem kilka słów o tym, dlaczego szyfrowanie haseł w plikach konfiguracyjnych (szyfrowanie plików konfiguracyjnych) często w praktyce nie zwiększa poziomu bezpieczeństwa.
Ostatnio na BugTraq pojawiła się następująca wiadomość:
Pidgin IM Client Password Disclosure Vulnerability (...) The credentials used to connect to the required service i.e. username and password is not encrypted properly. The credentials can be extracted in clear text by dumping process memory of the live pidgin process when a connection is set. The vulnerability allows anyone with access to the client system to obtain the username and password. (...)
Czy to źle?
A te kilka słów chcę napisać, bo z wydajnością jest często po prostu źle. Bardzo często jest tak, że do załadowania jednej strony potrzebnych jest kilka(naście|dziesiąt) odwołań do serwera. Warto tutaj zaznaczyć, że klient (przeglądarka) nie może nawiązywać dowolnej ilości połączeń do serwera, dobrze zachowujący się klient nawiązuje jednocześnie co najwyżej dwa połączenia do jednego serwera (patrz RFC 2068). Co się dzieje, jeśli w ramach tych dwóch połączeń do załadowania strony trzeba ściągnąć 150 elementów, różnego rodzaju obrazków, plików ze skryptami, definicji stylów CSS, łatwo się domyślić. Jak to można rozwiązać?
Można rozdzielić treść dynamiczną od treści statycznej. Obrazki, skrypty, arkusze stylów mogą być pobierane z innych serwerów, niż “główna” treść. Pozwala to na równoległe pobranie większej ilości danych w jednostce czasu (bo jeśli serwerów jest 6, to przeglądarka może nawiązać 12 połączeń). Ale jeszcze lepiej, by przeglądarka tych połączeń nie musiała nawiązywać. Nie chodzi mi tu o różne techniki “konsolidacji” plików (Data URI Support), ale o efektywne wykorzystanie mechanizmów cache (pamięci podręcznej). Bardzo często mam okazję oglądać, jak przy każdym kolejnym ładowaniu strony, przeglądarka wysyła żądania o praktycznie każdy element graficzny tej strony. Co prawda dostaje od serwera odpowiedź 304 i treść nie jest pobierana, ale samo żądanie jest wysyłane. Po co? Czy obrazki zmieniają się tak szybko? Skrypty? Arkusze stylów? Śmiem wątpić. Ustawienie “czasu życia” (czyli w praktyce na przykład nagłówka Expires) takiego obrazka nawet na godzinę spowodowałoby, że tych żądań zakończonych odpowiedzią serwera 304 byłoby zdecydowanie mniej. To nie jest tak, że w przypadku “bezpiecznych aplikacji webowych” zawsze należy ustawić nagłówek Cache-control na no-store!
W przypadku aplikacji ASP.NET zauważyłem, że często wykorzystywany jest mechanizm WebResource.axd. Według informacji znajdującej się tu: Don’t run production ASP.NET Applications with debug=”true” enabled mechanizm ten jest “samooptymalizujący się”, czyli “na produkcji” automatycznie ustawiany jest “długi czas życia” zwracanych w ten sposób treści. Jeśli treści te zwracane są bez stosownych nagłówków, to można założyć, że aplikacja jest właśnie w wersji debug, co w trakcie testów penetracyjnych może być interesującą informacją. Trochę irytujące może być natomiast obserwowanie, jak po raz kolejny pobierane są te same skrypty i obrazki.
Fiddler pozwala na łatwe ukrycie odwołań do obrazków czy sesji, w których serwer zwrócił odpowiedź 304. Przy zapisywaniu takiej sesji (no trzeba mieć historię działań) okazuje się nagle, że poza 100 sesji widocznych w UI jest jeszcze kilkaset sesji (odwołań do plików), które zostały wyfiltrowane. To naprawdę jest spory problem.
Warto wspomnieć o narzędziach wspomagających optymalizację stron pod względem ich wydajności. Po pierwsze wspominany już Fiddler ma rozszerzenie Timeline , które pozwala w graficznej formie przedstawić proces ładowania strony. Warto też zapoznać się z Fiddler PowerToy – Part 2: HTTP Performance. Po drugie potężna wtyczka Firebug ma rozszerzenie YSlow, które potrafi przeanalizować wskazaną stronę i wskazać obszary wymagające poprawy, a następnie odesłać do odpowiedniego fragmentu Best Practices for Speeding Up Your Web Site.
Oryginał tego wpisu dostępny jest pod adresem Coś z zupełnie innej beczki: wydajność – ilość requestów
Autor: Paweł Goleń
Taka mała :)
Krótki przykład jak NIE należy implementować walidacji danych wejściowych...
Pojawiła się wersja PyFlag dla Windows. Chyba w końcu uda mi się sprawdzić to narzędzie. Przy okazji warto też wspomnieć o PlainSight, kolejnym narzędziu (właściwie środowisku) w kolejce do sprawdzenia.
Jest sobie gazeta, która przez przypadek publikuje ponownie stary artykuł dotyczący problemów finansowych pewnej firmy. Agregator wiadomości uwzględnia ten artykuł, trafia on do inwestorów. Inwestorzy w panice wyprzedają akcje. Kurs akcji spada. Hipotetyczny scenariusz? No nie bardzo: Blamestorming. Swoją drogą polecam książkę Dług Honorowy.