Archiwa tagu: security

Kernel: Don’t panic

W ubiegłym miesiącu, dla zabicia czasu w sobotni, deszczowy dzień, wybrałam się na studencką konferencję organizowaną przez Koło Naukowe Kernel, o uroczej nazwie „Kernel: DON’T PANIC!„. Impreza odbywała się 13 maja ’17, w dużej auli Wydziału Fizyki i Informatyki Stosowanej AGH, którą oczywiście darzę dużym sentymentem:D

Organizacja na piątkę. Szatnia, ciasteczka, gorąca kawa, a nawet upominki dla uczestników: smyczki i elegancka torba z nadrukiem loga koła, a w środku pisadło i butelka wody (może na kaca, w końcu Juwenalia:D), słowem profeska i szacunek dla organizatorów za ogarnięcie tematu (a dla sponsorów za sypnięcie groszem:))

Przechodząc jednak do merytoryki muszę powiedzieć, że wykłady trzymały poziom. Na scenie udało się zgromadzić naprawdę ciekawych prelegentów.

Na początek Piotr Konieczny którego przedstawiać myślę nie trzeba (niebezpiecznik.pl) opowiedział o kulisach ataków socjotechnicznych, jakie w ramach audytów bezpieczeństwa przeprowadzają w firmach. Okazuje się, że czasem nawet świadomość i wiedza pracowników nie wystarcza, by uchronić organizację przed przemyślanym atakiem socjotechnicznym. Bardzo często działamy automatycznie, nawykowo, a na domiar złego w grupie myślenie i odpowiedzialność ulega rozproszeniu, skutkiem czego niestety, najsłabszym ogniwem zabezpieczeń bywa człowiek. Naprawdę warto było wstać przed ósmą (w sobotę!) i pomknąć przez deszczowy Kraków, by dotrzeć na ten wykład!

Wykład pt. „Metodologia tworzenia oprogramowania przez IBM spełniającego wymogi cyber-bezpieczeństwa” niestety ciut mnie rozczarował, więc przejdę od razu do kolejnego punktu, czyli wystąpienia naczelnika krakowskiego wydziału policji do walki z Cyberprzestępczością. Czytaj dalej

4 złote zasady bezpiecznej aplikacji

Nieważne, czy pisana aplikacja jest aplikacją mobilną, webową, desktopową czy mamy do czynienia z rozbudowanym systemem. Poniższe cztery zasady tworzenia bezpiecznych aplikacji są zawsze aktualne:

klodka

  1. Zasada dodatkowych zabezpieczeń. Popularnie stosowana np. w serwisach aukcyjnych – przed zmianą kluczowych ustawień konta (np. hasła), użytkownik musi się przelogować.
  2. Zasada minimalnych uprawnień. Oczywistość – po co redaktorowi tekstów uprawnienia do administracji użytkownikami, po co praktykantowi hasła do głównych serwerów. Oczywiście w przypadku nadawania uprawnień ludziom, nakłada to na administratora dodatkową pracę oraz konieczność stosowania jasnych uprawnień. Natomiast w aplikacjach/systemach często sprowadza się to do uniksowego nadania uprawnień typu rwx do folderów oraz do uniemożliwienia użytkownikowi dokonywania niebezpiecznych akcji.
  3. Zasada znanych rozwiązań. Komplikowanie systemu zabezpieczeń powoduje dyskomfort podczas korzystania z aplikacji. Powinna być ona jak najbardziej intuicyjna. Po stronie interfejsu stosujmy więc rozwiązania znane z innych serwisów (login+hasło, capcha, potwierdzanie rejestracji przez mail itp.). Pod maską można zawsze pokusić się o bardziej finezyjne zabezpieczenia.
  4. Zasada czytelnego, prostego kodu. O tym pisze się całe książki (np. Czysty kod, klasyka którą zawsze i wszędzie polecam). W prostym kodzie bez „magicznych rozwiązań” rodem z serii łamigłówek i szyfrów (pozdrawiam programistów pewnej firmy…) łatwiej się odnaleźć, programuje się szybciej i trudniej o popełnienie błędu. Prościej jest wywołać metodę dostarczoną przez język (framework/platformę/zewnętrzną bibliotekę) niż samemu popełnić głupi błąd np. w skomplikowanym wyrażeniu regularnym. Wierzy się, że w dojrzałych językach (/platformach/frameworkach/bibliotekach) większość błędów została już znaleziona i wyplewiona. Jeśli chcemy rozwiązań autorskich – czy mamy czas (i fundusze) na nawet wieloletnie testy?

[PHP] Bezpieczne logowanie błędów

Pozostając w temacie tworzenia bezpiecznych aplikacji webowych, pora przedstawić dobre zwyczaje odnośnie logowania błędów w aplikacjach PHP.

  • Podczas pracy programistycznej, najlepiej ustawić najwyższy poziom logowania błędów: zmienna error_reporting powinna otrzymać flagę E_ALL | E_STRICT (gdzie znak | oznacza po prostu OR). Więcej flag: http://php.net/manual/en/errorfunc.constants.php. Takie ustawienia pozwolą na wyłapanie nawet drobnych błędów na samym początku produkcji.
  • Podczas wdrożenia aplikacji oczywiście logi powinny zostać wyłączone (lub raczej – przekierowane w całości do pliku z logami. Poziom można wtedy zredukować). Dokonuje się tego za pomocą flag log_errors, error_log, display_errors. Można również użyć własnego przechwytywania błędów (set_error_handler).

Dane w bezpiecznych aplikacjach – pisanie i testowanie

Proponowana w mej ostatniej lekturze strategia tworzenia bezpiecznych aplikacji opiera się głównie na podziale danych przetwarzanych przez aplikację na dane bezpieczne i niebezpieczne.

Dane bezpieczne to te, które generujemy we wnętrzu aplikacji (np. sklejanie stringa, obliczenia, generowanie daty itp.). Uwaga jednak na zewnętrzne biblioteki – „w trybie paranoika” również danych pochodzących z bibliotek  nie powinno traktować się jako w 100% zaufane.
Dane niebezpieczne to wszystkie dane pochodzące ze źródeł zewnętrznych: adresy URL (dane, które nadeszły wraz z żądaniem GET), dane w żądaniach typu POST, nagłówki HTTP (cookie), dane z bazy danych, pliki itp.

Opierając się na powyższym podziale, bezpieczeństwo aplikacji można zapewnić poprzez:

  • Skuteczną walidację danych niebezpiecznych. Autor zaleca, by walidacji dokonywać za pomocą funkcji wbudowanych w język (np. is_number) – minimalizujemy wtedy ryzyko popełnienia błędu we własnych funkcjach. Wyrażeń regularnych używamy w ostateczności.
  • Nie opieranie się na interfejsie. To, że w interfejsie aplikacji użyliśmy checkboxa z kilkoma dozwolonymi wartościami nie oznacza, że użytkownik nie spreparuje żądania, przesyłając dane, których się nie spodziewamy.

dane_bezpieczne2

Czytaj dalej