Choć zwykle unikam na swoim blogu promowania cudzych akcji marketingowych, to w tym wypadku uczynię wyjątek. Przejrzałem te opracowania i muszę przyznać, że choć poruszają podstawowe zagadnienia związane z wymienionymi tematami, to jednak merytorycznie w tym zakresie, który obejmują, są OK. Jeśli dodatkowo popatrzeć na CWE, to podatności/słabości:
mają tak dużą szansę wystąpienia i wykorzystania, że należy się cieszyć z każdej inicjatywy, która może zmienić ten stan rzeczy. Przy okazji można też sprawdzić, jak te podatności zostały “wycenione” w OWASP Top10 2010 (chodzi mi o Weakness Prevalence oraz Weakness Detectability):
Sponsorem tego wpisu jest BP, który zupełnie przypadkowo spowodował, że zacząłem sobie przypominać różne dziwne języki, w których popełniłem choć trochę kodu. Czasami bardzo trochę. Przypominam, że nie jestem (i nie uważam się) za programistę, ale w razie czego coś, co jakoś działa jestem w stanie napisać.
Wyniki kolejnego eksperymentu dotyczącego “przyspieszania” blind sql injection przez zmianę układu znaków, na którym wyszukiwane jest rozwiązanie, czyli kontynuacja wpisów Blind SQL Injection z wykorzystaniem regexpów oraz Szybszy(?) blind sql injection. Tym razem postanowiłem sprawdzić jak układ (kolejność) znaków wpływa na szybkość znajdowania rozwiązania przy “klasycznej” strategii podziału.
Tak, jest to nawiązanie do wcześniejszego wpisu: Blind SQL Injection z wykorzystaniem regexpów. Postanowiłem sprawdzić, czy rzeczywiście uda się zmniejszyć ilość pytań, które trzeba zadać, by odgadnąć słowo. Rezultat: 66976481 63650628. Lepiej?
Przeglądając wczoraj różne informacje trafiłem na dokument Blind Sql Injection with Regular Expressions Attack. Temat jest ciekawy, jedno z głównych pytań, które mnie się nasunęło brzmi – ale po co. Po chwili przyszła jednak refleksja – może i ma to sens.
Zwykle o wycieku danych użytkowników dowiadujemy się wtedy, gdy ktoś się ich posiadaniem pochwali. Nie musi to oznaczać, że ofiara (źródło wycieku) nie wie, że taka sytuacja miała miejsce. Po prostu wolą nie przyznawać się do takiej wpadki, a jeśli już muszą, to podają jak najmniej szczegółów, lub używają popularnego ostatnio słowa klucza: APT. Takie postępowanie można nawet zrozumieć patrząc na często irracjonalne zachowania ludzi, nie koniecznie związane IT (np. lęk przed lataniem po głośnej katastrofie lotniczej, nawet jeśli rozbił się zupełnie inny typ samolotu z jakichś szczególnych powodów). Po prostu percepcja ryzyka u ludzi mocno rozmija się z tym, jakie to ryzyko rzeczywiście jest. Ale ja chciałem o czym innym...
Stworzenie zabezpieczenia w 100%25 skutecznego jest niemożliwe. System nie musi (i nie może) być absolutnie bezpieczny, musi natomiast realizować swoje cele biznesowe z zachowaniem akceptowalnego poziomu ryzyka. Innymi słowy – system musi być wystarczająco bezpieczny. Ale jak stwierdzić, że coś jest wystarczająco bezpieczne?
Moim pierwszym skojarzeniem jest: pan Roman poszedł do muzeum, dostał wp^Włomot i teraz musi nosić maskę... Jeśli to miało zachęcić mnie do pójścia do muzeum – gratuluję! Nie udało się...
Przykład: Za kratki przez trzęsienie ziemi?. Cała sprawa jest dziwna. O ile mi wiadomo nie istnieje obecnie skuteczny sposób prognozowania trzęsień ziemi (patrz, właściwie słuchaj , też: Kluczowe kilkanaście sekund – o systemach ostrzegawczych przed trzęsieniem ziemi). Wątek zbyt częstego ostrzegania przed możliwym zdarzeniem (w tym wypadku trzęsieniem), które w rzeczywistości nie ma miejsca, również w tej rozmowie jest poruszany. Zawsze śmieszy mnie wszechwiedza ludzi po zdarzeniu , którzy oczywiście widzą wszystkie “zaniedbania i błędy”, ale jednocześnie przed zdarzeniem sami wcale nie byli tacy mądrzy.
Ale tak naprawdę zdziwiło/zirytowało mnie inne stwierdzenie zawarte w tym artykule:
Podobnie marne standardy stosowali zresztą Japończycy. Tama, którą zaprojektowali przed elektrownią atomową w Fukushimie, okazała się za niska i kilkunastometrowa fala tsunami przelała się przez nią z łatwością.
...no tak, bo trzęsienia o sile przekraczającej 9 stopni zdarzają się nagminnie. Fale tsunami o takiej wysokości oczywiście również. Ze zdarzenia w Fukushimie trzeba oczywiście wyciągnąć wnioski, ale z tymi “marnymi standardami” to autora tekstu trochę poniosło...
Nie ma to jak odpalić rano laptopa i dowiedzieć się, że tchórzliwie odmawia połączenia z siecią. A konkretnie karta sieciowa postanowiła nie widzieć linka... Od dłuższego czasu miałem z nią/nim (tą kartą/tym laptopem) problem tego rodzaju, że uporczywie negocjował połączenie 10Mbps zamiast 1Gbps, natomiast po wyjęciu i ponownym włożeniu kabla “dogadywał się” ze switchem i pracował z pełną dostępną szybkością. Okazuje się, że dziś przestał. I to tak skutecznie, że w konfiguracji sterowników (tak, mam najnowsze) musiałem wyłączyć negocjację i na sztywno ustawić 100Mbps. Super...
Oczywiście to nie były jedyne problemy, które nagle się postanowiły zamanifestować. Nie, nie wszystkie były związane ze sprzętem. Ale po dłuższej chwili intensywnego wyklinania rzeczywistości udało mi się dojść do porozumienia ze wszystkimi niezbędnymi do normalnej pracy sprzętowymi i programowymi elementami tej maszyny piekielnej popularnie określanej mianem laptopa...
Z drugiej strony i tak lepsze takie problemy, niż mój dawny przypadek z TrueCryptem, który najpierw tchórzliwie odmówił wystartowania systemu, a następnie postanowił “zawinąć się” na magicznej liczbie 137 i ponownie zaszyfrować wcześniej odszyfrowaną część dysku...
