Pod adresem http://bootcamp.threats.pl/lesson09a/ znajduje się prosty przykład “aplikacji”, która nie do końca poprawnie stosuje encoding danych wyjściowych. Przekazane dane są wypisywane w kilku miejscach, w różnym kontekście z wykorzystaniem różnego encodingu. Każdy z zastosowanych sposobów encodingu danych pozwala na XSS (na różne sposoby), choć nie w każdym(?) kontekście.
To tak w nawiązaniu do tego, że właściwy encoding jest trudny. W przeciwieństwie do encodingu, ten przykład trudny specjalnie nie jest. Miłej zabawy!
P.S. W zasadzie można się zastanawiać, czy i w którym przypadku stosowany jest encoding, a w którym escaping.
Gmail zaczął witać swoich użytkowników w następujący sposób:
O tym, że warto mieć unikalne hasła w różnych serwisach mówi się zwykle wówczas, gdy pojawia się jakaś informacja o możliwym wycieku danych użytkowników (w szczególności haseł lub stosunkowo łatwych do złamania hashy) z jakiegoś bardziej lub mniej popularnego serwisu. Zastanawiam się jakie są efekty takich dyskusji i jaki będzie efekt informacji wyświetlanej w Gmailu.
Ja tylko po raz kolejny podpowiem, że do przechowywania haseł i do generowania unikalnych haseł do różnych serwisów można wykorzystać na przykład KeePass. O tym, jak z niego korzystam pisałem tutaj: Jak korzystam z KeePass.
Drodzy programiści! Zapamiętajcie sobie dwie proste rzeczy:
wszystkie dane pochodzące z niezaufanego źródła (np. od użytkownika) przed użyciem trzeba zakodować w sposób właściwy dla kontekstu użycia,
właściwy encoding jest trudny,
W związku z tym bardzo proszę, nie róbcie tego sami, bo zrobicie to najprawdopodobniej źle. Zamiast tego wykorzystajcie proszę dostępne w bibliotekach (np. ESAPI, Microsoft Web Protection Library) funkcje napisane przez ludzi, którzy w temacie siedzą nieco głębiej. Przecież w wielu innych przypadkach nie wynajdujecie koła na nowo, tylko korzystacie z tego, co ktoś już napisał i się sprawdziło. Dlaczego z bezpieczeństwem ma być inaczej?
Jeśli już musicie robić to sami, to proszę, popatrzcie jak zrobił to ktoś, kto zrobił to dobrze. Choćby tutaj. Nawet jeśli okaże się, że w takich implementacjach są błędy, to prawdopodobnie będzie ich mniej, niż w tych “własnej roboty”, a i szansa na szybkie usunięcie jest zdecydowanie większa.
Oczywiście jest jeszcze walidacja danych wejściowych, ale to jest nieco inny temat.
Dziś wpis na temat różnicy między zagrożeniem a ryzykiem. Może najpierw na przykładach, przez wyliczenie. Przykładowe zagrożenia, bez specjalnego tematu przewodniego:
W cytowanym wpisie postawiłem następujące pytanie:
(...) w jakim przypadku opisany sposób uzyskania potwierdzenia przelewu, który w rzeczywistości nie został wykonany, jednak ma (większy) sens?
Odpowiedź pojawiła się w komentarzach do wpisu. A w oderwaniu od szczegółów można ją sprowadzić do stwierdzenia, że pozyskanie potwierdzenia przelewu z banku przed wykonaniem tego przelewu ma sens wówczas, gdy atakujący nie może go (dokładnie) sfałszować. W komentarzach pojawił się wątek podpisu cyfrowego i jest to właśnie ten przykład, który miałem na myśli.
Dziś w ramach ciekawostki zapomniana sztuka pisania \*.bat. Ale najpierw kontekst. A kontekstem jest to pytanie:
(...) Pamiętam konkretne cyfry, liczby, symbole i wyrazy ale po kilku latach nie pamiętam kolejności a kombinacji przy haśle ok 15-25 znakowym jest za dużo by klepać na piechotę. Czy ktoś może mi poradzić jak stworzyć słownik do “jakiegoś programu” który w miarę szybko by pokombinował... (...)
Jakiś czas temu pojawiła się potrzeba połączenia dwóch lokalizacji poprzez VPN site-to-site. Ponieważ użytkownikiem tego połączenia miała być osoba, która jest użytkownikiem właśnie (aczkolwiek muszę przyznać, że raczej zaawansowanym), szukałem rozwiązania “pudełkowego”. Takiego, który zarówno w używaniu, jak i utrzymaniu będzie możliwie mało absorbujący. Bardzo ważnym parametrem była również cena. Nie mam sumienia polecać komuś rozwiązania klasy UTM, które może i potrafi więcej, ale to “więcej” jest kompletnie nieprzydatne w konkretnym przypadku.
Korzystając z otrzymanych sugestii zdecydowałem się na urządzenia RB750GL. Co do możliwości samego RouterOS nie miałem wątpliwości, pewną niewiadomą była nato miast wydajność tych urządzeń w IPSec. Umówmy się, że sprzętowo nie są to jakieś potworne bestie. Z drugiej strony parametry łącza, na którym VPN ma zostać zestawiony, powodowały, że już 2 Mbit/s byłoby akceptowalną przepustowością. Okazuje się, że urządzenia te w AES-256 osiągają do 13 Mbit/s. Po skonfigurowaniu reguł firewalla ta przepustowość spada mniej więcej do 11 Mbit/s, ale i tak jest to bardzo przyzwoite osiągnięcie.
Ogólnie moje wrażenia są bardzo pozytywne. Tak bardzo, że zastanawiam się poważnie nad zakupem RB751U-2HnD. Dla siebie.
Pod wpisem 0b10 | 0b01 exploit Kravietz umieścił kilka ciekawych myśli. Na przykład w tym komentarzu poruszony został temat, który chciałbym rozwinąć. Zacznijmy od myśli przewodniej:
Ale mechanizm bezpieczeństwa, żeby działał, musi być relewantny. (...)
Po długiej przerwie udostępniam dwa nowe videocasty w ramach cyklu Bootcamp: Bezpieczeństwo aplikacji internetowych. Oba odcinki dotyczą możliwości wykorzystania skryptów w narzędziu Fiddler. Oczywiście wszystko po to, by ułatwić sobie życie.
Krótkie nawiązanie do poprzedniego wpisu. Trochę dlatego, że pojawiło się kilka komentarzy, a i nowy egzemplarz spamu również w filtrach się zatrzymał.
