Jakieś dwa lata temu dostałem na imieniny książkę Tożsamość , której autorem jest Allan Folsom. Była nawet całkiem niezła, dlatego skusiłem się na Pojutrze. Tu już było gorzej, muszę zgodzić się z opinią, że w jego książkach jest coś z Ludluma, problem w tym, że to nie koniecznie jest komplement. Na Traktat Machiavellego skusiłem się, bo jest to kontynuacja Tożsamości (łączy je bohater, a nie wątki), jestem jednak rozczarowany. W zasadzie mógłbym to określić jako pomieszanie Spisku Akwitanii (Ludlum) z Przymierzem Ognia (Morrell). Są autorzy, którzy potrafią stworzyć wciągającą “alternatywną rzeczywistość” czy “możliwe” teorie spiskowe. Takich czytam z przyjemnością. Są też tacy, u których granice absurdu/nieprawdopodobieństwa (oczywiście w mojej prywatnej skali) zostają przekroczone... Niestety, jak na razie Folsom, w stosunku 2:1, plasuje się w tej drugiej kategorii.
Szczerze mówiąc rozczarowałem się tym groźnym niewykrywalnym wirusem , który kradnie hasła. Rezultaty z CWSandbox, myślałem, że to coś bardziej zmyślnego. Ogólnie – nihil novi sub sole.
...korzystając z Thunderbird i Enigmail używając opcji Send to z Explorera. Sprawa jest prosta – wystarczy wcześniej wysłać załącznik o tej samej nazwie. Thunderbird nie usunie pliku tymczasowego (w katalogu %25tmp%25\moz_mapi), a przy wysyłaniu kolejnego pliku o tej samej nazwie – wykorzysta “stary” plik.
Normalnie Thunderbird usuwa plik załącznika po wysłaniu, ale jeśli jest szyfrowanie, to załącznik jest w zaszyfrowanej postaci zapisywany w pliku o nazwie encfile , który to plik jest usuwany, plik w postaci jawnej pozostaje nietknięty.
Szczególnym przypadkiem tego błędu jest wysłanie w postaci jawnej pliku, który wcześniej został wysłany w postaci zaszyfrowanej, jeśli użytkownik chce wysłać (jawnie) plik o nazwie takiej samej, jak wcześniej wysłany plik zaszyfrowany.
Z komentarzy: Bezpieczeństwo tworzonych aplikacji zawiera się (wg. Ciebie) pod pojęciem 'jakości kodu', czy może stanowi dodatkowy 'ficzer', za który klient powinien płacić?
W trakcie prezentacji na spotkaniu OWASP pojawiło się pytanie o najbardziej efektywne odczytywanie danych z bazy za pomocą techniki blind sql injection. W szczególności pojawiła się sugestia, że szybkie (w szczególności szybsze od bisekcji) może być wykorzystanie zapytania z konstrukcją LIKE. Tak nie jest.
Dziś miało miejsce kolejne spotkanie OWASP. W trakcie rozwinęła się dyskusja jak zachęcić większą ilość ludzi do przychodzenia na takie spotkania. W szczególności chodzi o:
programistów,
przedstawicieli klientów “końcowych”,
Nie osiągnie się poprawy bezpieczeństwa aplikacji, jeśli na takie spotkania będą przychodzili ludzie już zainteresowani tematem, a tak jest niestety obecnie. Jeden z obecnych na spotkaniu programistów powiedział wprost, że od niego nikt nie wymaga tworzenia bezpiecznego kodu, bo on w zasadzie ma zrealizować wymagania klienta. Dlatego też dobrze by było, gdyby na spotkania przychodzili przedstawiciele klienta, choćby po to, by wiedzieli co umieścić w wymaganiach. Jeśli wymagania odnośnie bezpieczeństwa pojawią się w podpisywanych umowach, w sposób naturalny również i programiści będą zainteresowani (odgórnie) tematem. Ludzie ci jednak nie przyjdą na spotkania OWASP, jeśli nie znajdą tematów dla nich interesujących. Co chcielibyście więc usłyszeć?
Napisałem sobie skrypt, który służył do uruchamiania narzędzia Memoryze. Problem w tym, że skrypt umieściłem w katalogu programu, a później zainstalowałem nową wersję (Memoryze now supports Vista SP1 and F-response). Okazało się, że w trakcie tego upgrade mój skrypt zniknął (instalator najpierw usunął obecnie zainstalowaną wersję, w tym katalog z całą zawartością). Nie bardzo chciało mi się pisać go jeszcze raz, więc przeszukałem cały dysk (ProDiscover Basic) na określone słowa kluczowe. Okazało się, że w kilku klastrach zostały fragmenty skryptu (prawdopodobnie pliki tymczasowe edytora), po ich odzyskaniu skrypt udało się odtworzyć.
CWE-89: Failure to Preserve SQL Query Structure (aka 'SQL Injection') pochodzi wprost z 2009 CWE/SANS Top 25 Most Dangerous Programming Errors. Osobiście bardzo się cieszę z opublikowania tego typu dokumentu, zalecenia w nim zawarte można wprost wykorzystywać jako tak zwane najlepsze praktyki , co powinno znacznie ukrócić niejednokrotnie uciążliwe dyskusje z devloperami odnośnie tego co jest, a co nie jest najlepszą praktyką. Jak Tomek kiedyś stwierdził, temat sql injection jest tematem dyżurnym na moim blogu. Tym razem trochę na temat tego, jak zmniejszyć szansę pojawienia się podatności w tworzonej aplikacji.