Jeśli ktoś jeszcze nie wie, Gynvael publikuje videocasty. Pomijając jakość, autor jest jej gwarancją, strasznie spodobała mi się forma. O ile do podcastów mam spory dystans, nie widzę w ich przypadku dużej wartości dodanej w stosunku do tekstu, to w videocastach taką wartość widzę. Pewne rzeczy po prostu można pokazać szybciej i bardziej zrozumiale, niż próbując je opisać (w tekście).
Taka ta pogoda niezdecydowana. Raz słońce, raz deszcz (z lodem). Deszcz na zdjęciu, choć nie do końca to widać. Okolice Obidowca, konkretnie zaraz przy pomniku w miejscu katastrofy lotniczej.
Oryginał tego wpisu dostępny jest pod adresem Gorce
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ę...