Wykład z konferencji 4Developers 2015.
OWASP - Open Web Applications Security Project to fundacja non-profit której celem jest eliminacja problemów bezpieczeństwa aplikacji.
W trakcie wykładu przedstawie krótko OWASP Top 10 w wydaniu dla programistów, czyli "Top 10 Proactive Controls" a więc najważniejsze zalecenia pozwalające na uniknięcie kluczowych błędów bezpieczeństwa.
Testowanie poziomu bezpieczeństwa aplikacji internetowychAntoni Orfin
Niniejsza praca ma za zadanie przedstawić zagrożenia związane z bezpieczeństwem aplikacji internetowych.
Omawia najpowszechniejsze rodzaje zagrożeń, przykłady podatności i sposoby ochrony. Pozwoli na zapoznanie się z ogólnymi zasadami, którymi powinny kierować się osoby odpowiedzialne za wytwarzanie systemów webowych. Jest również bazą która pozwoli skuteczniej przeprowadzać audyty bezpieczeństwa.
Co to jest SQL injection i jak wyglądają współczesne ataki na serwisy? Dlaczego SQL injection jest takie groźne? Jak w praktyce obronić się przed tą luką w bezpieczeństwie i ocalić swoje dane?
Kompletny przewodnik po SQL injection dla developerów PHP (i nie tylko)Krzysztof Kotowicz
W trakcie prezentacji zademonstrujemy szkody, na jesteście narażeni nie myśląc o SQL injection. Dowiecie się, jak się przed nim bronić - zarówno w teorii, jak i na konkretnych przykładach. Nauczymy się pisać bezpiecznie w PHP 5 - sprawdzimy Zend Framework i Symfony, przenalizujemy Propel, Doctrine, PDO i mdb2. Omówimy wszystkie kruczki i różnice między różnymi systemami baz danych (Oracle, MS SQL Server, MySQL) oraz nauczymy się pisać procedury składowane odporne na SQL injection.
Bezpieczeństwo aplikacji czy musi być aż tak źleSecuRing
Prezentacja z konferencji SECURE 2012 (Warszawa, 22-24.10.2012)
Aplikacje to prawdziwa pięta achillesowa współczesnych systemów IT. Zarówno własne doświadczenia jak i dostępne opracowania wskazują, że w większości aplikacji, niezależnie od stosowanej technologii, można znaleźć poważne podatności. Na domiar złego – zewnętrzne zabezpieczenia (firewalle, IPS, WAF, itp.) mają ograniczoną skuteczność dla ochrony aplikacji. Ciągle, najlepszą metodą radzenia sobie z ewentualnymi podatnościami w eksploatowanych aplikacjach jest unikanie ryzyka, czyli wytwarzanie, bądź zamawianie oprogramowania, które nie posiada istotnych błędów bezpieczeństwa. Ale czy jest to możliwe w praktyce?
Agenda:
- Wprowadzenie do problemu
- Kilka ciekawych przykładów
- Krótko o nowych źródłach ryzyka (AJAX, HTML5, aplikacje mobilne, NFC, ...)
- Przyczyny powstawania podatności we współczesnych aplikacjach.
- Jak postępować w trakcie tworzenia lub zamawiania aplikacji, żeby ograniczyć możliwość powstania istotnych błędów?
W szczególności krótko zostaną zaprezentowane ogólnodostępne narzędzia i dokumenty OWASP pomagające zbudować bezpieczne aplikacje (np.: ASVS - Application Security Verification Standard, OpenSAMM - Security Assurance Maturity Model, OWASP Cheat Sheets).
Testowanie bezpieczeństwa – jak dostosować zakres do realnych zagrożeń i budżetuSecuRing
Jednym z problemów przed którym staje manager bezpieczeństwa lub kierownik projektu, który chce sprawdzić bezpieczeństwo systemu informatycznego to właściwy dobór zakresu testów bezpieczeństwa. Z jednej strony test zbyt ogólny może nie wykryć wielu istotnych słabości, z drugiej strony – dogłębne testy i analizy bezpieczeństwa nie mają ekonomicznego uzasadnienia dla każdego systemu i aplikacji eksploatowanej w firmie. Czas specjalistów, zarówno zewnętrznych jak i wewnętrznych, kosztuje i jest ograniczony, natomiast czas potencjalnych intruzów – nie. Tym bardziej istotne jest optymalne wykorzystanie czasu i budżetu przeznaczonego na testy bezpieczeństwa.
Celem prezentacji jest zachęcenie do dyskusji nad tym jak właściwie dobrać zakres testów bezpieczeństwa.
Prezentacja z konferencji SEMAFOR 2013, 5-6 marca 2013
Wykład z konferencji 4Developers 2015.
OWASP - Open Web Applications Security Project to fundacja non-profit której celem jest eliminacja problemów bezpieczeństwa aplikacji.
W trakcie wykładu przedstawie krótko OWASP Top 10 w wydaniu dla programistów, czyli "Top 10 Proactive Controls" a więc najważniejsze zalecenia pozwalające na uniknięcie kluczowych błędów bezpieczeństwa.
Testowanie poziomu bezpieczeństwa aplikacji internetowychAntoni Orfin
Niniejsza praca ma za zadanie przedstawić zagrożenia związane z bezpieczeństwem aplikacji internetowych.
Omawia najpowszechniejsze rodzaje zagrożeń, przykłady podatności i sposoby ochrony. Pozwoli na zapoznanie się z ogólnymi zasadami, którymi powinny kierować się osoby odpowiedzialne za wytwarzanie systemów webowych. Jest również bazą która pozwoli skuteczniej przeprowadzać audyty bezpieczeństwa.
Co to jest SQL injection i jak wyglądają współczesne ataki na serwisy? Dlaczego SQL injection jest takie groźne? Jak w praktyce obronić się przed tą luką w bezpieczeństwie i ocalić swoje dane?
Kompletny przewodnik po SQL injection dla developerów PHP (i nie tylko)Krzysztof Kotowicz
W trakcie prezentacji zademonstrujemy szkody, na jesteście narażeni nie myśląc o SQL injection. Dowiecie się, jak się przed nim bronić - zarówno w teorii, jak i na konkretnych przykładach. Nauczymy się pisać bezpiecznie w PHP 5 - sprawdzimy Zend Framework i Symfony, przenalizujemy Propel, Doctrine, PDO i mdb2. Omówimy wszystkie kruczki i różnice między różnymi systemami baz danych (Oracle, MS SQL Server, MySQL) oraz nauczymy się pisać procedury składowane odporne na SQL injection.
Bezpieczeństwo aplikacji czy musi być aż tak źleSecuRing
Prezentacja z konferencji SECURE 2012 (Warszawa, 22-24.10.2012)
Aplikacje to prawdziwa pięta achillesowa współczesnych systemów IT. Zarówno własne doświadczenia jak i dostępne opracowania wskazują, że w większości aplikacji, niezależnie od stosowanej technologii, można znaleźć poważne podatności. Na domiar złego – zewnętrzne zabezpieczenia (firewalle, IPS, WAF, itp.) mają ograniczoną skuteczność dla ochrony aplikacji. Ciągle, najlepszą metodą radzenia sobie z ewentualnymi podatnościami w eksploatowanych aplikacjach jest unikanie ryzyka, czyli wytwarzanie, bądź zamawianie oprogramowania, które nie posiada istotnych błędów bezpieczeństwa. Ale czy jest to możliwe w praktyce?
Agenda:
- Wprowadzenie do problemu
- Kilka ciekawych przykładów
- Krótko o nowych źródłach ryzyka (AJAX, HTML5, aplikacje mobilne, NFC, ...)
- Przyczyny powstawania podatności we współczesnych aplikacjach.
- Jak postępować w trakcie tworzenia lub zamawiania aplikacji, żeby ograniczyć możliwość powstania istotnych błędów?
W szczególności krótko zostaną zaprezentowane ogólnodostępne narzędzia i dokumenty OWASP pomagające zbudować bezpieczne aplikacje (np.: ASVS - Application Security Verification Standard, OpenSAMM - Security Assurance Maturity Model, OWASP Cheat Sheets).
Testowanie bezpieczeństwa – jak dostosować zakres do realnych zagrożeń i budżetuSecuRing
Jednym z problemów przed którym staje manager bezpieczeństwa lub kierownik projektu, który chce sprawdzić bezpieczeństwo systemu informatycznego to właściwy dobór zakresu testów bezpieczeństwa. Z jednej strony test zbyt ogólny może nie wykryć wielu istotnych słabości, z drugiej strony – dogłębne testy i analizy bezpieczeństwa nie mają ekonomicznego uzasadnienia dla każdego systemu i aplikacji eksploatowanej w firmie. Czas specjalistów, zarówno zewnętrznych jak i wewnętrznych, kosztuje i jest ograniczony, natomiast czas potencjalnych intruzów – nie. Tym bardziej istotne jest optymalne wykorzystanie czasu i budżetu przeznaczonego na testy bezpieczeństwa.
Celem prezentacji jest zachęcenie do dyskusji nad tym jak właściwie dobrać zakres testów bezpieczeństwa.
Prezentacja z konferencji SEMAFOR 2013, 5-6 marca 2013
Testowanie bezpieczeństwa aplikacji dedykowanych na platformę AndroidSecuRing
Celem prezentacji jest zapoznanie słuchaczy z metodami badania bezpieczeństwa aplikacji przeznaczonych na Androida. Zaprezentowane zostaną faktyczne przykłady podatności znalezionych w trakcie testów penetracyjnych. Dodatkowo, omówione będą podstawowe narzędzia oraz techniki niezbędne do przeprowadzanych testów bezpieczeństwa.
Prezentacja z konferencji SEMAFOR 2014.
Prezentacja ma na celu przedstawienie standardu weryfikacji bezpieczeństwa aplikacji ASVS (Application Security Verification Standard). Standard ten można stosować już na etapie definiowania wymagań w celu ustalenia wymagań dotyczących zabezpieczeń (również niefunkcjonalnych). Na etapie weryfikacji umożliwia on sprawdzenie czy są stosowane zasady dobrej praktyki i pozwala audytorowi na wypowiedzenie się o tym co jest poprawne a nie tylko na koncentrowanie się na błędach, jak to ma miejsce przy nieustandaryzowanych testach bezpieczeństwa. Ponadto stosowanie ASVS powoduje sprecyzowanie zakresu testów bezpieczeństwa a co za tym idzie sprowadzenie porównywanych ofert na testy weryfikacyjne do wspólnego mianownika.
Warto również podkreślić, że ASVS ma formę listy kontrolnej podzielonej na poziomy w zależności od ryzyka, w związku z tym zakres weryfikacji może być dobrany adekwatnie do specyfiki aplikacji.
Standard ten został stworzony w roku 2009 roku w ramach projektu OWASP (Open Web Application Security Project) i został przetłumaczony na kilkanaście języków, w tym polski. W tym roku ukazuje się nowa aktualizacja standardu ASVS i na tej nowej wersji będzie skupiona prezentacja.
4Developers 2015: Wybrane podatności w aplikacjach webowych - Michał SajdakPROIDEA
YouTube: https://www.youtube.com/watch?v=eRkD2a4vMsc&list=PLnKL6-WWWE_WNYmP_P5x2SfzJ7jeJNzfp&index=38
Speaker: Michał Sajdak
Language: Polish
W trakcie prelekcji zaprezentowane zostaną ciekawe podatności w aplikacjach webowych - w tym kilka nieoczywistych metod uzyskiwania shella na systemie operacyjnym czy podatność XXE. Każdy omawiany problem, po krótkim wstępie teoretycznym, prezentowany jest na żywo.
4Developers: http://4developers.org.pl/pl/
Zhakuj swojego Wordpressa, WordUP Trojmiastosecman_pl
Prezentacja na WordUP Trójmiasto poświęcona metodom testowania bezpieczeństwa tworzonych przez deweloperów dodatków do Wordpressa. W prezentacji skontrowano się na wybranych atakach na aplikacje webowe: SQL injection, XSS, Upload PHP shell
JDD2014/ 4Developers 2015: Błędy uwierzytelniania i zarządzania sesją w JEE -...PROIDEA
Celem wykładu jest pokazanie na czym polega Broken Authetication and Session Management – co to tak naprawdę oznacza. Jakie mogą być tego konsekwencje i czy to występuje obecnie w JEE.
Wykład jest przeznaczony dla osób tworzących aplikacje korzystając z WEBowych frameworków Java.
Broken Authetication and Session Management jest od wielu lat klasyfikowany przez OWASP (Open Web Application Security Project) jako jedna z groźniejszych podatność aplikacji WEBowych.
Fragment prezentacji firmy YetiForce dotyczącej OWASP ASVS 3.1 EA a w szczególności punktu pierwszego "1: Architektura, projektowanie i modelowanie zagrożeń".
[4developers] OWASP ASVS - ściągawka z bezpieczeństwa dla programistyPROIDEA
OWASP ASVS to standard weryfikacji bezpieczeństwa aplikacji. Jest to lista kontrolna do weryfikacji bezpieczeństwa aplikacji ale można ją też zastosować jako listę dobrych praktyk przy projektowaniu, wytwarzaniu i testach wewnętrznych.
Pod koniec roku 2015 ukazała się nowa wersja OWASP ASVS 3.0. Zmiany w nowej wersji obejmują m.in.: uzupełnienie listy kontrolnej o rozdziały dotyczące konfiguracji, aplikacji mobilnych, WebServices i REST, mapowanie na standard PCI-DSS, uporządkowanie wielu zapisów. Prezentacja będzie miała na celu omówienie standardu oraz najważniejszych zmian w bieżącej wersji.
4Developers: Mateusz Olejarka- Jak utrzymać bezpieczeństwo aplikacji po wdroż...PROIDEA
W trakcie swojej prezentacji poruszę problematykę utrzymania bezpieczeństwa aplikacji po wdrożeniu produkcyjnym z perspektywy dostawcy aplikacji. Na przykładowych aplikacjach (platforma SaaS, aplikacja tworzona zwinnie, aplikacja tworzona w waterfall) pokażę wyzwania z tym związane, w odniesieniu do konkretnej aplikacji oraz realiów, w jakich funkcjonuje. Wspólnie z uczestnikami przeanalizujemy możliwe mechanizmy mające na celu utrzymanie bezpieczeństwa aplikacji. Zastanowimy się nad optymalnym ich doborem oraz momentem, w którym warto z nich skorzystać, uwzględniając również koszt wykorzystania danego mechanizmu. Przyjrzymy się mechanizmom takim jak: • testy penetracyjne • konsultacje/szkolenia • definiowanie wymagań dotyczących bezpieczeństwa aplikacji • obsługa incydentów • narzędzia automatyczne • monitorowanie podatności w wykorzystywanych komponentach Postaramy się również wypracować odpowiedzi na poniższe pytania: • Co można zrobić wewnętrznie? • Jakie prace zlecić? • Jakich kompetencji poszukać? • Jak dobrać szkolenia? • Jakiego typu narzędzi poszukać? Chciałbym dać uczestnikom proste recepty na to, jak zadbać o utrzymanie bezpieczeństwa aplikacji, z którymi pracują.
Prezentacja z konferencji ISSA InfoTRAMS Holistic Application Security
Od kilku lat na świecie jest promowane podejście polegające na wpisaniu bezpieczeństwa w cały cykl rozwojowy oprogramowania. W polskiej praktyce, nadal kwestie związane z bezpieczeństwem najczęściej poruszane są na dopiero na końcu projektu, tuż przed wdrożeniem gdy wykonywane są testy bezpieczeństwa. Bardzo często takie podejście skutkuje znacznymi kosztami usuwania błędów i sporym "zamieszaniem" w projekcie, ale o tym firma przekonuje się dopiero "za 5 dwunasta", po wykonaniu testów bezpieczeństwa. Z reguły, usuwanie podatności na tym etapie projektu polega na "gaszeniu pożarów" i przyklejaniu kolejnych łatek zamiast wprowadzenia systemowych zmian. W rezultacie, w dalszym cyklu życia, po wprowadzeniu zmian funkcjonalnych wypływają nowe przypadki wystąpienia starych błędów.
Jak to zmienić? Czy zastosowanie podstawowych zasad tworzenia bezpiecznego oprogramowania jest faktycznie takie skomplikowane jak by mogło się wydawać?
W trakcie prezentacji zostaną przedstawione metodyki wprowadzania bezpieczeństwa do całego cyklu rozwojowego oprogramowania (na przykładzie OWASP SAMM), również z uwzględnieniem sytuacji, gdy stworzenie aplikacji zlecane jest dla firmy zewnętrznej. Krótko omówiona zostanie skuteczność i potencjalne problemy tych metodyk w naszych, polskich realiach. Przedstawione zostanie także kilka prostych sposobów, które zdaniem autora pozwolą na skuteczniejsze osiągnięcie zamierzonego efektu - czyli aplikacji nieobarczonej podatnościami.
Najciekawsze podatności znalezione przez nasz zespół w trakcie testowania bezpieczeństwa aplikacji Android – przede
wszystkim bankowości czy płatności mobilnych.
Owasp asvs 3.0 co nowego w bezpieczeństwie aplikacjiOWASP
OWASP ASVS to standard weryfikacji bezpieczeństwa aplikacji. Standard ten popularny zarówno w Polsce jak i na świecie pomaga zarówno w weryfikacji bezpieczeństwa jak i podczas definiowania wymagań dotyczących bezpieczeństwa aplikacji (funkcjonalnych i niefunkcjonalnych).
Na etapie weryfikacji umożliwia on sprawdzenie czy są stosowane zasady dobrej praktyki i pozwala audytorowi na wypowiedzenie się o tym co jest poprawne a nie tylko na koncentrowanie się na błędach, jak to ma miejsce przy nieustandaryzowanych testach bezpieczeństwa. Ponadto stosowanie ASVS powoduje sprecyzowanie zakresu testów bezpieczeństwa a co jest istotne przy zlecaniu testów bezpieczeństwa na zewnątrz organizacji.
Pod koniec roku 2015 ukazała się nowa wersja OWASP ASVS 3.0. Zmiany w nowej wersji obejmują m.in.: uzupełnienie listy kontrolnej o rozdziały dotyczące konfiguracji, aplikacji mobilnych, WebServices i REST, mapowanie na bazę podatności CWE i standard PCI-DSS, uporządkowanie wielu zapisów. Prezentacja będzie miała na celu omówienie standardu oraz najważniejszych zmian w bieżącej wersji.
Jakub Syta, dyrektor departamentu cyberbezpieczeństwa w EXATEL o tym, jak w praktyce działa centrum cyberbezpieczeństwa (Security Operations Center). Prezentacja miała miejsce podczas październikowych warsztatów EXATEL InTECH Day.
Najciekawsze podatności znalezione przez nasz zespół w trakcie testowania bezpieczeństwa aplikacji mobilnych – przede wszystkim finansowych (bankowość, płatności).
Większość banków stosuje w swoich systemach bankowości internetowej i mobilnej metody autoryzacji transakcji (np. hasła SMS, "podpis elektroniczny", tokeny OTP, tokeny challenge-response). Stosowanie tego typu metod nie jest ograniczone tylko do systemów finansowych, są np. szeroko stosowane do autoryzowania operacji odzyskiwania hasła w różnego rodzaju aplikacjach.
Autoryzacja transakcji ma ograniczać skutki wynikające z działania wrogiego oprogramowania na stacji użytkownika, przechwytywania sesji oraz zgadywania czy kradzieży haseł.
W ostatnich latach widzimy jednak, że strategie działania grup przestępczych dostosowują się do tych zabezpieczeń i niejednokrotnie skutecznie je omijają. Prezentacja ma na celu skonfrontowanie obecnych metod autoryzacji operacji ze współczesnymi scenariuszami ataku przy użyciu malware oraz wskazanie typowych błędów w implementacji, które mogą przyczynić się do możliwości obejścia tych zabezpieczeń.
Agenda (draft):
- Krótka prezentacja metod autoryzacji transakcji.
- Kilka "case study" - jak malware obchodzi autoryzacje transakcji (w tym własne doświadczenia zdobyte podczas analizy przypadków ataków w bankach).
- Jak wybrać skuteczną metodę autoryzacji transakcji?
- Na co uważać? Typowe błędy implementacji, które mogą przyczynić się do osłabienia mechanizmu autoryzacji transakcji.
Testowanie bezpieczeństwa aplikacji dedykowanych na platformę AndroidSecuRing
Celem prezentacji jest zapoznanie słuchaczy z metodami badania bezpieczeństwa aplikacji przeznaczonych na Androida. Zaprezentowane zostaną faktyczne przykłady podatności znalezionych w trakcie testów penetracyjnych. Dodatkowo, omówione będą podstawowe narzędzia oraz techniki niezbędne do przeprowadzanych testów bezpieczeństwa.
Prezentacja z konferencji SEMAFOR 2014.
Prezentacja ma na celu przedstawienie standardu weryfikacji bezpieczeństwa aplikacji ASVS (Application Security Verification Standard). Standard ten można stosować już na etapie definiowania wymagań w celu ustalenia wymagań dotyczących zabezpieczeń (również niefunkcjonalnych). Na etapie weryfikacji umożliwia on sprawdzenie czy są stosowane zasady dobrej praktyki i pozwala audytorowi na wypowiedzenie się o tym co jest poprawne a nie tylko na koncentrowanie się na błędach, jak to ma miejsce przy nieustandaryzowanych testach bezpieczeństwa. Ponadto stosowanie ASVS powoduje sprecyzowanie zakresu testów bezpieczeństwa a co za tym idzie sprowadzenie porównywanych ofert na testy weryfikacyjne do wspólnego mianownika.
Warto również podkreślić, że ASVS ma formę listy kontrolnej podzielonej na poziomy w zależności od ryzyka, w związku z tym zakres weryfikacji może być dobrany adekwatnie do specyfiki aplikacji.
Standard ten został stworzony w roku 2009 roku w ramach projektu OWASP (Open Web Application Security Project) i został przetłumaczony na kilkanaście języków, w tym polski. W tym roku ukazuje się nowa aktualizacja standardu ASVS i na tej nowej wersji będzie skupiona prezentacja.
4Developers 2015: Wybrane podatności w aplikacjach webowych - Michał SajdakPROIDEA
YouTube: https://www.youtube.com/watch?v=eRkD2a4vMsc&list=PLnKL6-WWWE_WNYmP_P5x2SfzJ7jeJNzfp&index=38
Speaker: Michał Sajdak
Language: Polish
W trakcie prelekcji zaprezentowane zostaną ciekawe podatności w aplikacjach webowych - w tym kilka nieoczywistych metod uzyskiwania shella na systemie operacyjnym czy podatność XXE. Każdy omawiany problem, po krótkim wstępie teoretycznym, prezentowany jest na żywo.
4Developers: http://4developers.org.pl/pl/
Zhakuj swojego Wordpressa, WordUP Trojmiastosecman_pl
Prezentacja na WordUP Trójmiasto poświęcona metodom testowania bezpieczeństwa tworzonych przez deweloperów dodatków do Wordpressa. W prezentacji skontrowano się na wybranych atakach na aplikacje webowe: SQL injection, XSS, Upload PHP shell
JDD2014/ 4Developers 2015: Błędy uwierzytelniania i zarządzania sesją w JEE -...PROIDEA
Celem wykładu jest pokazanie na czym polega Broken Authetication and Session Management – co to tak naprawdę oznacza. Jakie mogą być tego konsekwencje i czy to występuje obecnie w JEE.
Wykład jest przeznaczony dla osób tworzących aplikacje korzystając z WEBowych frameworków Java.
Broken Authetication and Session Management jest od wielu lat klasyfikowany przez OWASP (Open Web Application Security Project) jako jedna z groźniejszych podatność aplikacji WEBowych.
Fragment prezentacji firmy YetiForce dotyczącej OWASP ASVS 3.1 EA a w szczególności punktu pierwszego "1: Architektura, projektowanie i modelowanie zagrożeń".
[4developers] OWASP ASVS - ściągawka z bezpieczeństwa dla programistyPROIDEA
OWASP ASVS to standard weryfikacji bezpieczeństwa aplikacji. Jest to lista kontrolna do weryfikacji bezpieczeństwa aplikacji ale można ją też zastosować jako listę dobrych praktyk przy projektowaniu, wytwarzaniu i testach wewnętrznych.
Pod koniec roku 2015 ukazała się nowa wersja OWASP ASVS 3.0. Zmiany w nowej wersji obejmują m.in.: uzupełnienie listy kontrolnej o rozdziały dotyczące konfiguracji, aplikacji mobilnych, WebServices i REST, mapowanie na standard PCI-DSS, uporządkowanie wielu zapisów. Prezentacja będzie miała na celu omówienie standardu oraz najważniejszych zmian w bieżącej wersji.
4Developers: Mateusz Olejarka- Jak utrzymać bezpieczeństwo aplikacji po wdroż...PROIDEA
W trakcie swojej prezentacji poruszę problematykę utrzymania bezpieczeństwa aplikacji po wdrożeniu produkcyjnym z perspektywy dostawcy aplikacji. Na przykładowych aplikacjach (platforma SaaS, aplikacja tworzona zwinnie, aplikacja tworzona w waterfall) pokażę wyzwania z tym związane, w odniesieniu do konkretnej aplikacji oraz realiów, w jakich funkcjonuje. Wspólnie z uczestnikami przeanalizujemy możliwe mechanizmy mające na celu utrzymanie bezpieczeństwa aplikacji. Zastanowimy się nad optymalnym ich doborem oraz momentem, w którym warto z nich skorzystać, uwzględniając również koszt wykorzystania danego mechanizmu. Przyjrzymy się mechanizmom takim jak: • testy penetracyjne • konsultacje/szkolenia • definiowanie wymagań dotyczących bezpieczeństwa aplikacji • obsługa incydentów • narzędzia automatyczne • monitorowanie podatności w wykorzystywanych komponentach Postaramy się również wypracować odpowiedzi na poniższe pytania: • Co można zrobić wewnętrznie? • Jakie prace zlecić? • Jakich kompetencji poszukać? • Jak dobrać szkolenia? • Jakiego typu narzędzi poszukać? Chciałbym dać uczestnikom proste recepty na to, jak zadbać o utrzymanie bezpieczeństwa aplikacji, z którymi pracują.
Prezentacja z konferencji ISSA InfoTRAMS Holistic Application Security
Od kilku lat na świecie jest promowane podejście polegające na wpisaniu bezpieczeństwa w cały cykl rozwojowy oprogramowania. W polskiej praktyce, nadal kwestie związane z bezpieczeństwem najczęściej poruszane są na dopiero na końcu projektu, tuż przed wdrożeniem gdy wykonywane są testy bezpieczeństwa. Bardzo często takie podejście skutkuje znacznymi kosztami usuwania błędów i sporym "zamieszaniem" w projekcie, ale o tym firma przekonuje się dopiero "za 5 dwunasta", po wykonaniu testów bezpieczeństwa. Z reguły, usuwanie podatności na tym etapie projektu polega na "gaszeniu pożarów" i przyklejaniu kolejnych łatek zamiast wprowadzenia systemowych zmian. W rezultacie, w dalszym cyklu życia, po wprowadzeniu zmian funkcjonalnych wypływają nowe przypadki wystąpienia starych błędów.
Jak to zmienić? Czy zastosowanie podstawowych zasad tworzenia bezpiecznego oprogramowania jest faktycznie takie skomplikowane jak by mogło się wydawać?
W trakcie prezentacji zostaną przedstawione metodyki wprowadzania bezpieczeństwa do całego cyklu rozwojowego oprogramowania (na przykładzie OWASP SAMM), również z uwzględnieniem sytuacji, gdy stworzenie aplikacji zlecane jest dla firmy zewnętrznej. Krótko omówiona zostanie skuteczność i potencjalne problemy tych metodyk w naszych, polskich realiach. Przedstawione zostanie także kilka prostych sposobów, które zdaniem autora pozwolą na skuteczniejsze osiągnięcie zamierzonego efektu - czyli aplikacji nieobarczonej podatnościami.
Najciekawsze podatności znalezione przez nasz zespół w trakcie testowania bezpieczeństwa aplikacji Android – przede
wszystkim bankowości czy płatności mobilnych.
Owasp asvs 3.0 co nowego w bezpieczeństwie aplikacjiOWASP
OWASP ASVS to standard weryfikacji bezpieczeństwa aplikacji. Standard ten popularny zarówno w Polsce jak i na świecie pomaga zarówno w weryfikacji bezpieczeństwa jak i podczas definiowania wymagań dotyczących bezpieczeństwa aplikacji (funkcjonalnych i niefunkcjonalnych).
Na etapie weryfikacji umożliwia on sprawdzenie czy są stosowane zasady dobrej praktyki i pozwala audytorowi na wypowiedzenie się o tym co jest poprawne a nie tylko na koncentrowanie się na błędach, jak to ma miejsce przy nieustandaryzowanych testach bezpieczeństwa. Ponadto stosowanie ASVS powoduje sprecyzowanie zakresu testów bezpieczeństwa a co jest istotne przy zlecaniu testów bezpieczeństwa na zewnątrz organizacji.
Pod koniec roku 2015 ukazała się nowa wersja OWASP ASVS 3.0. Zmiany w nowej wersji obejmują m.in.: uzupełnienie listy kontrolnej o rozdziały dotyczące konfiguracji, aplikacji mobilnych, WebServices i REST, mapowanie na bazę podatności CWE i standard PCI-DSS, uporządkowanie wielu zapisów. Prezentacja będzie miała na celu omówienie standardu oraz najważniejszych zmian w bieżącej wersji.
Jakub Syta, dyrektor departamentu cyberbezpieczeństwa w EXATEL o tym, jak w praktyce działa centrum cyberbezpieczeństwa (Security Operations Center). Prezentacja miała miejsce podczas październikowych warsztatów EXATEL InTECH Day.
Najciekawsze podatności znalezione przez nasz zespół w trakcie testowania bezpieczeństwa aplikacji mobilnych – przede wszystkim finansowych (bankowość, płatności).
Większość banków stosuje w swoich systemach bankowości internetowej i mobilnej metody autoryzacji transakcji (np. hasła SMS, "podpis elektroniczny", tokeny OTP, tokeny challenge-response). Stosowanie tego typu metod nie jest ograniczone tylko do systemów finansowych, są np. szeroko stosowane do autoryzowania operacji odzyskiwania hasła w różnego rodzaju aplikacjach.
Autoryzacja transakcji ma ograniczać skutki wynikające z działania wrogiego oprogramowania na stacji użytkownika, przechwytywania sesji oraz zgadywania czy kradzieży haseł.
W ostatnich latach widzimy jednak, że strategie działania grup przestępczych dostosowują się do tych zabezpieczeń i niejednokrotnie skutecznie je omijają. Prezentacja ma na celu skonfrontowanie obecnych metod autoryzacji operacji ze współczesnymi scenariuszami ataku przy użyciu malware oraz wskazanie typowych błędów w implementacji, które mogą przyczynić się do możliwości obejścia tych zabezpieczeń.
Agenda (draft):
- Krótka prezentacja metod autoryzacji transakcji.
- Kilka "case study" - jak malware obchodzi autoryzacje transakcji (w tym własne doświadczenia zdobyte podczas analizy przypadków ataków w bankach).
- Jak wybrać skuteczną metodę autoryzacji transakcji?
- Na co uważać? Typowe błędy implementacji, które mogą przyczynić się do osłabienia mechanizmu autoryzacji transakcji.
Poznaj usługi z zakresu ochrony informacji organizacji oraz bezpieczeństwa i efektywnej pracy zdalnej. Microsoft Azure, Enterprise Mobility + Security, Operation Management Suite
OWASP Mobile TOP 10 na przykładzie aplikacji bankowych - Semafor 2016 - Mateu...Logicaltrust pl
Wnioski z technicznego badania kilkudziesięciu polskich aplikacji bankowych przeznaczonych na platformy Android oraz iOS pod kątem występowania w nich podatności z OWASP Mobile TOP 10. Prezentacja rzeczywistych błędów w oprogramowaniu mobilnym, praktycznych porad jak zabezpieczyć aplikacje oraz odniesienie uzyskanych rezultatów do badań przeprowadzonych w innych krajach.
Bezpieczeństwo to jeden z priorytetów, które trzeba wziąć pod uwagę podczas tworzenia aplikacji. OWASP ASVS to odkładnie wytyczone standardy bezpieczeństwa wytyczone dla każdego programu, nie tylko open source.
Jak powinna wyglądać architektura, projektowanie i modelowanie zagrożeń?
60. Definition of FIPS 140-2 Cryptographic StandardPrzykładowe ataki Atak #1: Strona nie używa SSL na stronach z wymagana autentykacja. Atakujący monitoruje ruch sieciowy (w sieci WiFi lub sieci lokalnej) I zbiera dane autentykacyjne typu ID sesji, zawartość ciasteczek. Zebrane w ten sposób dane mogą być użyte w celu ich odtworzenia I zalogowania się na konta ofiar. Atak #2: Strona posiada niepoprawnie skonfigurowany certyfikat. Użytkownicy aby korzystać ze strony musza akceptować ostrzeżenia. W wyniku ataku phishingowego użytkownicy nie odróżniają certyfikatów prawdziwych od fałszywych, co w efekcie może doprowadzić do ujawnienia prywatnych danych Atak#3: Strona używa polaczeń ODBC/JDBC bez szyfrowania, w rezultacie cały ruch jest nieszyfrowany I podatny na atak.
68. Szczegóły czynników ryzyka +F Słabości Bezpieczeństwa Wpływy Techniczne Wpływy Biznesowe Wektory Ataku Czynniki Zagrożenia Wystepowanie Wykrywalność Wykorzystanie Wpływ
Editor's Notes
Can we squeeze a mention of ‘parameter tampering’?It would also be nice to mention query constraints as a defense but maybe that’s too esoteric.