Paweł Goleń, blog

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.

Tradycyjnie razem z uaktualnieniami pojawiła się kolejna wersja Malicious Software Removal Tool (można też pobrać oddzielnie: Malicious Software Removal Tool). Postanowiłem sprawdzić skuteczność tego narzędzia na swojej kolekcji próbek.

Co prawda "podzieliłem się" tym wpisem w Google Reader (to jest jedna z usług Google, która mnie nie irytuje), ale tu też o tym napiszę: The Trojan solved it! Catching a fraudster with another criminal, ‘myspacce.exe’. W skrócie - pracownik robił przekręty, został przyłapany ale między "przyłapaniem" a rozpoczęciem "sekcji zwłok" pracownik dość skutecznie zatarł większość śladów. Okazało się jednak, że na komputerze zainstalowany był malware, który między innymi był keyloggerem, i który przypadkiem zebrał wystarczająco dużo informacji, by pracownikowi przekręty udowodnić. Sytuacja dość paradoksalna, zwłaszcza mając na uwadze tak zwaną obronę Trojan-did it-defense.