Od czasu do czasu pojawiają się oferty pracy dla osoby, która ma zajmować się bezpieczeństwem tworzonej aplikacji (webowej), między innymi projektowaniem architektury bezpieczeństwa tej aplikacji. Na podstawie takiego ogłoszenia można typować w jakim języku napisana jest dana aplikacja (tak, zwykle w FooBar). I tu pojawia mi się wątpliwość, czy rzeczywiście przy tego typu stanowisku ta “bardzo dobra znajomość” jest rzeczywiście niezbędna.
Ten wpis powstał w ramach zbierania myśli przy przygotowaniu prezentacji, którą ostatnio prowadziłem naForum Bankowości Elektronicznej. Całość dość ogólna, bez technicznego “mięsa”, ale taka jest specyfika tego typu imprez i chyba nie pozostaje nic innego, jak pogodzenie się z nią. Zresztą ankiety oceniające prezentacje pokazują, że uczestnicy takich imprez właśnie takiego przekazu oczekują.
Całość wypada zacząć znanym powiedzeniem:
Kto stoi w miejscu, ten się cofa, bo cały świat idzie do przodu.
Tak samo jest w przypadku bankowości. Funkcjonowanie banków, oferowane produkty i sposób ich oferowania, zmienia się. Często wykorzystywane są najnowsze technologie. Wszystko po to, by klienta obsługiwać w sposób bardziej efektywny, bardziej nowoczesny, zgodny z jego oczekiwaniami.
Postępu nie można ignorować, jeśli ktoś nie chce utracić swojej pozycji, musi wprowadzać do swojej oferty nowe produkty i oferować je w sposób oczekiwany przez klientów. Musi korzystać z nowych technologii. Ale co z bezpieczeństwem?
W tym zakresie tematów jest wiele, tym razem chcę poruszyć tylko te:
Jedną z podstawowych definicji/wymagań odnośnie bezpieczeństwa w kryptografii jest semantic security. Chodzi w niej o to, że atakujący dysponujący wiedzą o algorytmie szyfrowania i zaszyfrowanymi wiadomościami nie może powiedzieć na ich temat nic innego, poza określeniem ich długości.
Tak, pisałem już o tym wielokrotnie. Ale napiszę jeszcze raz. Drogi X. Pamiętaj, że świat jest pełen złych ludzi. Ludzi, którzy zastanawiają się jak wykorzystać każdą rzecz, którą zrobisz dla swojej korzyści. To dobrze, że w trosce o wygodę swoich użytkowników wprowadzasz coraz to nowe, bardziej zaawansowane, nowatorskie funkcje. Spróbuj jednak za każdym razem gdy żądasz/proponujesz/implementujesz kolejną ociekającą fajnością funkcję zastanowić się przez chwilę jak ta funkcja może zostać wykorzystana przez złych ludzi do ich złych celów. Uwierz mi, oni są pomysłowi i gotowi na wiele...
Podam Ci taki obrazowy przykład. To miło, że Twój klient lubi psy. Takie prawdziwe, duże psy. Nie takie nie wiadomo co, które można przypadkiem nadepnąć, przysiąść na kanapie, albo które w trakcie spaceru mogą niespodziewanie odfrunąć do krainy wiecznej szczęśliwości w szponach przypadkiem przelatującego ptaka drapieżnego. To dobrze dla Ciebie, że zdecydował się kupić drzwi Twojej produkcji. Wzmacniane, ze skomplikowanym systemem zamków i blokad. Takie drzwi, dzięki którym ich posiadacz może być pewien, że żaden nieproszony gość nie zjawi się u niego w domu. Ale pomyśl, czy na pewno dobrym pomysłem było dodanie do tych drzwi uchylnej klapki, przez którą pupilek Twojego klienta, wielkości średnio wyrośniętego cielaka, może swobodnie wchodzić/wychodzić do/z domu bez angażowania swojego właściciela do otwarcia drzwi? Ja wiem, my homo sapiens jesteśmy potomkami homo erectus. Ale obawiam się, że osoba, która chce się dostać do środka, niekoniecznie w cnych zamiarach, będzie skłonna do chwilowego schowania dumy do kieszeni i wykorzysta to uchylane udogodnienie do swoich celów. Na czworakach.
I nawet nie są wymagane takie zdolności:[Squeeze](http://en.wikipedia.org/wiki/Squeeze(TheX-Files)). A to, że ten odcinek jest więcej niż pełnoletni, to...
Oryginał tego wpisu dostępny jest pod adresem Świat jest pełen złych ludzi. Pomysłowych złych ludzi.
Autor: Paweł Goleń
Zacznijmy od końca. Jest coś takiego jak principle of good enough. W wielu przypadkach rzeczywiście wystarczające jest zastosowanie rozwiązania, które jest wystarczająco dobre. A skoro temat ten pojawia się u mnie, można przypuszczać, że będzie o aplikacjach internetowych i bezpieczeństwie. I tak rzeczywiście będzie.
Mam wrażenie, że czasami jest pewien problem ze zrozumieniem tego, czym jest ten XSS i co daje on atakującemu. Podejrzewam, że dla większości osób w jakiś sposób zorientowanych w temacie bezpieczeństwa stwierdzenie możliwość wykonania koduw kontekście atakowanej aplikacji mówi wszystko. Z drugiej strony są osoby, dla których to zdanie brzmi mniej więcej tak: bla bla bla, bla bla bla, bla bla. Postaram się w prosty sposób to zagadnienie wyjaśnić.
Czasami ktoś się coś o mnie pyta. Tym razem dostałem od Mateusza następujące pytanie (fragment):
Podłaczając się do sieci wi-fi (budżetowy, domowy routerek np. D-Link, Linksys). Czy jest możliwe podsłuchanie ruchu https? Rozumiem, że można przeprowadzić atak ARP Spoofing, ale w takim przypadky przy wejściu na stronę zabezpieczoną https, otrzymam komunikat o 'problemie' z certyfikatem. A czy istnieją sztuczki, które pozwolą taki ruch (https) przechwycić i odczytać zawartość, bez powiadamiania użytkownika o problemie z certyfikatem?
Tu są co najmniej dwa tematy. Bezpieczeństwo wifi i bezpieczeństwo HTTPS.
Właśnie przygotowuję się do kolejnej edycji szkolenia z bezpieczeństwa aplikacji internetowych. W tak zwanym międzyczasie miało miejsce kilka spektakularnych wycieków haseł i hashy haseł.
Tak w ramach ciekawostki polecam zapoznanie się z artykułem Our password hashing has no clothes. Troy Hunt pokazuje w nim eksperymentalnie jak efektywne może być łamanie hashy haseł z wykorzystaniem kart graficznych (w tym wypadku: AMD Radeon HD 7970). W tym wypadku atakowane były hashe SHA1, wykorzystany był salt. Jest to o tyle istotne, że ten sposób przechowywania haseł jest domyślny w ASP.NET jeśli korzysta się z domyślnego providera (choć to się zmienia: Stronger password hashing in .NET with Microsoft’s universal providers).
Dla porządku napiszę to jeszcze raz – jeśli masz przechowywać hasła, korzystaj z czegoś w rodzaju bcrypt, scrypt czy PBKDF2. Pamiętaj, że nawet wówczas hashe haseł nie są nieśmiertelne. Kupujesz im tylko trochę więcej czasu.
I ponownie porada dla użytkowników:
Oryginał tego wpisu dostępny jest pod adresem Czas sobie mija... Hasła dalej ciekną
Autor: Paweł Goleń
OWASP ASVS jest fajny, ale są takie punkty na tej liście, które są dyskusyjne i trochę zależą od interpretacji, albo nie zawsze pasują do wykorzystanego w danym przypadku środowiska. Dziś trochę na temat jednego z takich punktów dotyczącego zarządzania sesją:
V3.2 Verify that sessions are invalidated when the user logs out.
Gynvael już wspomniał o konferencji Security BSIDEs Polska, umieścił również agendę, z której jasno wynika, że pojawię się na niej. Konkretnie będę mówił o aplikacjach mobilnych, dokładniej o mechanizmach uwierzytelnienia w tych aplikacjach i o tym, jak mechanizm ten można spektakularnie zepsuć...
Oryginał tego wpisu dostępny jest pod adresem Security BSIDEs Polska
Autor: Paweł Goleń