Ja nie do końca zgadzam się z twierdzeniem, że wybór języka programowania, a właściwie szerzej – całego środowiska, w którym powstaje aplikacja, nie ma wpływu na bezpieczeństwo produktu wyjściowego.
Jeśli ktoś jest zainteresowany tematem bezpieczeństwa aplikacji internetowych, to powinien zainteresować się udostępnionym przez Google kursem Web Application Exploits and Defenses. Główne tematy poruszane w tym kursie to:
Cross-Site Scripting (XSS)
Client-State Manipulation
Cross-Site Request Forgery (XSRF)
Cross Site Script Inclusion (XSSI)
Path Traversal
Denial of Service
Code Execution
Configuration Vulnerabilities
AJAX vulnerabilities
Część z tych zagadnień poruszałem w moim krótkim przewodniku po bezpieczeństwie aplikacji internetowych, części nie poruszałem (np. ciężko mi było napisać bezpieczny dla mnie przykład do danego zagadnienia). Kilka zagadnień (np. SQLi) poruszanych jest z przykładami (na razie?) tylko u mnie.
Dla osób, które nigdy nie testowały aplikacji webowych pomocne może być moje krótkie wprowadzenie do tematu: Lekcja 1: absolutne podstawy, gdzie pokazuję jak korzystać z narzędzi typu local proxy.
Przyznam się do czegoś strasznego – nie jestem fanem Tolkiena. Próbowałem kilka razy zmusić się do przeczytania różnych jego książek i... nic. Nie udało mi się dobrnąć do końca. Ale ten cytat (z filmu, więc nie wiem jak wierny) dobrze pasuje mi do tego, o czym chcę napisać: (...) some things that should not have been forgotten were lost. History became legend. Legend became myth (...). Albo nieco inaczej – jak wiele czynności wykonywanych jest, bo tak się kiedyś robiło? Ile w tym przyzwyczajenia i tradycji, a ile sensu?
Ostatnio mój GPS doprowadził mnie kilka razy do lekkiej irytacji (czytaj – napadów furii). Głównym powodem było przeraźliwie wolne działanie AutoMapy, jej notoryczne zamieranie (zawieszanie się na kilka sekund), absolutnie nieakceptowalny czas wyznaczania i korygowania trasy oraz opracowywania wskazówek nawigacji. Objawy pojawiły się z chwilą aktualizacji oprogramowania do najnowszej wersji (lubię mieć aktualne mapy) i w pierwszej chwili wiązałem je z wprowadzeniem jakiejś nowej funkcji lub nowych, lepszych błędów. Po pewnym czasie wpadłem na jeszcze jeden pomysł – wolna praca karty SD. Dziś miałem okazję zweryfikować ten trop, wyglądało to mniej więcej tak:
włóż kartę SD do laptopa,
skopiuj zawartość na dysk,
usuń zawartość karty,
sformatuj kartę,
skopiuj dane na kartę,
Efekt – piorunujący. Irytujące objawy zniknęły bez śladu.
Zadania związane z obfuskowanym kodem JavaScript zostały rozwiązane, głównie przez Krzysztofa Kotowicza. Planowałem przygotować jeszcze jedną mutację tego zadania, ale ostatecznie chyba ją sobie odpuszczę, przynajmniej na razie. Do rozwiązania pozostają jeszcze inne zadania, związane z phishingiem na formatce logowania, oraz kontrolą dostępu do funkcji. Pora na wyjaśnienie zadania dotyczącego kontroli dostępu do funkcji.
Skusiłem się ostatnio na książkę 2012: Gniew Ojca. Choć widywałem ją w księgarni od pewnego czasu, jakoś omijałem ją szerokim łukiem. Rok 2012 w tytule sugerował kolejnego katastroficznego gniota, ale...
Zastanawiałem się właśnie nad pewnym scenariuszem ataku, do którego przydatny byłby XMLHttpRequest. Scenariusz był raczej mało prawdopodobny z uwagi na mechanizm same-origin policy , ale spróbować można. W trakcie tej próby trafiłem na kolejny przykład moich “ulubionych” różnic między przeglądarkami. Chodzi mianowicie o same-origin policy dla XMLHttpRequest, a w zasadzie o różne postępowanie przeglądarek w przypadku, gdy same-origin policy jest naruszone. Okazuje się, że Interrnet Explorer w przypadku naruszenia zasad same-origin policy nie wyśle żądania, Firefox i Chrome (a może i inne przeglądarki) żądanie wyślą. Zresztą mają ku temu pewne uzasadnienie, ale o tym później.
W poprzednim wpisie być może nie do końca jasno napisałem o co chodzi w zadaniu, bo nie wierzę by zadanie było tak trudne, że nikt nie jest w stanie go rozwiązać.