Komentáře k článku
Aktuálně: Tak nám hackli GitHub…
Krátce poté, co zde vyšel seriál Jdu hacknout váš server, máme další článek na stejné téma. Tentokrát ale „žhavě aktuální“ o tom, jak jeden ruský programátor hacknul github (a poukázal na chybu v Rails, která se projevuje i na dalších serverech). A přitom stačilo, aby tým vývojářů Rails naslouchal…
Re: Aktuálně: Tak nám hackli GitHub...
pekne :D
GitHub
Zajímavé mi na tomhle přijde nezvládnutí ega vývojářů githubu. Možná se pletu, ale celé to na mě působí dojmem, že si vývojři řekli : „Přece nám tady nebude radit nějaký usmrkaný klučina s bezpečností“, protože jinak si neumim vysvětlit, že ten problém nechali dojít až do stavu commitovaní do hlavní větvě railsů…
Re: GitHub
Všeobecně je celá kauza nasáklá egoismem. O problému se střídavě mluvilo od roku 2007, a vyjádření Rails devs bylo „not a rails problem.“ Argumentovali tím, že je pak rails pro nováčky jednodušší.
Tohle opomenutí vedlo k tomu, že spousta „nováčků“ v githubu, posterous atp. imho vůbec netušilo, že vůbec nějaké attr_accessible je. A máme z toho takovouhle bombu.
Nedivím se, že to rails pushnul. Na jeho místě bych byl tak moc překvapen, že si nekontrolují oprávnění při ukládání SSH klíčů (!!), že bych to prostě prubnul. A vývojáři githubu, i když dostali několik reportů na tento konkrétní problém, si neprošli to nejzásadnější s tím, „že tam určitě problém nebude.“
Fix v rails je nakonec jen pro nové aplikace, a ještě k tomu jde vypnout jedním (!) řádkem v configu globálně. Trochu se obávám, že teď si spousta vývojářů své aplikace patchne, ale za pět let máme stejný problém – se službou, která bude tehdy trendy.
Re: GitHub
Ono kde co nese označení „not a rails problem“. Rails devs jsou z větší části banda idiotů, s kterejma se nedá absolutně mluvit.
Re: GitHub
Až tak útočný bych nebyl, ale (naivně) jsem si myslel, že vývojáři na jejich úrovni, už nebudou mít problém přiznat chybu, opravit ji a nebo se o ni normálně pobavit…
Re: GitHub
:-) no kdo to nezkusil, tak by asi tak utocny nebyl, to je fakt. a o jake urovni se bavime? kdyz si proctete na githubu nahlasene chyby a reakce na ne od rails vyvojaru, tak je to uz jasny. opravdu dobrych je mezi nima jen par.
Framework vs. aplikace
Pěkné :-)
Jak to vlastně funguje? Definuji ve frameworku formulář, kde vyjmenuji atributy a všechno kolem se udělá samo. Nebo na straně serveru přijímám vstup z libovolného formuláře (který si třeba napíšu sám, tudíž framework neví, jaké atributy tam chci mít) a na straně serveru jen nechám nasypat POST parametry do vlastností objektu?
V prvním případě je to chyba frameworku, protože mohl vědět, které atributy tam chci – v druhém případě je to chyba aplikace a framework je v tom nevinně, protože nemohl tušit, které atributy vývojář chce nastavit a které ne.
Re: Framework vs. aplikace
Celý problém je druhá varianta – vývojáři (většina devs –> nemyslím, že github má zrovna newbie programátory..) prostě vezmou celý POST a narvou ho do objektu. Konstrukce z jejich pohledu je taková, že mám:
- input name=“user[name]„
- input name=“user[surname]„
atp. No a pak když ho chci uložit, tak můžu použít právě ono hromadné přiřazení – a drtivá většina to tak skutečně dělá. Rails devs si toho byli vědomi ve chvíli, kdy funkci psali. Jsou dvě možnosti jak si aplikaci zabezpečit:
- attr_accessible – whitelist
- attr_restricted – blacklist
Funkce hromadného přiřazení se pak dívá do white/black listu a podle toho se chová. Nicméně základní problém, na který chtěl právě Homakov upozornit, je ten, že standartně není nastaveno ani jedno. Každý model je defaultně nezabezpečený s tím, „že si ho musíte zabezpečit sami.“
Což o to. Hlavně si to ale musíte pamatovat.
Ve chvíli, kdy funkci všichni používají (bez ohledu na fakt, jestli je k tomu určena či nikoli) k načítání dat z POSTu, pak musí být defaultní white/black list implementován s tím, že programátor MUSÍ vědět, co dělá, když její chování nastavuje. Tomu osobně říkám restricted-by-default. A to je to, co chtěl Homakov.
A nakonec věděl proč. Hoši z Githubu, Posterous, Scribd a jiných si své modely nezabezpečili. Pokud to neudělali oni – v případě githubu u software, jehož licence začíná na 5000 dolarech – kolik jiných rails devs má své aplikace zabezpečeno? Imho to bude tak do 10%.
Re: Framework vs. aplikace
Např. v Javě (JSP) jde udělat stejná věc, ale nemyslím si, že by to byla chyba – tohle je podle mého odpovědnost programátora aplikace. Programátor si přece může vyrobit DTOčko, do kterého půjdou nastavovat jen vybrané atributy, nebo je může nastavovat individuálně místo hromadně. Ale když místo toho zavolá funkci „nastav všechny atributy podle POST parametrů“, tak si framework myslí, že to je přesně to, co programátor chce. Je to přece stejné, jako když zavolám funkci/metodu na smazání entity – framework/jazyk/platforma, taky nemůže tušit, že mazat ve skutečnosti nechci a volám tu funkci omylem.
Další věc je, že aplikace nebývají často jen pouhým rozhraním k databázi a mají nějakou logiku – a součástí ní je třeba i to, kteří uživatelé/role mohou nastavovat které atributy kterým entitám. Některé atributy půjdou nastavovat třeba jen v určité hodiny, nebo při připojení z určité sítě nebo na základě jiných atributů (např. článku, který neprošel korekturou nepůjde nastavit stav na „vydáno“) atd. atd. Takže tam stejně nějaký „filtr“ vytvořený programátorem být musí. Je fajn, když tahle pravidla jdou vyjádřit deklarativně. Ale tak jako tak je to odpovědnost programátora. Přijde mi, že se spousta lidí nechalo unést tím, jak snadno se dá dělat software, aniž by četli dokumentaci nebo přemýšleli, co která funkce dělá – a takhle se jim to ošklivě vymstilo.
Re: Framework vs. aplikace
Mna to prekvapilo aj tak. Yii framework v PHP, cista kopia RoR touto chybou out-of-box netrpi. Plati tam jednoduche pravidlo – field bez validatora (aj prachobycjany „required“) nie je mozne nastavovat masivnym priradenim.
Scaffolder validacne pravidla pekne do modelov pripravi z definicie tabuliek. Formulare si musi programator postrazit sam. Developer sa tak od zaciatku uci dobrym navykom.
Maly priklad – z beznej tabulky, povedzme ‚articles‘ sa nastavia validacne pravidla ‚required‘ pre stlpce s NOT NULL. Stlpec s AUTO INCREMENT sa ale vynecha – nie je mozne z vonka zmenit ID entity. Jasne, takato jednoducha logika nezabrani priradit rolu ‚admin‘ ak ma ten field validator. To uz si musi postrazit logika aplikacie.
Re: Framework vs. aplikace
Protože Xue u toho přemejšlí. A taky sleduje ostatní frameworky (nejen PHP) a snaží se vyhnout jejich chybám. Asiat no :D
Re: Framework vs. aplikace
Přesně to mě napadlo, že tenhle problém elegantně řeší nějaký view model, který bude mapovat a bindovat jen ty property, které chci. Je to sice práce navíc, ale osobně se mi to u .net mvc mnohokrát oplatilo.
Re: Framework vs. aplikace
P.S. K čemu bude dobré, když whitelist/blacklist bude výchozí chování?
IMHO více méně k ničemu, protože tím akorát omezím aktualizace atributů, které se nikdy nemění – např. primárního klíče nebo okamžiku vytvoření entity. Ale co všechny ty ostatní atributy? U nich totiž nemůžeme zakázat aktualizace, protože někdy je upravovat potřebujeme – např. administrátor může měnit role jiných uživatelů a jejich e-maily, běžný uživatel může měnit svůj e-mail ale ne jiných uživatelů atd.
Může ten whitelist/blacklist být vázaný (alespoň) na role aktuálně přihlášeného uživatele? Pokud ne, tak je to na nic. Ne, tohle není řešení a stejně tam musí někde ta logika (kdo co může) být zapsaná.
Re: Framework vs. aplikace
Ale co všechny ty ostatní atributy? U nich totiž nemůžeme zakázat aktualizace, protože někdy je upravovat potřebujeme – např. administrátor může měnit role jiných uživatelů a jejich e-maily, běžný uživatel může měnit svůj e-mail ale ne jiných uživatelů atd.
No, to jistě. Ale od toho tam jsou role. :-) Např. ten administrátor. :-)
Re: Framework vs. aplikace
jj, to už jsem taky zjistil, více viz tehle komentář.
Re: Framework vs. aplikace
Good one :-)
OU SHIT
Kaju se, přesně tu samou chybu mám taky, shame on me…
Re: Aktuálně: Tak nám hackli GitHub...
prvý článok na zadrojáku ktorý som prečítal od začiatku do konca :P palec hore
Grails
Přesně stejná věc je i ve frameworku grails, akorát se to tam jmenuje jinak – attribut „.properties“.
dhh - controller
DHH k tématu poslal: https://gist.github.com/1975644
Celkem rozumím tomu, proč to řeší v controlleru a ne v modelu.
Reakce GitHub
Z pohledu IT člověka se reakce GitHubu může zdát dětinská, ale z pohledu marketingu a legislativy neměli moc na výběr. Evidentně dlouhou dobu bagatelizovali problém a najednu jim někdo ukázal, že problém existuje. V té chvíli musí provozovatel udělat dvě věci – chybu promptně opravit a ukonejšit laickou veřejnost, že nešlo o vážný problém. A to konejšení laické veřejnosti je právě to zablokování účtu dotyčného a ještě větši bagatelizování ve smyslu „i kdyby snad někdo tu díru použil, my na to přijdeme a zjednáme nápravu“. Znalý člověk si sice poklepe na čelo, že tady logika hapruje, ale akcionář a zákazník si bude myslet „jo, těm nic neunikne“. Nejde tedy ani tak o projev uraženého ega, jako o snahu udržet si zdroj peněz. No a nebo, a to je můj osobní názor, jde o kombinaci obojího.
Re: Reakce GitHub
Tohle funguje presne do okamziku, kdy sedi na strane zakaznika managor, kterej nicemu nerozumi a nesleduje ani co se deje. Ovsem az si (i ten blbej managor) precte (trebas) zdejsi clanek, tak vyhodnoti tohle chovani jako velmi neduveryhodne a da od podobnyho partnera ruce pryc.
Delat chyby, je totiz normalni, ale nepriznat je, je vetsi pruser nez ta najvetsi chyba. Driv nebo pozdejs se to totiz stejne provali a pak to nekdo nalezite rozmazne.
Re: Reakce GitHub
„Delat chyby, je totiz normalni, ale nepriznat je, je vetsi pruser nez ta najvetsi chyba“
Tesat do kamene. Z mého pohledu měli tu chybu opravit, zveřejnit na svém blogu, jak staré projekty aktualizovat.
Re: Reakce GitHub
Nemyslim si, ze by byl GitHub pouzivan z vetsi casti prave „laickou verejnosti“… Spis bych rekl, ze laik o GitHub nezavadi, popripade je procento takovych uzivatelu mrzce nizke.
Ametéři
Tak to jsou v GitHub docela améři, míchat vnitřní atributy a ty co dostanou z formuláře, to se v php nedoporučovalo už před sto lety, klasickej příklad byl vždycky nastavení user_id na adnimistrátora :D
Re: Ametéři
no, jo, je to o par let mladsi jazyk a chcou byt proti proudu, tak si musi hloupost svych „registerGlobals“ poznat sami, protoze zkusenosti jsou temer neprenosne…
Re: Ametéři
Ruby i PHP jsou pro verejnost z roku 1995, Ruby vyvoj zacal o rok drive nez php
Wiki
http://cs.wikipedia.org/wiki/Ruby_(programovac%C3%AD_jazyk)
„Práce na něm započaly v roce 1993, první verze byla uveřejněna v roce 1995 „
http://cs.wikipedia.org/wiki/PHP
„Vše začalo v roce 1994″
Re: Ametéři
Až na to že ten problém není v Ruby ale ve frameworku Ruby on Rails … a ten měl první release v roce 2004.
Re: Ametéři
To že RoR chybí nějaká vlastnost ještě neznemená, že to programátora nepraští do očí a něco si tam nedobastlí, aby to neměl děravé jak cedník, proto mne překvapuje, že to exprti na github ignorovali.
Re: Ametéři
Ono to ale není tak že by „RoR“ nějaká vlastnost chyběla. Možnost filtrovat fieldy které lze přes mass assignment modifikovat tam je (whitelisting i blacklisting), akorát je to holt v defaultu vypnuté protože RoR vývojáři razí myšlenku že to v defaultní instalaci má být použitelné i pro naprosté začátečníky a tímhle by se to komplikovalo …
Ano, máte pravdu že programátoři githubu (a dalšího asi milionu projektů které RoR používají) to měli změnit a nastavit. Současně to pěkně ilustruje že bezpečnostní princip „defaultně zakázat, povolit jen vyjmenované“ má svůj smysl.
Re: Ametéři
Z té myšlenky „že to v defaultní instalaci má být použitelné i pro naprosté začátečníky a tímhle by se to komplikovalo“ mě úplně jímá hrůza. Použitelnost pro naprosté začátečníky je skvělá věc, ale za žádných okolností to nesmí být na úkor bezpečnosti.
Proč by weby začátečníků měly být děravé? Protože jsou začátečníci? Právě naopak, začátečník se v bezpečnosti neorientuje a na framework spoléhá. Tímhle ho ale podvedl.
Re: Ametéři
konec dobrý, všechno dobré :)
Pochopili, změnili… osobně jsem rád, protože když jsem to při prozkoumávání RoR sám zjistil, tak jsem se tomuto přístupu hodně divil.
Sequel
Chapu spravne, ze clovek ktery vymyslel v sequelu metodu set_fields byl genius protoze vyvojare Railsu tohle nenapadlo pet let? ( http://sequel.rubyforge.org/rdoc/classes/Sequel/Model/InstanceMethods.html#method-i-set_fields )
Re: Sequel
Ne. Nechápete to dobře. Jak už tady bylo zmiňované několikrát – vývojáře Railsu to pochopitelně napadlo. Jde jen o defaultní chování a jejich preference.
Re: Sequel
Jde o to, ze narozdil od uvedeneho attr_protected muze tahle funkce mit pri kazdem volani jine parametry.
Ego je problem temer kazdeho kdo neco vytvori
zkratka „tak jak sem to udelal, je to nejlepsi a nikdo nema pravo mi do toho zvanit.“
3012
V rámci přesvědčování Rails dev týmu vytvořil issue I'm bender from future, který byl založen v roce 3012. Udělal to jednoduše – ve firebugu přidal <input type="hidden" name="created" /> a, ke svému vlastnímu překvapení, zjistil, že to funguje. Proof of concept zaslal Githubu v pátek, a GitHub chybu ihned opravil.Rok 3012?
Re: 3012
„homakov opened this issue in 1001 years“
Re: 3012
Ale pozitivní je, že počítali s tím, že někdo může zadat příspěvek v budoucnu – připraveni na všechno :-)
Zend Framework
Presne, ked som skusal rails (cca 3 r. dozadu) tak v niektorom zo screencastov na toto poukazovali, a odvtedy si pamatam tuto nebezpecnu dieru avsak rails som nechal tak a ostal pri PHP (nie preto).
V zende je to riesene cez formulare. Naplnim si formular parametrami a tie (ak je validny) vytiahnem. Pritom formular vrati iba tie parametre, ktore su v nom definovane (moznost nastavit filtre na hodnoty). Ak je vo formulari select tak pri zadani hodnoty ktora v nom nie je formular vrati chybu atd.
Re: Zend Framework
http://railscasts.com/episodes/26-hackers-love-mass-assignment
Re: Zend Framework
Ryan vydal „revised“ verzi … http://railscasts.com/episodes/26-hackers-love-mass-assignment-revised