Jeśli ktoś zaoferuje wam wykonanie projektu (najczęściej jakiegoś serwisu) w oparciu o “autorski, profesjonalny CMS”, to uciekajcie tak szybko i tak daleko, jak tylko się da. Może i w jednym przypadku na dziesięć popełnicie błąd. W pozostałych dziewięciu właśnie uniknęliście poważnych kłopotów.
Co do zasady wykorzystanie pewnej dodatkowej “warstwy abstrakcji” ogranicza ryzyko związane z błędami typu SQL Injection. Ogranicza, ale nie eliminuje, bo:
I tak właśnie jest w przypadku Ruby on Rails: SQL Injection Vulnerability in Ruby on Rails (CVE-2012-5664) (patrz też: Rails 3.2.10, 3.1.9, and 3.0.18 have been released!).
A teraz pytania, które zadawałem programistom na szkoleniu, i na które odpowiedź brzmiała zwykle “nie”:
Pojęcie “biblioteki” jest tutaj pewnym placeholderem. Patrz też: Remember the Giblets! i The Trouble with Giblets.
Błąd w takim “dodatku” nie jest błędem w Twoim kodzie, ale jest błędem w Twojej aplikacji. Jeśli używasz cudzego kodu, musisz o niego dbać (On handling your pets and a CSRF protection that wasn't). Absolutne minimum to:
A co, kiedy ktoś mówi “nie mogę zagwarantować, że po aktualizacji nasz system będzie nadal działał”? Cóż, z tym też można sobie poradzić: Test-driven development.
Oryginał tego wpisu dostępny jest pod adresem SQLi w RoR
Autor: Paweł Goleń
Na początek odsyłacz do “materiału poglądowego”: Hacking an Android Banking Application. Chodzi mi szczególnie o sekcję “Memory dump analysis”, choć nie tylko. Na potrzeby tego krótkiego wpisu jednak ograniczmy się do tego scenariusza.
A teraz fragment zdania, które w stosunkowo często pojawia się w książkach Schneiera:
If (...), you already have much bigger problems.
A teraz temat do przemyśleń – jeśli atakujący dysponuje takim dostępem do urządzenia ofiary, że jest w stanie pozyskać i analizować zrzut pamięci, to czy przypadkiem nie znaczy to, że mamy już większy problem, niż to, co atakujący w tej pamięci znajdzie?
Oryginał tego wpisu dostępny jest pod adresem Czy aby na pewno TO jest problem?
Autor: Paweł Goleń
Załóżmy, że w wyniku błędu w aplikacji mamy możliwość odczytu dowolnego pliku z serwera, pod warunkiem, że znamy jego nazwę (i oczywiście ścieżkę). Załóżmy, że serwer pracuje pod kontrolą systemu Windows, a aplikacja jest napisana w PHP. Załóżmy dodatkowo, że ciekawe dane znajdują się w sesji użytkownika i bardzo chcemy się do nich dostać.
Czym te “bardzo ciekawe dane” mogą być? Zależy. Jednym z ciekawszych przypadków, które widziałem w ciągu ostatnich 12 miesięcy, była sytuacja, w której w sesji użytkownika był zapisywany jego login i hasło. Działo się tak, ponieważ aplikacja webowa pełniła właściwie tylko rolę GUI do WS, który to WS z kolei wymagał podania danych uwierzytelniających przy wywołaniu każdej metody. Możliwość masowego odczytywania danych zapisanych w sesji niewątpliwie w tym przypadku byłaby bardzo “owocna” dla atakującego.
To jak, damy radę się dostać do tych konfitur?
Chodzi oczywiście o to jak przechowywać hasła (i potencjalnie inne dane uwierzytelniające) w systemie tak, by były bezpieczne. Odpowiedź na to pytanie powtarzana jest jak mantra:
Hasła powinny być hashowane z użyciem kosztownego obliczeniowo algorytmu (np. scrypt, bcrypt, PBKDF2), należy do tego użyć unikalny dla każdego hasła salt i opcjonalny pepper. Szyfrowanie jest złe, bo w systemie musi być przechowywany klucz i atakujący, który uzyska dostęp do klucza będzie w stanie rozszyfrować wszystkie hasła przechowywane w bazie.
I wszystko się zgadza. Prawie.
Tym razem z okazji TechCamp#6.
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
Autor: Paweł Goleń
Dziś wpis na nietypowy temat – aplikacje na Androida. A konkretnie odrobina o ich bezpieczeństwie.
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.