https://archive.mroczna-zaloga.org/ Paweł Goleń, blog - Zrzędzenie starego zgreda pl Serendipity - http://www.s9y.org/ Sat, 15 Mar 2025 22:15:00 GMT https://archive.mroczna-zaloga.org/templates/bulletproof/img/s9y_banner_small.png https://archive.mroczna-zaloga.org/ 100 21 https://archive.mroczna-zaloga.org/archives/657-ilu-programistow-mnie-czyta.html#c1320 https://archive.mroczna-zaloga.org/archives/657-ilu-programistow-mnie-czyta.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=657 nospam@example.com (kravietz) Z najlepszymi praktykami chodziło mi tylko o to, że skazane na niepowodzenie jest zaczęcie wykładu od nich bez uzasadnienia dlaczego się o nich mówi. Ja rozmawiając ze swoimi developerami mówię np. tak: ja wiem, że to httpOnly to z praktycznego punktu widzenia duperela, ale zewnętrzni pentesterzy będą wam to wykazywać w każdym kolejnym raporcie, a wy będziecie musieli to w kółko wyjaśniać klientowi. Więc jak macie chwilę czasu i EE6 to dodajcie to httpOnly do sesji, żeby zaoszczędzić czas swój i klienta :) Sat, 25 Jul 2009 11:44:58 +0200 https://archive.mroczna-zaloga.org/archives/657-guid.html#c1320 https://archive.mroczna-zaloga.org/archives/657-ilu-programistow-mnie-czyta.html#c1283 https://archive.mroczna-zaloga.org/archives/657-ilu-programistow-mnie-czyta.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=657 nospam@example.com (wampir) I jeszcze jedno. Nie do końca się zgodzę, że mówienie o najlepszych praktykach jest skazane w 100% na niepowodzenie. W przypadku programistów jasny komunikat: dane na wyjście wypisujemy korzystając z superFunkcja(dane) a nie echo dane jest wystarczający i może być skuteczny. Natomiast cała teoria o kosztach, oszczędnościach, (...) czy historie typu "a Andrzej M. tego nie robił i złapał kapcia" może wprowadzić "drobne" zniecierpliwienie słuchaczy. Oczywiście gdzieś "kapkę wyżej" ktoś musi zrozumieć, że takie dobre praktyki mają sens i z ich wprowadzenia będzie zysk. W przypadku programistów przykładowym zyskiem może być zmniejszenie czasu poświęcanego na usuwanie błędów bezpieczeństwa. Ale by móc go w jakiś wymierny sposób ocenić, trzeba mieć informacje na temat zgłaszanych błędów bezpieczeństwa i czasu potrzebnego na ich usunięcie. Co więcej błędy bezpieczeństwa powinny być odróżnialne od innych błędów i, co najważniejsze, powinny być zgłaszane. I z tym wyszukiwaniem i zgłaszaniem błędów bezpieczeństwa może być pewien problem. Thu, 23 Jul 2009 16:01:12 +0200 https://archive.mroczna-zaloga.org/archives/657-guid.html#c1283 https://archive.mroczna-zaloga.org/archives/657-ilu-programistow-mnie-czyta.html#c1280 https://archive.mroczna-zaloga.org/archives/657-ilu-programistow-mnie-czyta.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=657 nospam@example.com (wampir) Problem w tym, że często brakuje przypadku, o którym można opowiedzieć. Informacje zza wielkiej wody niekoniecznie są dobrym przykładem (trochę inne regulacje prawne, swoją drogą często mnie irytowali handlowcy powołujący się przykładowo na SOX tam, gdzie nie miał on zastosowania), u nas raczej panuje tendencja do ukrywania tego typu informacji i ciężko jest zrobić case study. Pokazanie (wymiernych) zysków z bezpieczeństwa również może być trudne, bo informacja o stratach obarczona jest dużym stopniem niepewności. Nie bardzo jest z czym się porównać i weryfikować szacunki. Thu, 23 Jul 2009 15:42:12 +0200 https://archive.mroczna-zaloga.org/archives/657-guid.html#c1280 https://archive.mroczna-zaloga.org/archives/657-ilu-programistow-mnie-czyta.html#c1277 https://archive.mroczna-zaloga.org/archives/657-ilu-programistow-mnie-czyta.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=657 nospam@example.com (kravietz) Bezpieczniacy często nie wiedzą JAK trzeba mówić do programistów oraz menedżerów oraz w jakiej kolejności. Mówienie o najlepszych praktykach jest skazane na porażkę w 100%. Opowiadanie o różnych włamaniach do różnych odległych portali - w 80%. Case study z bankiem będących bezpośrednim konkurentem klienta nieco przyciąga uwagę (np. wczoraj FSA ukarała HSBC $4m grzywną za niechlujstwo w ochronie danych) i z tego w ogóle należy zaczynać. Bezpieczeństwo w rozumieniu menedżerów jest kosztem. Trzeba im pokazać, że nie jest kosztem tylko inwestycją, którą ponosi się po to, by nie ponieść straty. Tzn. wydajecie $300k po to, żeby nie wydać $3m na karę plus utrata reputacji. Thu, 23 Jul 2009 14:27:05 +0200 https://archive.mroczna-zaloga.org/archives/657-guid.html#c1277 https://archive.mroczna-zaloga.org/archives/657-ilu-programistow-mnie-czyta.html#c1276 https://archive.mroczna-zaloga.org/archives/657-ilu-programistow-mnie-czyta.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=657 nospam@example.com (kravietz) Nikt się nie bedzie samodoskonalił jak 100% czasu pracy ma zajęte przez konkretne zadania i terminy. A jak będzie to raczej w kwestii np. optymalizacji kodu czy nowych ficzerów, a nie bezpieczeństwa, którego rola jest dość specyficzna (o czym poniżej). Thu, 23 Jul 2009 14:16:59 +0200 https://archive.mroczna-zaloga.org/archives/657-guid.html#c1276 https://archive.mroczna-zaloga.org/archives/657-ilu-programistow-mnie-czyta.html#c1266 https://archive.mroczna-zaloga.org/archives/657-ilu-programistow-mnie-czyta.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=657 nospam@example.com (wampir) Ja pracowałem w banku i o traktowaniu tego tematu "u dużych" też można napisać wiele ciekawych opowieści. Właśnie wątek nierzetelności jest tutaj istotny. Wiele razy zwracałem uwagę, że w umowach z dostawcami często nie są zawierane żadne zapisy, które pozwolą egzekwować "bezpieczeństwo" od końcowego produktu. Problemem jest choćby zdefiniowane mierzalnych parametrów, których (nie)przejście wpływa na odbiór dostarczonego produktu. Osoba od security nie musi być ekspertem w danej technologii. Problemy, z którymi się spotykam najczęściej nie wynikają ze specyfiki wykorzystanej technologii, tylko z niewiedzy. Brak walidacji, brak encoingu danych wejściowych, dynamiczne składanie zapytań SQL, "kontrola dostępu" poprzez ukrywanie/wyłączanie opcji w GUI aplikacji - to wszystko są kwestie praktycznie niezależne od wykorzystanej technologii. Co do samego problemu z brakiem komunikacji, to się zgodzę. Często wygląda to tak, że przyjdzie bezpiecznik, coś tam pogada, programiści/produkcja dla spokoju posłuchają myśląc o zupełnie czymś innym, a potem i tak zrobią to po swojemu... Tue, 21 Jul 2009 11:56:21 +0200 https://archive.mroczna-zaloga.org/archives/657-guid.html#c1266 https://archive.mroczna-zaloga.org/archives/657-ilu-programistow-mnie-czyta.html#c1265 https://archive.mroczna-zaloga.org/archives/657-ilu-programistow-mnie-czyta.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=657 nospam@example.com (wampir) Masz oczywiście rację, że firma nie zamówi szkolenia, jeśli jakieś wsparcia nie będzie na wystarczająco wysokim poziomie. Ale przecież programiści to nie są niewolnicy firmy. Mówi się (z rzeczywistością różnie bywa), że określony czas pracy pracownik powinien poświęcić na tak zwane samodoskonalenie. Czyżby bezpieczeństwo było tak dalece nieatrakcyjne, że bardzo niewielki odsetek ludzi "samodoskonali" się choćby poznając ogólne zarysy problemu bezpieczeństwa? Tue, 21 Jul 2009 11:50:14 +0200 https://archive.mroczna-zaloga.org/archives/657-guid.html#c1265 https://archive.mroczna-zaloga.org/archives/657-ilu-programistow-mnie-czyta.html#c1262 https://archive.mroczna-zaloga.org/archives/657-ilu-programistow-mnie-czyta.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=657 nospam@example.com (Piotr) Zwróciłbym także uwagę na smutna rzeczywistość klientów. Można oczywiście mówić jacy to developerzy są nie dobrzy bo nie wiedzą - to fakt. Brak wiedzy w zakresie "security", a także "quality" jest i to jest fakt, nie chce z tym polemizować tylko pokazać inny problem. Z drugiej strony są jednak klienci. Nawet ci duzi i świadomi (z bankami nie pracowałem) nie zamawiają ani "quality" ani "security", a przecież ktoś za to musi zapłacić. Firmy starają się jakoś przeżyć i obcinają różne koszty.... i jest jak jest. Z drugiej strony jak się kupuje samochód bez poduszek powietrznych to do kogo można mieć pretensje? Z "trzeciej" strony mamy tez doczynienia z nierzetelnością. Klient przez domniemanie zakłada, że system jest zrobiony zgodnie ze sztuką, płaci ile płaci, a dostaje niską jakość. Inny problem to totalny brak komunikacji między ludźmi od security i od produkcji. Proponuje zrobić eksperyment i porozmawiać: -o javie z ekspertami od security -o Building Security In Maturity Model, Software Assurance Maturity Model Od paru lat w dziedzinie produkcji oprogramowania mamy tendencje do lekkich metodyk w których nikt nie mówi o bezpieczeństwie. Mówi się o braku błędów o spełnianiu wymagań klienta itd. O security nie ma nic. Zostawianie tego na developerów nie jest dobrym pomysłem. Tue, 21 Jul 2009 09:57:52 +0200 https://archive.mroczna-zaloga.org/archives/657-guid.html#c1262 https://archive.mroczna-zaloga.org/archives/657-ilu-programistow-mnie-czyta.html#c1260 https://archive.mroczna-zaloga.org/archives/657-ilu-programistow-mnie-czyta.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=657 nospam@example.com (kravietz) Z moich obserwacji wynika, że programistom brakuje zwykle podstawowej wiedzy o tym, że ludzie mogą robić złe rzeczy ich aplikacjom. Dominuje podejście funkcjonalne ("wystarczy że mniej więcej działa"). Kapitalne rezultaty przynosi praca u podstaw - nawet godzinne szkolenie z paroma straszliwymi przykładami uczy czujności i pokazuje kierunki, w których goście mogą się już sami dokształcać (OWASP itd). TYLKO ŻE... aby przeszkolić tych gości musisz mieć zgodę ich szefa. Aby nie traktowali Cię jak pana od BHP ich szef musi też traktować ten temat poważnie. Stąd takie działania edukacyjny muszą zacząć się od szefów. Inna sprawa, że im wystarcza 15 minut z częstym cytowaniem Datalossdb.org :) Tue, 21 Jul 2009 09:43:13 +0200 https://archive.mroczna-zaloga.org/archives/657-guid.html#c1260 https://archive.mroczna-zaloga.org/archives/657-ilu-programistow-mnie-czyta.html#c1252 https://archive.mroczna-zaloga.org/archives/657-ilu-programistow-mnie-czyta.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=657 nospam@example.com (wampir) Wsparcie "senior management" jako wymaganie jest wymieniany nie tylko w ISO 27001. Ale wydaje mi się, że tworzenie kodu zgodnie z "najlepszymi praktykami" jest wymaganiem, które nie powinno być aż tak wysoko "umocowywane". Owszem, decyzja o modyfikacji procesów (wprowadzenie jakieś formy SDLC) jak najbardziej, ale w odniesieniu do samej świadomości programistów? To trochę tak, jakby programista mógł tworzyć wolny, zabugowany i ogólnie paskudny kod (z pominięciem kwestii bezpieczeństwa), bo przecież na ścianie nie wisi podpisany przez prezesa slogan "dziś piszemy wydajnie" albo "w ten kod patrzą też inni, pisz tak, by dało się zrozumieć". Przecież takimi zagadnieniami jak znajomość algorytmów czy struktur danych przez programistów nie zajmuje się chyba zarząd. A wiedza, że (przykładowo) przed wpisaniem danych na wyjście trzeba zrobić encoding jest w zasadzie tego samego gatunku, jak wiedza potrzebna do podjęcia decyzji, czy w danym przypadku użyć hashtable, listy czy jakiegoś innego rozwiązania... Oczywiście wiem, że informatycy (programiści nie są tu wyjątkiem) są z natury leniwi i w większości zrobią tylko tyle ile się od nich wymaga, bez przesady, są zatrudniani i dostają w sumie nie najmniejsze pieniądze nie za to, by ktoś ich uczył jak poprawnie kodować. To może zmodyfikuje nieco pytanie - czy czytają mnie starsi programiści/team leader/kierownicy zespołu programistów? Jak kwestie związane z bezpieczeństwem wyglądają w ich zespole? Jaki poziom prezentują nowi pracownicy? Czy w jakikolwiek sposób poziom "nowych" w trakcie pracy jest podnoszony (szkolenia, pogadanki, rytualny lincz na "winnych" wprowadzenia błędów do kodu)? Mon, 20 Jul 2009 14:30:00 +0200 https://archive.mroczna-zaloga.org/archives/657-guid.html#c1252 https://archive.mroczna-zaloga.org/archives/657-ilu-programistow-mnie-czyta.html#c1250 https://archive.mroczna-zaloga.org/archives/657-ilu-programistow-mnie-czyta.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=657 nospam@example.com (kravietz) Z moich obserwacji wynika, że poziom jest bardzo nierówny i w bardzo dużym stopniu uzależniony od świadomości osoby zarządzającej danym zespołem. Czasem nawet w jednej organizacji niektóre zespoły były dobrze wyedukowane, a inne wcale. Potwierdza to podstawowe założenie ISO 27001, że pierwszą rzecząc, którą należy wykonać zanim zacznie się wdrażać jakiekolwiek techniki tam wymienione jest "obtain senior management support" :) Mon, 20 Jul 2009 13:53:55 +0200 https://archive.mroczna-zaloga.org/archives/657-guid.html#c1250 https://archive.mroczna-zaloga.org/archives/657-ilu-programistow-mnie-czyta.html#c1249 https://archive.mroczna-zaloga.org/archives/657-ilu-programistow-mnie-czyta.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=657 nospam@example.com (k.) $programisciCzytajacyBloga++; Nie znam osobiście chyba żadnego programisty, który w większym stopniu interesuje się bezpieczeństwem. Niewielu zna chociażby podstawowe zagrożenia. W poprzednich (niewielkich) firmach, w których pracowałem wiedza ta była bliska zeru, w aktualnej świadomość jest o wiele większa (trochę wyższy poziom). Jednak ogólnie jest słabo ;-/ Sun, 19 Jul 2009 23:39:46 +0200 https://archive.mroczna-zaloga.org/archives/657-guid.html#c1249 https://archive.mroczna-zaloga.org/archives/657-ilu-programistow-mnie-czyta.html#c1247 https://archive.mroczna-zaloga.org/archives/657-ilu-programistow-mnie-czyta.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=657 nospam@example.com (Kaarol) Może prostu część z nich zakłada, że zrobili to za nich twórcy frameworku? Co do samych studiów, to wydaje mi się, że temat samego bezpieczeństwa aplikacji na pewnych przedmiotach jest różnie traktowany. Czasami wykładowcy sami stwierdzają, że brakuje na niego czasu :( Sun, 19 Jul 2009 04:09:16 +0200 https://archive.mroczna-zaloga.org/archives/657-guid.html#c1247 https://archive.mroczna-zaloga.org/archives/657-ilu-programistow-mnie-czyta.html#c1246 https://archive.mroczna-zaloga.org/archives/657-ilu-programistow-mnie-czyta.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=657 nospam@example.com (wampir) No właśnie, to mnie trochę dziwi. Kto jak kto, ale programiści powinni jakoś łatwiej wyobrazić sobie skutki wykonania dowolnego wybranego przez atakującego kodu (XSS, SQL injection), a nader często XSS czy CSRF jest jakąś straszną abstrakcją. SQL Injection może nieco mniej, bo demonstracja wyciągania danych z bazy jest bardziej "bezpośrednia". Sat, 18 Jul 2009 23:07:49 +0200 https://archive.mroczna-zaloga.org/archives/657-guid.html#c1246 https://archive.mroczna-zaloga.org/archives/657-ilu-programistow-mnie-czyta.html#c1245 https://archive.mroczna-zaloga.org/archives/657-ilu-programistow-mnie-czyta.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=657 nospam@example.com (Marcin Gryszkalis) Patrząc na studntów informatyki, z którymi miałem do czynienia od ładnych paru lat wychodzi mi, że (bardzo zgrubnie szacując): - 100% potrafi napisać prosty program w php - 10-20% potrafi użyć gotowego frameworka albo rozszerzalnego CMSa - co znacznie poprawia bezpieczeństwo :) - 5% wie co to jest SQL injection - 1% rozumie konsekwencje bardziej zaawansowanych ataków typu XSS, cokolwiek-forgery, itd. Oczywiście po studiach pisać aplikacje idzie więcej niż te 1% ;) Sat, 18 Jul 2009 22:38:08 +0200 https://archive.mroczna-zaloga.org/archives/657-guid.html#c1245