WebApps

Na początku chciałem wyjaśnić jedną rzecz - nie kwestionuję istotności tematu użyteczności aplikacji, zresztą wspominałem o tym wcześniej. Irytuje mnie natomiast "usability", czyli banda nawiedzonych, niedouczonych oszołomów, którzy uszczęśliwiają (pośrednio) mnie na siłę. Wszystko oczywiście w ramach rewitalizacji aplikacji i poprawy usability właśnie. W tym swoim ślepym zapatrzeniu we "święte księgi" przypominają mi tolkistów z Kłopotów w Hamdirholm.

Wpis ten jest związany z tematem autoryzacji transakcji, który wielokrotnie już poruszałem. Mimo tego temat wciąż nie został wyczerpany, jest ciągle wiele aspektów, o których się mówi. Jeden z nich chcę tu poruszyć, tak trochę w ramach ciekawostki.

Chyba najwyższa pora napisać trochę więcej na temat wielu ścieżek wykonania. Pierwszy przykład (http://bootcamp.threats.pl/lesson18/) kilka osób prawidłowo rozwiązało, w przypadku drugiego (http://bootcamp.threats.pl/lesson18a/) nikt się prawidłowym rozwiązaniem nie pochwalił, nawet mimo tego, że udostępniłem fragment kodu. Pewnie nie chodzi o to, że przykłady są wyjątkowo trudne, raczej nie są specjalnie ciekawe. Mimo wszystko ten umiarkowanie ciekawy temat doprowadzę do końca.

Na początek zacytuję jeden z komentarzy, którego autorem jest XANi:

Najlepszym zabezpieczeniem jest nie podążanie za "podejrzanymi" linkami ;]. Ja od jakiegoś czasu mam skrypt który odpala mi przeglądarkę + WebScarab proxy pod innym userem właśnie do "oglądania" takich rzeczy. nie jest to zabezpieczenie idealne ale zawsze coś...

Fragmentem, na który chcę zwrócić uwagę jest ten, o podejrzanych linkach.

Podpowiedź do przykładu http://bootcamp.threats.pl/lesson18a/:

            if ($b_id) {
            	$query = 'SELECT * FROM news WHERE id=:id';
            	$params['id'] = $id;
            }
            else if ($b_text && $b_type){
            	$query = 'SELECT * FROM news WHERE title LIKE :text AND public=:type';
            	$params['text'] = $text;
            	$params['type'] = $type;
            }
            else if ($b_type) {
            	$query = 'SELECT * FROM news WHERE public=:type';
            	$params['type'] = $type;
            }
            else if ($b_text) {
            	$query = 'SELECT * FROM news WHERE title LIKE \''.$text.'\'';
            }

Po wczorajszym spotkaniu OWASP chciałem zwrócić uwagę na fragment wypowiedzi Piotra Łaskawca z prezentacji dotyczącej fuzzingu i fuzzerów. Powiedział on mniej więcej tyle, że w procesie tworzenia oprogramowania (konkretnie podczas jego testowania) firma, w której pracuje wykorzystuje fuzzing. Kluczowy fragment jest jednak inny. Wykorzystywane fuzzery są tworzone specjalnie pod testowane aplikacje, bo tworzone aplikacje są na tyle specyficzne, że "standardowe" fuzzery sobie z nimi nie radzą.

Obecnie w ramach przewodnika po bezpieczeństwie aplikacji internetowych udostępnione jest 18 przykładów. Przykłady dotyczą różnych aspektów bezpieczeństwa oraz testowania aplikacji internetowych, po części po to, by pokazać, że testy penetracyjne wcale nie są gwarancją bezpieczeństwa. Ten temat poruszałem zresztą wiele razy na blogu i jeszcze kilka razy pewnie poruszę.

Dziś chciałem podsumować to, co pokazałem w przykładach, a przy okazji zapytać się, co pokazać jeszcze. Jeśli ktoś ma sugestie odnośnie tematu, na który chciałby się czegoś więcej dowiedzieć - proszę bardzo.

W ramach ciekawostki przygotowałem drobną modyfikację zadania bootcamp XVIII. Wersja ta dostępna jest pod adresem http://bootcamp.threats.pl/lesson18a/ i różni się od oryginalnej ścieżką kodu, w której występuje podatność. O ile w przykładzie podstawowym podatność znajduje się w kodzie normalnie używanym w trakcie interakcji z użytkownikiem, w wersji zmodyfikowanej podatność ukrywa się w legacy code, który mógł być kiedyś wykorzystywany, ale wprowadzone zostały drobne zmiany i... Wciąż jednak można się do tej ścieżki wykonania dostać. Jak? To jest właśnie Wasze zadanie :) Powodzenia!

Tym razem nie chodzi o żaden przykład z bootcamp. Błąd, który trzeba zauważyć jest co prawda związany z bezpieczeństwem, jest(?) to podatność, ale ryzyko z nią związane jest nikłe. Błąd jest dość oczywisty, fragment kodu:

Pora na rozwinięcie poprzedniej wskazówki podanej we wpisie Bootcamp XVIII: Jak to może być zrobione. Chcę przede wszystkim podkreślić, że tego typu przypadki "występują w naturze", przy czym wykrycie ich nie jest trywialne.