Temat dotyczy konfiguracji firewalli WEWNĄTRZ naszej sieci. Spotkałem się z nim dawno, dawno temu, jak jeszcze zajmowałem się administrowaniem, między innymi administrowaniem urządzeniami sieciowymi, ale wciąż jest żywy. Mogę powiedzieć nawet, że teraz jest bardziej aktualny niż kiedyś, bo w coraz większej ilości sieci są one podzielone na strefy, a samo filtrowanie dotyczy nie tylko ruchu przychodzącego, ale również wychodzącego.
To teraz pytanie – czy używać akcji DROP czy REJECT?
7 grudnia w Krakowie będzie miał miejsce TechCamp #6. Przez 20 minut będę mówił na nim o tym, że dane zaszyfrowane wcale nie muszą być bezpieczne. Jeśli ktoś czyta mojego bloga w miarę regularnie, powinien wiedzieć o co chodzi :)
Oryginał tego wpisu dostępny jest pod adresem TechCamp #6
Michał Zalewski w książce The Tangled Web zawarł następującą myśl:
The only reasonable approach to tag sanitization is to employ a realistic parser to translate the input document into a hierarchical in-memory document tree, and then scrub this representation for all unrecognized tags and parameters, as well as any undesirable tag/parameter/value configurations.
Niestety, często programiści myślą, że są w stanie oczyszczać HTML łatwiej. I wciąż pokutuje tutaj podejście oparte na blackliście niedopuszczalnych tagów/atrybutów/zdarzeń. Takie podejście to proszenie się o kłopoty.
Częstym problemem jest zabezpieczenie aplikacji/systemu przed klientem, który chce z tego systemu, lub jakiejś jego funkcji, korzystać zbyt często. Potrzeba takiego ograniczenia może wynikać z różnych przyczyn. Może to być na przykład zabezpieczenie przed masową enumeracją danych, ale równie dobrze powód może być bardziej trywialny – ochrona przed wyczerpaniem zasobów. Może byc na przykład tak, że “zwykłe” wyszukiwanie jest kosztowne dla serwera i złośliwy klient może wykorzystać ten fakt do wykonania ataku DoS.
Jak się przed taką sytuacją bronić? Jednym z pomysłów może być uczynienie wywołania takiej metody dużo bardziej kosztownym dla klienta, niż jej obsługa dla serwera. W jaki sposób to zrobić? Na przykład wykorzystując kryptografię.
Czasem bywa tak, że człowiekowi wpadnie do głowy jakiś pomysł. Jak wpadnie, to pół biedy. Gorzej, jeśli go zrealizuje. Mnie wczoraj wpadł pomysł by w końcu zmienić swojego wysłużonego Windows XP na Windows 8. Jak pomyślałem tak zrobiłem...
Nie, nie będę narzekał na system, bo prawdę mówiąc nawet mi się podoba. Mimo, że mój laptop jest dość leciwy, to nowy system nie działa wolniej niż XP. Jedyny problem to urządzanie się na nowo.
Oryginał tego wpisu dostępny jest pod adresem Windows 8
Krótki(?) wpis w nawiązaniu do historii o uwierzytelnieniu w aplikacjach mobilnych i danych, które mogą wyciec z uwagi na wykorzystanie baz sqlite. Postanowiłem przeprowadzić prosty eksperyment – zapisać w bazie pewien rekord, a następnie zmodyfikować go na kilka sposobów:
przez UPDATE,
przez sekwencję INSERT, DELETE i VACUUM,
przez sekwencję DELETE, INSERT i VACUUM,
W każdym z przypadków spróbuję znaleźć w systemie plików pozostałości tego rekordu. Tajna wartość brzmi tak:
Czasem zdarza mi się wystąpić na jakiejś konferencji. Z reguły jest tak, że na każdą taka okazję przygotowuję inna prezentację. Nie jest to zbyt efektywne podejście, ilość czasu poświęcona na przygotowanie prezentacji jest zdecydowanie większa, niż czas, przez który wykorzystuję otrzymany “produkt”. By trochę poprawić sytuację, umieszczam treść (oczywiście nie słowo w słowo) prezentacji na blogu. Tym razem jest to prezentacja przygotowana na SecurityBSIDEs Polska (albo Warszawa, jak kto woli).
Przykłady podawane w tekście brane są z różnych aplikacji mobilnych, z którymi miałem do czynienia. Nie podaje ich nazw i nie demonstruję konkretnych podatności w konkretnej aplikacji. Raczej staram się dokonać uogólnienia i wykazać ogólne klasy problemów.
Całość dotyczy jednej z podstawowych funkcji bezpieczeństwa, czyli uwierzytelnienia użytkownika. Czy atakujący, który uzyska dostęp do urządzenia ofiary będzie w stanie ustalić jego dane uwierzytelniające i uzyskać dostęp do (jakiegoś) systemu?