XSS Warning to rozszerzenie do Firefoxa chroniące użytkownika przed atakami XSS typu reflected. Projekt dopiero raczkuje, ale może być interesujący. Znacznie bardziej rozbudowane możliwości daje NoScript. Chociaż wymaga przynajmniej kilku dni oswajania się z nowym zachowaniem przeglądarki i odwiedzanych stron, to jednak zdecydowanie warto.
Ten weekend poświęciłem na szybki kurs Ruby on Rails. Zacząłem od Rolling with Ruby on Rails Revisited, który w bardzo przyjazny czytelnikowi sposób wprowadza w tematykę RoR. Niestety w drugiej części tego artykułu zatrzymałem się na dłuższą chwilę w miejscu, gdzie w przykładzie zablokowana zostaje użytkownikowi możliwość edycji daty wpisu. Usuwany jest formularz oraz nadawana domyślna wartość daty, ale… nikt nie zabrania użytkownikowi przesłać daty spreparowanym formularzem, lub chociażby telnetem. Autor nie wspomniał o tym, że aby faktycznie zablokować możliwość wprowadzenia własnych danych, należałoby dodać linię “attr_protected :date” w odpowiednim modelu.
Jest to problem bardzo podobny do sytuacji, gdy przy włączonej dyrektywie register_globals programista PHP używa zmiennej nie inicjując wcześniej jej wartości. O tym, że w Ruby on Rails jest to równie typowy błąd, mogą świadczyć na przykład luki w LoginGenerator i LoginSugar.
Inny często spotykany problem to podatność na CSRF - ten temat został prawie pominięty w dostępnych materiałach.
Dla programistów RoR polecam:
Ruby on Rails Security Blog
Opis luki w Rails<1.1.6
Securing your Rails application
CSRF Killer plugin
Na blogu Michała Ławickiego pojawił się krótki artykuł na temat szybkiego łatania SQL Injection przy pomocy mod_rewrite. Coraz częściej moduł ten jest wykorzystywany jako ubogi kuzyn mod_security. Rozwiązanie takie ma kilka zalet:
Oczywiście reguły mod_rewrite nie powinny stanowić ostatecznej wersji mechanizmu obrony przed SQL Injection - byłoby to rozwiązywanie problemu komunikacji aplikacji z bazą danych na poziomie przychodzących żądań HTTP, co najprawdopdobniej nie sprawdziłoby się na dłuższą metę. Obrona taka ogranicza się tylko do zmiennych GET, ponadto przy niewielkich zmianach logiki aplikacji potrzebne byłyby modyfikacje kilku jej warstw, co nie jest wygodne.
Pomysł jest jednak moim zdaniem dobry. Łatanie dziury wykrytej przez użytkownika lub programistę składa się zwykle z trzech etapów: szybkiej łatki, monitorowania ewentualnych prób ataków, oraz docelowego rozwiązania, uwzględniającego zebrane w drugim etapie dane. Pierwszy z tych kroków realizuje właśnie opisana regułka mod_rewrite.
Na stronach WASC można znaleźć statystyki podatności wykrytych przez zautomatyzowane narzędzia skanujące aplikacje internetowe w 2006 roku. Najczęściej spotykaną luką jest w tym zestawieniu Cross-Site Scripting - 100 tysięcy wykrytych na 26 tysiącach stron (ogółem testowano ponad 31 tysięcy stron).
Niestety statystyki nie są podzielone na źródła podatności (kolejne warstwy wykresu “Vulnerability Stack”), co moim zdaniem znacznie obniża ich wartość. Można przypuszczać, że większość błędów odkrytych przez wykorzystane narzędzia wiąże się z wykorzystaniem gotowych aplikacji (open-source lub komercyjnych). Mam też wrażenie, że w praktyce tego typu statystyki nie pokazują rzeczywistych ilości istniejących luk, ale stopień ich wykrywalności przez automatyczne skanery.
Tematyka ujawniania luk XSS w serwisach internetowych jest ostatnio dość popularna, i budzi czasem gorące emocje. Może warto przypomnieć o istnieniu Full Disclosure Policy?
The goal of following this policy, above all else, is education:
Education of the vendor to the problem (ISSUE, as defined below).
Education of the researcher on how the vendor intends to fix the problem, and what caveats might cause a solution to be delayed.
Education of the community of the problem, and hopefully a resolution.
With education, through continued communication between the researcher and software maintainer, it allows both parties to see where the other one is coming from. Coupled with compensation*, the experience is then beneficial to the researcher, vendor, and community. Win/win/win for everybody. :)(*Compensation is meant to include credit for discovery of the ISSUE, and perhaps in some cases, encouragement from the vendor to continue research, which might include product updates, premier technical subscriptions, etc. Monetary compensation, or any situation that could be misconstrued as extortion, is highly discouraged.)
W przypadku XSS można zastanawiać się również, w jakich warunkach publiczne ujawnienie luki jest uzasadnione. Serwisy internetowe nie muszą zazwyczaj informować publicznie o fakcie załatania luki, ponieważ cały proces aktualizacji odbywa się po stronie serwera, i nie wymaga podjęcia żadnych działań przez użytkowników. Ujawnienie jest zatem pomocne, jeżeli:
Zgodnie z RFP serwis powinien odpowiedzieć w ciągu 5 dni - w tym czasie zgłaszający i serwis mogą ustalić przybliżony termin załatania błędu. Dobrym pomysłem jest dokładne wyjaśnienie w zgłoszeniu przyczyn i skutków istnienia luki. Propozycje finansowe oczywiście nie mają z Full Disclosure Policy nic wspólnego, co zresztą jest podkreślone w zacytowanym powyżej fragmencie.
Czy Waszym zdaniem tego typu zasady mają sens w przypadku luk XSS?
