Jeśli kogoś interesuje kryptografia, to 11 czerwca startuje kolejna edycja kursu ze Stanford University. Jak rozumiem będzie to ten sam materiał, który był prezentowany od 12 marca. Druga część kursu (kolejne tematy) mają pojawić się jesienią. A przynajmniej jak na razie taka wersja jest obowiązująca:
The class starting on June 11 is mostly identical to the crypto class that just ended. It will run for six weeks and cover the same material. The extended class with new material is planned for the fall and will be called Crypto II.
Polecam. Materiał ciekawy, zadania programistyczne... Cóż, powiedzmy, że najwięcej problemów miałem ze zmieszczeniem wystarczająco dużych struktur danych w pamięci na moim 32 bitowym systemie. Oczywiście pisałem w Pythonie (zupełnie wystarczające narzędzie do zadań). Jeśli ktoś ma 64 bitowy system, to zadania można uznać za trywialne. Może ciut trudniej było po przejściu do kryptografii asymetrycznej, ale znów problemem nie było programowanie, tylko liczenie. Na początek kartka i długopis, a potem było już z górki.
A ja jestem na siebie z lekka zły, bo w Final Exam przez głupie pomylenie ½n z 1/n2 zamiast tradycyjnych 100%25 mam tylko 92%25. Chlip...
Miałem okazję ostatnio prowadzić kilka iteracji szkolenia dotyczącego bezpieczeństwa aplikacji internetowych. Było to ciekawe, ale i wymagające doświadczenie (również fizycznie, zwykle nie pracuję głosem). Po podsumowaniu ankiet oceniających szkolenie jestem z siebie dumny :) Generalnie oceny powyżej 5 punktów (zakres 1 – 6).
Szkolenie było interesujące dla mnie również z innego powodu. Do czasu, gdy obracam się w grupie ludzi związanych z pewnym tematem, wiele rzeczy jest “powszechnie znane” i “oczywiste”. Gdy nagle zmienia się otoczenie, okazuje się, że to wcale tak oczywiste nie jest...
Atak na profil zaufany ogranicza się do przejęcia kontroli nad skrzynką poczty elektronicznej użytkownika, co umożliwia całkowite przejęcie wykorzystania profilu zaufanego przez atakującego.
Chodzi oczywiście o funkcję “przypominania” hasła. ePUAP nie jest ani pierwszą, ani jedyną aplikacją, w której mechanizm ten został zaimplementowany źle.
Zajęty jestem ostatnio i to na wiele różnych sposobów. Chcę tylko zwrócić uwagę na ten post na Niebezpieczniku: Zakupy przez internet za darmo? Poważny problem systemu płatności Sofort. Mam pewne wątpliwości, czy wycofanie przelewu jest rzeczywiście problemem. Mam na myśli to, co się stanie “potem”. Taka akcja to oszustwo, które podpada pewnie pod kilka różnych paragrafów. Przekręt musiałby być naprawdę na dużą kasę, by się opłacać. Zresztą w treści artykułu ten wątek jest też poruszany.
Przejrzałem sobie komentarze pod tym wpisem i mam wrażenie, że ich autorzy mają nieco przyciasne horyzonty (nie, to nie jest obraza). Praktycznie nikt nie zwrócił uwagę na fakt, który poruszył viroos (mówię o komentarzach). Dlaczego ktoś korzysta z usług Sofort (w sensie – integruje się z tym systemem płatności)? Odpowiedź – bo jest to tańsze niż inne dostępne rozwiązania. A dlaczego ktoś z tego korzysta? Dlatego:
Musząc wybrać między obejrzeniem tańczących świnek a bezpieczeństwem, użytkownicy za każdym razem zdecydują się na świnki.
W treści posta pojawia się takie tłumaczenie:
Paweł Fornalski: Podstawą bezpieczeństwa klienta jest to co firma robi z jego danymi i jej zasady etyczne, a nie zastosowane technologie.
Nie do końca zgadzam się z tym stwierdzeniem, ale częściowo jest ono słuszne. Jest ono słuszne w tym względzie, że technologie to jeszcze za mało, by zapewnić bezpieczeństwo. Etyka rzeczywiście ma tutaj również swoje miejsce.
Temat zostawiam Wam do przemyślenia.
Oryginał tego wpisu dostępny jest pod adresem Sofort
Ten temat po części już poruszałem we wpisie Niekonsekwencje w ASP.NET, ale postanowiłem do niego wrócić. Część rzeczy się powtórzy, więc ewentualne uczucie Deja vu jest uzasadnione. Chodzi o to, w jakich przypadkach ASP.NET sam zastosuje odpowiedni encoding, a w jakim programista musi sam o to zadbać.
Raz na jakiś czas spotykam się z mechanizmem, którego przeznaczenia nie rozumiem. Albo inaczej – nie jestem w stanie zrozumieć, dlaczego ktoś myśli, że ten mechanizm będzie działać. Na przykład ładnych już kilka lat temu w trakcie pracy nad projektem pewnej aplikacji jej dostawca zaproponował, by wprowadzić dodatkową warstwę szyfrowania przy przesyłaniu formularzy na serwer. Połączenie z serwerem miało być oczywiście realizowane standardowo przy pomocy SSL, natomiast jeszcze sama aplikacja po stronie klienta miała szyfrować dane przed ich wysłaniem do serwera. Miało to być zabezpieczenie przed atakiem typu man-in-the-middle. Ostatecznie funkcja ta nie została zaimplementowana, i dobrze.
Dziś będzie krótko. Na początek odsyłam do tekstu, do którego chcę się odnieść: A czy Twój bank jest odporny na ataki UI Redressing – Clickjacking? A teraz konkretniej – ja z UI Redressing mam pewien problem. To jest doskonała podatność do pokazywania na konferencjach, szkoleniach, prezentacjach. Jest bardzo efektowna , ale już z jej efektywnością bywa różnie. Tekst, do którego odsyłam, dotyczy bankowości internetowych. Obawiam się, że w tym konkretnym przypadku z efektywnością (czyli skutecznością) tego typu ataku byłoby bardzo słabo.
Wdałem się ostatnio w nieco dziwną dyskusję odnośnie tego, czy każdy wyjątek występujący w aplikacji powinien być obsłużony. Dla uściślenia chodzi mi tutaj o aplikacje webowe i wyjątki występujące w wyniku manipulacji przez użytkownika przekazywanymi danymi.
Moim zdaniem obsługiwanie każdego wyjątku na siłę po to, by było “ładnie” nie jest dobrym pomysłem. Na przykłada dlatego, że do obsługi takiego wyjątku potrzeba jakiegoś kodu, a im więcej linii kodu, tym większe prawdopodobieństwo wystąpienia błędu. Jeszcze gorsze rzeczy mogą się dziać, jeśli kod obsługi wyjątku będzie usiłował “naprawić” sytuację wyjątkową i kontynuować wykonanie kodu (i to nawet wówczas, gdy nie ma to większego sensu). W takich przypadkach często jest lepiej po prostu przerwać wykonanie kodu, a nieobsłużony wyjątek robi to zwykle dość skutecznie.
Oczywiście można też patrzeć na sprawę w inny sposób. Co się stanie, jeśli wyjątek wystąpi w trakcie jakiejś operacji? Być może jakiś obiekt/proces/cokolwiek zostanie wówczas w osieroconym stanie i być może będzie można to w jakiś sposób wykorzystać. Pomijam tu również sytuację, gdy nieobsłużony wyjątek skutkuje wyświetleniem jakże przydatnych dla atakującego informacji (stacktrace).