Jednego nie potrafię zrozumieć - ostanie dziury w Railsach były znane na długo przed włamaniami.
Była zlewka na problem. Dopiero włamy na github a teraz na rubygems prowokują do patchowania.
Trochę mi łyso, gdy znajomy pythoniarz pisze mi - “Weź @$#nij te railsy, przecież ci goście są niepoważni. Chcesz robić solidne aplikacje na czymś takim?”
Masz jakieś pytanie / problem, chcesz się czeoś dowiedzieć, o czymś istotnym nam powiedzieć? Czy liczysz że zaraz będzie 100 postów broniących RoR i porównujących do PHP, Javy czy czego tam jeszcze innego?
Rubygems nie zostały shackowane wykorzystując dziurę w railsach, tylko fakt, że domyślnie parsowanie YAMLa nie jest bezpieczne, tzn. deserializacja może stworzyć obiekty rubiego inne niż podstawowe typy.
Co do reszty, to tak, bardzo słabe jest to jak YAML domyślnie działa, bo to było wektorem ataku dla wszystkich osatnio znalezionych dziur. Tylko różnego rodzaju dziury pozwalające na zdalne wykonywanie kodu były obecne w wielu innych językach i frameworkach. Tzn. że powinno się porzucić każdą technologią, w której znajdą jakąś dziurę?
Ten problem z YAMLem jest obecny także w pythonie: http://nedbatchelder.com/blog/201302/war_is_peace.html. Nie jest oczywiście nawet w małej części tak groźny jak to co się działo w railsach, bo w django czy innych frameworkach pythonowych YAML nie był wykorzystany tak jak w railsach, ale jeżeli istnieje serwis, który parsuje YAMLa i używa do tego load, a nie safe_load, tak jak rubygems (czy github pages, czy travis), to też będzie podatny.
[quote=drogus]Rubygems nie zostały shackowane wykorzystując dziurę w railsach, tylko fakt, że domyślnie parsowanie YAMLa nie jest bezpieczne, tzn. deserializacja może stworzyć obiekty rubiego inne niż podstawowe typy.
Co do reszty, to tak, bardzo słabe jest to jak YAML domyślnie działa, bo to było wektorem ataku dla wszystkich osatnio znalezionych dziur. Tylko różnego rodzaju dziury pozwalające na zdalne wykonywanie kodu były obecne w wielu innych językach i frameworkach. Tzn. że powinno się porzucić każdą technologią, w której znajdą jakąś dziurę?
Ten problem z YAMLem jest obecny także w pythonie: http://nedbatchelder.com/blog/201302/war_is_peace.html. Nie jest oczywiście nawet w małej części tak groźny jak to co się działo w railsach, bo w django czy innych frameworkach pythonowych YAML nie był wykorzystany tak jak w railsach, ale jeżeli istnieje serwis, który parsuje YAMLa i używa do tego load, a nie safe_load, tak jak rubygems (czy github pages, czy travis), to też będzie podatny.[/quote]
Nie chodzi mi o przypadek szczególny, ale o ogólną politykę bezpieczeństwa.
Tutaj analizujesz ten szczególny przypadek, ale wiesz, że bug który został wykorzystany do włamania i podmiany kluczy na githubie był zgłaszany wcześniej i nie były podjęte żadne kroki - do momentu w którym, z tego co pamiętam, zgłaszający tego buga nie wkurzył się i pragmatycznie nie udowodnił zastosowania takiej luki. Obiektywnie rzecz biorąc takie “strong parametrs” powinny być najpóźniej zaimplementowane w wersji 2.0 Railsów a nie 4.0. Ja w tej chwili bardzo negatywnie oceniam politykę bezpieczeństwa Railsów i w momencie,gdy ktoś zadaje pytanie, czy Railsy są “corpo ready” to nie odważę się odpowiedzieć “tak”.
Bo tak jak słusznie zauważyłeś, bugi zdarzają się wszędzie, ale ważna jest polityka bezpieczeństwa, czyli nie tylko sposób reagowania na zgłaszane błędy, ale i przywiązywanie większej wagi do zagadnień bezpieczeństwa aplikacji przy projektowaniu frameworku.
Jak postawić aplikację, typu SaaS, gdzie będę pobierać opłaty i mieć na głowie umowy i odpowiedzialność prawną, gdy na zgłaszane bugi w zasadzie jest brak reakcji. Bardzo cenię Railsy za wygodę i szybkość tworzenia aplikacji, ale martwię się takimi sprawami.
Masz lepsze przebicie w core team, może warto czasami podnieść takie tematy? To ostatnia IMO słabość Railsów, dzięki jruby wydajnościowo jest już nieźle, skalować też się da, teraz tylko poprawa bezpieczeństwa.
Wybierając wiele miesięcy temu framework do nauki miałem świadomość niedoskonałości Railsów, ale doszedłem do momentu, gdzie w zasadzie jestem w stanie już w tej chwili uruchomić 2-3 serwisy, zarobkowo, i sam nie wiem. Naprawdę nie wiem.
[quote=ichi]Nie chodzi mi o przypadek szczególny, ale o ogólną politykę bezpieczeństwa.
Tutaj analizujesz ten szczególny przypadek, ale wiesz, że bug który został wykorzystany do włamania i podmiany kluczy na githubie był zgłaszany wcześniej i nie były podjęte żadne kroki - do momentu w którym, z tego co pamiętam, zgłaszający tego buga nie wkurzył się i pragmatycznie nie udowodnił zastosowania takiej luki. Obiektywnie rzecz biorąc takie “strong parametrs” powinny być najpóźniej zaimplementowane w wersji 2.0 Railsów a nie 4.0. Ja w tej chwili bardzo negatywnie oceniam politykę bezpieczeństwa Railsów i w momencie,gdy ktoś zadaje pytanie, czy Railsy są “corpo ready” to nie odważę się odpowiedzieć “tak”.[/quote]
Brak strong parameters to nie jest bug, attr_accessible/attr_protected są z nami od bardzo dawna.
Gdzieś w 2007 roku przetoczyła się fala blog-postów przypominających o konieczności używania tych makr lub czegoś w zastępstwie.
to mocne słowa, na które nie dajesz argumentów. imo railsy często przodowały w featurach uszcelniających (filter parameters od zawsze /logi webowych apek bywają kopalnią diamentów/, rozróżnienie środowisk, csrf protection, safe buffer w 2.3.8 i inne, których akurat nie pamiętam).
[quote=ichi]To ostatnia IMO słabość Railsów, dzięki jruby wydajnościowo jest już nieźle, skalować też się da, teraz tylko poprawa bezpieczeństwa.
Wybierając wiele miesięcy temu framework do nauki miałem świadomość niedoskonałości Railsów, ale doszedłem do momentu, gdzie w zasadzie jestem w stanie już w tej chwili uruchomić 2-3 serwisy, zarobkowo, i sam nie wiem. Naprawdę nie wiem.[/quote]
Dramatyzujesz i wydaje mi się, że nie jesteś świadomy z ilu stron tak naprawdę można zaatakować serwis dostępny w internecie.
Przed frameworkiem masz vps (lub alternatywę, zazwyczaj parę usług), serwer http, serwer aplikacji, język, różnej jakości biblioteki w tym języku.
Istnieje całkiem duża szansa, że któryś element tego stacku masz w wersji znajdywalnej na http://www.cvedetails.com/product-search.php .
Ja się częściowo zgodzę jednak z kolegą który rozpoczął temat: w Railsach jest kilka decyzji które bardzo źle wpływają na bezpieczeństwo aplikacji, w szczególności to jak są przekazywane parametry z zapytania http prosto do modeli (mass assignment). Oczywiście strong parameters, czy inne implementacje (nawet najprostsze!) dodatkowego zabezpieczenia są jak najbardziej na miejscu. Ja nigdy z attr_protected/accessible nie czułem się pewnie. Niestety, jest to droga na skróty aby udało się napisać bloga w 15 minut.
Z drugiej strony, taką samą sytuację będziesz miał zawsze, gdy kod Twojej aplikacji jest ściśle powiązany z frameworkiem. Tak samo będzie w Django kiedy znajdzie się duża dziura bezpieczeństwa.
W każdym przypadku, kiedy wybiera się drogę na skróty, Twój kod będzie narażony na problemy związane z bibliotekami których używasz. Dlatego trzeba się zastanowić 2 razy nie tylko przy wyborze frameworka, ale przy tym w jaki sposób piszesz swoje klasy, i jakie (i czy warto) biblioteki dołączasz do aplikacji.
Kilka pytań które warto by sobie zadać:
- masz w aplikacji prosty file upload i download, bez robienia thumbnaili itd. Po co Ci carrierwave? Przecież właśna, lekka implementacja to w porywach 3 linijki kodu.
- masz do zrobienia formularz, po co Ci simple_form?
- masz do zrobienia wyszukiwanie po kategorii, po co Ci searchlogic?
- masz do zrobiania prostą autoryzację, po co Ci devise?
To rzucanie się na ‘gotowe’ implementacje jest przyczyną dużej ilości potencjalnych błędów. O ile Ty potrafisz pisać dobry kod, łatwiej się upewnić że on będzie bezpieczny niż kod bibliotek napisanych gdzieś kiedyś przez kogoś, których działania nawet do końca nie rozumiesz.
Za politykę bezpieczeństwa to odpowiada twórca aplikacji, a nie frameworka. To że Railsy domyślnie załatwiają (czy ułatwiają załatwić) za programistę sporo potencjalnych luk bezpieczeństwa (CSRF, wstrzyknięcie SQL) nie zwalnia od myślenia programisty.
Przypominam że Igor Homakov podmianę kluczy wykonał dzięki luce w kodzie Githuba, a nie samych Railsów. To że potem whitelistowanie zostało domyślnie włączone w Railsach 3.2 nic nie zmieniło w sytuacji Githuba, który jedzie na Rails 2.3.
Czy za “corpo ready” uważasz największy javowy framework, Spring, który domyślnie nie ma takich mechanizmów bezpieczeństwa jak Railsy? Zastanów się nad odpowiedzią, masz wybór pomiędzy pokazaniem nieznajomości innych frameworków a nieznajomością wymogów aplikacji enterprise-grade.
Za politykę bezpieczeństwa to odpowiada twórca aplikacji, a nie frameworka.[/quote]
Aplikacja będzie maksymalnie bezpieczna w takim stopniu, na jaki zezwoli użyte do tego celu narzędzie.
Argumenty typu - “a u was biją murzynów” są naprawdę słabe 
A dyskusję typu “co to znaczy corpo ready” też wolę uniknąć - wiadomo, że nie jesteś w stanie poznać doskonale wszystkich znaczących frameworków (+języków na którym bazują). Jeśli próbujesz zdyskredytować rozmówcę takim podejściem, to też chyba nie tędy droga.
Przyjmijmy dla uproszczenia - w moim pojęciu aplikacje wykraczające poza blog dla amatora-programisty, a aplikację o dużej strukturze gwarantującą na poziomie wewnętrznym języka/frameworka silną integrację mechanizmów bezpieczeństwa.
Takiej, żebym nie musiał się bać, że w środowisku wieloużytkownikowym, dostępnym dla każdego (Internet) wskutek włamu i odszkodowań z procesów powstałych w wyniku włamania do serwisu wykorzystujących znany a nie załatany bug spędzę resztę życia z komornikami na karku.
Nie załatany na poziomie twórców frameworku a nie moim, maintainera-twórcy aplikacji czy poprzez źle napisaną logikę aplikacji.
@hubertlepicki - zgadzam się z Tobą w 100%, pechowo dal moich 2 projektów z wyjątkiem simple_forms używam reszty i to z uzasadnieniem. Mało tego - narzekam na brak funkcjonalności i pewne rzeczy z czasem będę musiał dopisać samemu
Nie da się ukryć, że w przeciągu kilku ostatnich miesięcy mamy złą passę pt “Włamania na serwisy oparte o RoR i bugi ruby/rails”
I tak, chciałem sprowokować dyskusję, w której od bardziej doświadczonych w RoR osób dało by się wyciągnąć trochę informacji o sytuacji z ich punktu widzenia.
Co mi się częściowo udało zrobić
To, że mamy coraz więcej znalezionych dziur w railsach jest oznaką tego, że railsy rosną w siłę, i zaczyna się opłacać w ogóle sprawdzać railsy pod względem bezpieczeństwa.
Bzdura: „Rails security is omakase”. Robiąc analogię do systemów operacyjnych: jesteś w stanie mieć bezpieczny komp z win Xp, oraz dziurawy openBSD.
Fakt faktem, że istnieje coś takiego, jak domyślne bezpieczeństwo, ale poza nim trzeba również używać mózgu.
pijesz cały czas do githuba i rubygemsów – czy na prawdę nie rozumiesz, że żaden z tych błędów nie wynikał z bugów frameworka?
To, że ktoś nie używał attr_accessible to ultra fail – ja to robiłem od daawna, jeszcze zanim mieliśmy GH drama.
To, że mało kto zdawał sobie sprawę co tak naprawdę robi YAML.load (tu biję się w pierś – sam nie zastanawiałem się nad tym, ale podejżewam, że bym się zastanowił, gdybym pisał usługę, w której są tam deserializowane dane z zewnątrz), to również nie jest bug.
pokaż mi jeden znany, nie załatany bład związany z bezpieczeństwem railsów. Pics or didn’t happen.
@hubertlepicki – częsciowo się zgadzam. Z drugiej strony, gdy dopiero się uczysz, to mimo wszystko lepiej załóż, że Jose Valim lepiej napisał uwierzytelnianie, niż Ty. A Ryan Bates autoryzację, niż Ty (dołóż tu jeszcze parę ficzerów, które chcesz implementować).
Widziałem serwis w którym pewien całkiem nie początkujący programista z UK zostawił dziurę w postaci możliwości założenia sobie konta admina dzięki używaniu devise. CanCan natomiast jest dla mnie półśrodkiem. Wg. mnie, architektura aplikacji powinna już sama w sobie dbać o prawa dostępu użytkowników, przynajmniej na takim poziomie na jakim zapewnia to biblioteka Ryana. Przykład: jeśli użytkownik nie może tworzyć rekordów danego typu, nie powinien wywołać metody zapisującej obiekt do bazy bo takiej metody nie będize miał w zasięgu, a jeśli to zrobi, rzucony zostanie wyjątek. W dużej ilości przypadków, rozsądnie stosowane dziedziczenie w klasach odpowiadających za szkielet naszej aplikacji, sprawdza się świetnie. To jednak dygresja.
Zgadzam się z przedmówcami że RoR nie jest niczym szczególnym, w innych frameworkach też zdarzają się podobnie straszne dziury od czasu do czasu.
RoR jednak nie zachęca do myślenia o architekturze naszej aplikacji w innych kryteriach niż tabele z bazy danych, mapowane na obiekty, mapowane na formularze i zasoby REST. I to prowadzi do okropnego kodu (że przytoczę: http://devblog.avdi.org/2011/08/22/your-code-is-my-hell/) i problemów z bezpieczeństwem właśnie w taki sposób napisanych aplikacji.
Podsumowując: RoR w niczym moim zdaniem nie odbiega od innych frameworków, nie jest ‘mniej bezpieczny’. Łatwość strzelenia sobie w stopę jest jednak znaczna, trzeba po prostu wiedzieć co się robi.
Język Ruby nie przeszkadza w napisaniu w 100% bezpiecznej aplikacji webowej.
O nie, mój drogi, nie ma tak. Wprowadziłeś pojęcie “corpo ready”, powiedziałeś że Railsy nie spełniają tej definicji – to teraz powinieneś podać tę definicję i wykaz frameworków, które ją Twoim zdaniem spełniają. Albo to, albo odszczekujesz całą swoją wypowiedź o “corpo ready” jako rzucającą UndefinedBullshitException.
@ichi: tak na szybko, myslisz dziury railsów z dziurą w rubygems, która pozwalała na wykonanie dowolnego kodu poprzez domyślne zachowanie parsera YAMLa: Psych. To co było do załatania w railsach było załatane bardzo szybko.
Co do reszty, to tak jak przedmówcy napisali, strong parameters można używać już teraz. Oczywiście super by było gdyby tak jak piszesz to było już dostępne i rozpowszechniane od wersji 2.0, ale co zrobić, tak nie było i teraz będzie to zmienione.
Assembler pewnie też. Nie przekręcaj, rozmowy są o dziurach w Railsach nie Rubym.
Naucz się czytać ze zrozumieniem chłopie:
[quote=ichi]Przyjmijmy dla uproszczenia - w moim pojęciu aplikacje wykraczające poza blog dla amatora-programisty, a aplikację o dużej strukturze gwarantującą na poziomie wewnętrznym języka/frameworka silną integrację mechanizmów bezpieczeństwa.
Takiej, żebym nie musiał się bać, że w środowisku wieloużytkownikowym, dostępnym dla każdego (Internet) wskutek włamu i odszkodowań z procesów powstałych w wyniku włamania do serwisu wykorzystujących znany a nie załatany bug spędzę resztę życia z komornikami na karku.
Nie załatany na poziomie twórców frameworku a nie moim, maintainera-twórcy aplikacji czy poprzez źle napisaną logikę aplikacji.[/quote]
Poziom dyskusji z Tobą przestał mi odpowiadać. Przypisujesz mi słowa, których nigdzie nie napisałem, domagasz się definicji, które podałem i każesz podać listy frameworków, o których nigdzie tutaj nie pisałem w żadnym kontekście.
Nie śledzę na bieżąco bugtrackera czy wszystkich list developerskich. Powinienem, ale dopóki nie mam komercyjnych zobowiązań związanych z Railsami traktuję Railsy na poziomie nauki a nie security produkcyjnej aplikacji. Przynajmniej tak było do tej pory. Po wprowadzeniu updatu z 3.2.10 na 3.2.11 od razu została podniesiona sprawa niezałatanego buga w obsłudze json - ostatni o którym mi było wiadomo:
Warto przeczytać posty z ostatniego miesiąca:
gdzie przewija się ciągle:
These releases contain an important security fix. It is recommended that all users upgrade immediately.
Oczywiście, że błędy są w końcu łatane, czy napisałem gdziekolwiek, że jest inaczej? Pisałem jedynie o tym, że bugi są zgłaszane i trzeba czasami bardzo długo czekać na poprawki, najczęściej do momentu ich wykorzystania przez kogoś w niecnych celach.
@drogus- dzięki za wyjaśnienie mi pewnych niejasności i rozwianie wątpliwości + @hubertlepicki macie rację jeśli chodzi o podnoszenie spraw bezpieczeństwa aplikacji.
Temat jest o rubygems, a tam wykorzystano “dziurę” w Ruby, nie w Railsach. Myślę, że z tych nieścisłości wynika część flejmu powyżej.
Piszesz teraz o railsach? Czy o ruby? Czy rubygems?
[quote=ichi]Przyjmijmy dla uproszczenia - w moim pojęciu aplikacje wykraczające poza blog dla amatora-programisty, a aplikację o dużej strukturze gwarantującą na poziomie wewnętrznym języka/frameworka silną integrację mechanizmów bezpieczeństwa.
Takiej, żebym nie musiał się bać, że w środowisku wieloużytkownikowym, dostępnym dla każdego (Internet) wskutek włamu i odszkodowań z procesów powstałych w wyniku włamania do serwisu wykorzystujących znany a nie załatany bug spędzę resztę życia z komornikami na karku.[/quote]
Przestań liczyć na to, że ktoś zapewni ci bezpieczeństwo. Tutaj już nie chodzi o siermiężny bug YAMLa, railrów i to że “wolnotariusze” rubygems nie załatali krytycznego błędu w ciągu tygodnia. Dużo bardziej niebezpieczne jest przeświadczenie, że ktoś zapewni Ci kompletne bezpieczeństwo na poziomie wysokopoziomowego frameworka i “poważne” aplikacje Twoje i Twojego kumpla są bezpieczne. Jak rzucasz pojęcia typu “corpo ready” to sprawdź sobie ile jest 0dayi na jave, które pozwalają na, nie tyko wykonanie kodu na serwerze, ale i na komputerze klienta. Poczytaj o zhackowaniu głównego repo linuxa i krytycznym błędzie, który się pojawił bo komuś omsknęła się ręka i odkomentował kod. Sprawdź bazę exploitów, które możesz kupić za mniej niż 3K dolków. To nie jest problem railsów, czy jakiejkolwiek innej technologi. Im coś jest bardziej złożone, tym więcej ma dziur.
Chodzi mi też o to, że jak mówisz swojemu szefowi, czy klientowi, że twoja aplikacja jest na 100% bezpieczna, to wprowadzasz tego człowieka w błąd i powinieneś za to beknąć.
To nie dyskutuj, wystarczy kliknąć tutaj.
Próbuję Ci przede wszystkim pokazać że sam do końca nie wiesz o czym chcesz rozmawiać (ruby? rails? rubygems?), a Twoje zarzuty są niejasne, niezdefiniowane i fudziarskie.
Twoja definicja “corpo ready” jest zwyczajnie głupia: oczekujesz frameworka który zwolni Cię z myślenia o bezpieczeństwie. Nie ma takiego, a jeśli jakiś twierdzi że jest, to należy omijać szerokim łukiem.
Ale OK, skoro już podałeś definicję i wymagasz od frameworku żeby ją spełniał, to podrzuć chociaż jeden framework który odpowiada Twoim oczekiwaniom i który możesz nazwać “corpo ready” z czystym sumieniem. Jeśli takiego nie ma, to znów, Twoja definicja jako warunek użycia jest bezużyteczna.
Ja chętnie pogadam o ostatnich babolach znalezionych w rails czy rubygems, ale nie poniżej pewnego minimalnego poziomu. Chętnie pogadam czy domyślny whitelisting atrybutów to pomysł lepszy czy gorszy, jak powinna wyglądać ewaluacja yamli czy parsowanie jsona. Natomiast pierdololo “omg railsy są niebezpieczne bo magiczne / na ruby / bo używają yamla / bo bałbym się postawić w anonimowej korporacji” zamierzam bezlitośnie krytykować i punktować.
Jak projekt ma być corpo ready to ma dokładny audyt bezpieczeństwa, inaczej to jest guerrilla warfare ready :).
Dziury w railsach zostały załatane bardzo szybko. Jeśli nie pasuje Ci, że w ogóle jakieś były, to nikt Cię nie trzyma - wybierasz język/framework, który jest corpo ready (z ciekawości, który to?) lub piszesz od zera coś własnego (powodzenia ;).
Ćśśś, nie spojluj, kolega Ichi chyba jeszcze nie wie co to są audyty bezpieczeństwa.
Oraz że swojego pierwszego nigdy się nie przechodzi, niezależnie od frameworku.
Ja tylko dodam jeszcze, że nie należy oczywiście sprawy bagatelizować. Dziury były poważne, tak samo poważny jest sposób parsowanie YAMLa, więcej mądrych rzeczy napisał w temacie @patio11: http://www.kalzumeus.com/2013/01/31/what-the-rails-security-issue-means-for-your-startup/
Tzn. jedną rzeczą jest bronić tego, że railsy szybko radzą sobie z takimi dziurami, a drugą jest to, że te dziury były niesamowicie poważne, bo właściwie każda appka bez patcha jest podatna.
Swoją drogą, kawałek z posta na temat ostatnich kilku postów w temacie: