Przymierzałem się do napisania notki odnośnie w/w tematu, ale
Przemysław Skowron zrobił
to wcześniej na swoim blogu :)
Nie zamierzam rezygnować z wpisu, więc...
Raport czytało się przyjemnie, ale tak jak wspomniał kolega
P. Skowron, również podszedłbym do sprawy bezpieczeństwa w bankowości internetowej trochę z innej strony.
Załóżmy, że klient posiadający działalność gospodarczą posiada konto firmowe w znanym banku (z dostępem przez internet). Jak wiadomo, w dzisiejszych czasach najcenniejszą rzeczą jest informacja.
Informacja która dotyczy działania firmy, kontaktów handlowych oraz strategicznych aspektów stanowi podstawę działalności na rynku danego przedsiębiorstwa. Dla klienta z kontem firmowym strata 5, czy 50 pln podczas transakcji internetowej raczej nie będzie miała większego wpływu na dalsze losy firmy. O wiele większe straty mogą powstać w chwili ujawnienia danych typu: ile pln, dla jakiego odbiorcy, z jaką datą będzie wykonywany przelew (albo historia przelewów).
Trochę inaczej wygląda sprawa w przypadku klienta indywidualnego. W tym przypadku osoba atakująca skupia się nie tylko na dostępie do konkretnej kwoty przelewu, ale również na zebraniu jak największej ilości danych odnośnie danego klienta. Tego typu dane mogą posłużyć do innego rodzaju ataków (np. phishing). Posiadając informacje odnośnie adresu, imion oraz nazwiska klienta, stanu konta jesteśmy w stanie stworzyć prawie idealnie wiarygodny e-mail od banku, nakłaniający np. do zmiany hasła, lub ponownego przelania danej kwoty ale na inny numer konta.
Czyli stosowanie tokenów potwierdzających transakcje jest złe? NIE! Absolutnie!
Warto pamiętać, że zatrzymując się na wprowadzeniu samych tokenów to tak samo jak zatrzymać się na bezpieczeństwie poprzez wprowadzenie wirtualnej klawiatury.
Cytując wpis z
w/w blogu:
"Wielokrotnie powtarzałem, że bezpieczeństwo systemu bankowości elektronicznej składa się z trzech dużych obszarów:
bezpieczeństwa samego systemu po stronie banku,
bezpieczeństwa komunikacji,
bezpieczeństwa klienta (komputera klienta),"
Podsumowując, możemy:
- sprawdzić czy strona logowania/ transakcji nie posiada żadnych błędów typu: XSS, SQL Inj., Information disc., Clickjack, CSRF...
<+Dr_Link> SSL certificate: $30.
<+CoJaBo-Aztec> Dell mainframe server: $1.
<+CoJaBo-Aztec> Discount cupon: -$80,000.
<+Dr_Link> Getting hacked by a POST injection: Priceless.
- stosować 'bezpieczne' połączenia SSL, które niewiele dadzą jeżeli pojawi się błąd z poprzedniego punktu + nie będziemy mieli ustawionej flagi Secure dla cookies.
- stosować pytanie o dane na 'wyrywki' (PESEL, hasło potwierdzające),
- wprowadzić wirtualną klawiaturę; nie aż tak dobre rozwiązanie, biorąc pod uwagę przykładowe pomysły na ominięcie tego 'zabezpieczenia',
- oraz wiele innych...
Kiedy już posiadamy super twierdzę, zabezpieczoną z trzech stron, nadal pozostaje nam najsłabsze ogniwo:
Klient...
- Halo ?
- Witam, tu bank...
Posty
