Mamy problem z szeroko pojętą jakością oprogramowania. My, czyli nasza cywilizacja. Wciąż nie jesteśmy w stanie stworzyć oprogramowania, które nie będzie zawierało błędów. Nie jesteśmy też w stanie wychwycić wszystkich błędów na etapie testowania. I nie, nie chodzi mi tu (tylko) o błędy związane z bezpieczeństwem. Skutki błędów mogą być zarówno spektakularne (np. eksplozja rakiety Ariane 5), jak i tragiczne (np. ofiary śmiertelne źle działającego sprzętu medycznego). Mogą też być ciekawe, ostatnio przeczytałem, że jednym z ograniczeń odchodzących właśnie do historii wahadłowców było to, że misja nie mogła się przeciągać z grudnia na styczeń, choć tu nie wiem, czy jest to błąd, czy “świadome” ograniczenie. Błędem na pewno było zawieszanie Windows przy zbyt dużym uptime: Computer Hangs After 49.7 Days, choć z drugiej strony niewątpliwym sukcesem było osiąganie takiego uptime...
Jakiś czas temu Google udostępniło możliwość logowania się do swoich usług za pomocą uwierzytelnienia dwuskładnikowego. Jedną z możliwości jest wykorzystanie kodów jednorazowych generowanych przez aplikację Google Authenticator (źródła tego projektu można znaleźć tutaj: google-authenticator). Aplikacja ta jest niczym innym, jak programowym tokenem generującym hasła jednorazowe w oparciu o czas lub licznik (więcej szczegółów: HOTP: An HMAC-Based One-Time Password Algorithm).
Google jakiś czas temu wprowadziło +1 button. W ramach eksperymentu dodałem go na blogu, choć nie wiem, czy długo tam zabawi. Ale ja nie o tym... Zdobycie +1 staje się konfiturą, wartością samą w sobie, sposobem na poprawienie swojego rankingu w wynikach wyszukiwania.
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?
