Dzisiaj kontynuacja cyklu “zrób to sam w weekend”. Tym razem przykład jak szukać błędów typu sql injection (patrz: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')) Podobnie jak ostatnim razem wpis nie będzie zawierał jakiejś wiedzy tajemnej. Chcę po prostu pokazać w jaki sposób błędy typu SQLi można w stosunkowo prosty sposób zidentyfikować. Oczywiście przy użyciu tej techniki nie da się znaleźć 100%25 błędów, ale przynajmniej całkiem sporą ich ilość. Nie jest to podejście typu fire and forget , wymaga trochę myślenia, ale to raczej jego zaleta, niż wada. No i każdy może w stosunkowo prosty sposób dostosować to podejście do swoich potrzeb.
Ten wpis nie będzie zawierał jakiejś wiedzy tajemnej. Będzie raczej pokazywał w jaki sposób można podejść do tematu testowania kontroli dostępu. A kontrola dostępu jest bardzo ważnym elementem bezpieczeństwa aplikacji. Jeśli nie jest zrealizowana w sposób konsekwentny i prawidłowy, może się to skończyć takimi informacjami: Poważny błąd w Gadu-Gadu i Gadu Air.
Na spotkaniu SPINu mówiłem między innymi o tym, że błędy związane z bezpieczeństwem powinny być w bazie błędów oznaczane tak, by było wiadomo, że jest to błąd bezpieczeństwa oraz powinny zawierać informację o powodzie tego błędu (w sensie root cause). Dziś mogę przytoczyć kolejny argument za tym, by takie znakowanie błędów bezpieczeństwa prowadzić.
Jak to zwykle bywa teoria rozmija się z praktyką. Okazuje się, że większość (wszystkie?) przeglądarek jest dość liberalna i równie ochoczo zinterpretują taki payload:
<img src=“niemamnie” onerror=“alert(/XSS/)”
Każdy może sobie to sprawdzić tutaj: http://bootcamp.threats.pl/lesson09/. Istnieją co prawda dodatkowe różnice między przeglądarkami w przypadku, gdy wspomniany kod HTML jest wstawiany poprzez innerHTML , ale to niech już każdy zainteresowany sprawdzi sobie we własnym zakresie :)
Bardzo podobają mi się takie wykresy, jak ten prezentowany niżej...
A o co chodzi? Po prostu mBank zmienia stronę logowania, ktoś przy okazji domagał się hasła maskowanego, ktoś inny odpisał mu, że to nie jest najlepszy pomysł i podał przy tym link do jednego z moich wpisów na temat haseł maskowanych, których szczerze nie lubię...
Korzystając z okazji przypomnę o swojej prezentacji dotyczącej mechanizmów bezpieczeństwa w bankowości internetowej i ich odporności na ataki z wykorzystaniem malware: Zamiast slajdów z SecDay.
Przed chwilą wróciłem ze spotkania SPINu, na którym miałem okazję mówić różne dziwne rzeczy, mam nadzieję, że ciekawe. Być może efektem ubocznym będzie kilka nowych wpisów na blogu. Po raz kolejny złapałem się na tym, że mówiąc o rzeczach oczywistych dla mnie i mojego środowiska, mogę jednocześnie mówić o rzeczach abstrakcyjnych dla innych. To chyba pokazuje, że musimy się częściej spotykać :)
Ważną rzeczą, którą chciałem przekazać jest to, że bezpieczeństwa aplikacji nie buduje się poprzez jej testowanie i przyklejanie kolejnych łatek w miejscach znalezienia i wskazania błędu. I tylko w tych miejscach. Bezpieczeństwo buduje się przez zmianę procesu tworzenia aplikacji, w którym różne testy bezpieczeństwa to tylko jeden z elementów układanki. Ważny, ale nie jedyny.
Być może spotkamy się po raz kolejny, tym razem na czymś w rodzaju prostych warsztatów. Tymczasem zapraszam do zapoznania się z moim krótkim przewodnikiem po bezpieczeństwie aplikacji internetowych. Od czegoś trzeba zacząć :) Jestem otwarty na wszelkie pytania, a może i w rezultacie pojawią się jakieś kolejne lekcje?
Jakiś czas temu pojawiły się zapowiedzi, że Acrobat Reader w kolejnej dużej wersji będzie miał piaskownicę. Pomysł doskonały, ilość błędów w obsłudze plików PDF była w ostatnim czasie zatrważająca. I w końcu pojawił się ten wyczekiwany Acrobat Reader X, co z tym sandboxem?
Całkiem ciekawy temat się z tego robi: Przeterminowana promocja. Dwa ostatnie ciekawe wpisy w temacie tego co jemy i naszych praw jako konsumentów z serwisu socjotechnika.net:
Jak czujecie się w roli konsumenta? Jak smakują wam kupowane przez was produkty? Jak często macie wrażenie, że coś jest produktem X tylko z nazwy i koło prawdziwego X nawet nie leżało?
Ciekawy tekst: Changing Passwords. Przyznam się, że ja nie zmieniam swoich haseł. No, przynajmniej nie wszystkie. Uważam, że w większości przypadków zysk z takiej praktyki nie uzasadnia jej uciążliwości. Tu nawet nie chodzi o pamiętanie zmienionego hasła, pamiętać nie muszę bo korzystam z KeePass. Zmiana kilkudziesięciu haseł trwa.
