Narušení bezpečnosti GitHub a Ruby on Rails

Bezpečnost GitHub a projektů postavených nad Ruby on Rails byla narušena. Egor Homakov upozornil na vážné bezpečnostní problémy Ruby on Rails. Chyby prezentoval na projektu GitHub. Dělal si co se mu zachtělo. Zahlásil chybu z roku 3012 (I'm Bender from Future), dokázal smazat libovolný příspěvek, provádět změny v hlavní větvi, smazat celou historii projektu nebo přiřadit svůj veřejný klíč k libovolnému projektu. Více například na Posterous (také má problém). Vyjádření GitHub v oficiálním blogu.

5.3.2012 15:37 | Ladislav Hagara | Bezpečnostní upozornění

Komentáře

[Max]

Na rootu o tom vyšlo pěkné psaní : Aktuálně: Tak nám hackli GitHub...
Zdar Max

[Ladicek]

Myslím, že dělal si co se mu zachtělo zdaleka není adekvátní popis (a nic takového jako smazat celou historii projektu se nestalo). Ano, kdyby chtěl, mohl, ale nic fatálního neudělal.

[Lol Phirae]

Ano, kdyby chtěl, mohl

Hmmm, a wo to tady asi go, že...

[Ladicek]

To asi těžko. Nešlo o útočníka, který se chtěl zmocnit GitHubu, ale o vývojáře, jehož námitky vůči výchozí politice Railsů nikdo nebral vážně. Teď už je vážně berou, naštěstí.

[Lol Phirae]

Co asi těžko? Kdyby někdo chtěl, tak si skutečně mohl dělat, co uzná za vhodné. A mimochodem, nemyslím si, že by změna defaultních nastavení fakticky něco opravila.

[xkucf03]

To přece není chyba Railsů, ale té aplikace, ne?

[sidik]

Jo, "not a rails problem" byla přesně reakce Rails devs. No a nakonec se ukázalo, že to je problém Rails.

[xkucf03]

Viz co jsem psal na Rootu: 1, 2. Že nakonec ustoupili a opravili/upravili to, ještě neznamená, že to před tím nebyla chyba programátorů aplikace. Chovala se ta funkce podle dokumentace nebo ne?

[Lol Phirae]

Kdepak, je to marný, marný, marný. I vývojáři pochopili až poté, co jim dotyčný, který se opakovaně snažil marně vysvětlit, jak špatné jsou defaultní hodnoty, prostě předvedl tu jejich nádheru v praxi.

[xkucf03]

Možná jsem něco špatně pochopil, v tom případě budu rád, když mne někdo opraví, ale: 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á.

[Lol Phirae]

K čemu bude dobré, když whitelist/blacklist bude výchozí chování?

Třeba to pochopíte tady.

[xkucf03]

Ano, to jsem četl, ale neodpovídá to na moji otázku.

Tak tedy znovu: když dám např. atribut uživatelská_role na blacklist (resp. nedám na whitelist), tak ani administrátor nebude moci měnit role uživatelů, což právě potřebujeme. A když tenhle atribut na blacklist nedáme (resp. dáme na whitelist), bude moci administrátor moci měnit role, ale uživatel taky (za předpokladu, že může měnit tu entitu jako takovou – což předpokládám že může, protože si např. může změnit jméno, příjmení, e-mail atd.).

[Ladicek]

Kdyby ses podíval na dokumentaci, zjistil bys, že právě podle role to omezit jde.

[xkucf03]

OK, tak to je fajn Nicméně stejně je to málo

1. Role nejsou všechno, může záležet na hodnotách jiných atributů, vztahu mezi uživatelem a entitou (např. vlastnictví), ročním období, úplňku atd.
2. „Mass-assignment will only set attributes in this list, to assign to the rest of attributes you can use direct writer methods.“ – takže taková definice oprávnění stejně není neprůstřelná – když už, tak by se mi líbilo, aby to fungovalo jako v SQL databázích – když nemá uživatel příslušný GRANT, tak tabulku prostě nezmění, ani kdyby se stavěl na hlavu. Na jednu stranu ty a ostatní chcete, aby framework bránil programátorovi dělat chyby, ale on mu stejně nebrání – přitom by to bylo celkem fajn, kdyby šlo takhle deklarativně stanovit, kdo co může a tahle pravidla nešla překročit (ani tím, že programátor třeba poplete nějaké podmínky v ifu a zavolá omylem nějaký setter). Přijde mi to jako polovičaté řešení.
3. Stále to nic nemění na tom, že programátor zavolal funkci „nastav všechny atributy podle POST parametrů“ a pak se diví, že framework skutečně nastavil všechny hodnoty podle POST parametrů – přestože v dokumentaci je to chování popsané a o této vlastnosti (něříkal bych tomu chyba) se ví zhruba od 2007/2008.
4. Přijde mi to, jako kdyby autor aplikace napsal SQL: DELETE FROM tabulka; a pak se divil, že databázový systém skutečně smazal všechny záznamy v dané tabulce.

[Lol Phirae]

The perfect is the enemy of the good.

Jinak, předpokládám, že takový megaprojekt, jako je GitHub, asi nepíše a neadminuje banda amatérů. Pokud se tohle stane jim, jakpak "bezpečné" jsou asi další projekty postavené na RoR? "Favoring convention over configuration" - fakt? Asi to chce nad těmi defaultními nastaveními v generovaném kódu příště trochu víc přemýšlet.

[Ladicek]

Je to obecně vzato málo, ale ve spoustě případů je to dost. Já souhlasím, že The ACL is dead a deklarativní programování je pitomost, na druhou stranu výchozí chování musí být rozumné, tedy musí brát ohled na reálný svět. Mimochodem, před pár lety byla podobná aféra kolem Spring MVC

[xkucf03]

Takže abych to shrnul. Ve Springu bezpečnostní chyba není (alespoň co je mi známo). Chyba ale může vzniknout při jeho neopatrném používání. Doufám že se zítra nedočtu, že je závažná chyba v Oraclu. Doslechl jsem se, že umožňuje zavolat DROP SCHEMA a to může mít závažné následky na integritu dat.

Souhlas

[Ladicek]

Ta srovnání s SQL jsou nesmyslná. Kdyby nějaký databázový framework ve výchozím nastavení prováděl DROP SCHEMA někde pod třemi vrstvami abstrakce, byl by to průser. Když si to uživatel zavolá sám, je to úplně něco jiného.

[Tom]

Existuje o tom, že ACL is dead, někde něco psaného na netu (ne video)?

[Ladicek]

To nic, to je jenom Zed So Fucking Awesome Shaw, nic důležitýho

[Ladicek]

Že ve výchozím stavu generují nebezpečný kód a vymlouvají se na komplikace pro začátečníky je chyba Railsů a nikoho jiného.

[trekker.dk]

projektů postavených nad Ruby on Rails byla narušena.

Chybí mi tam některých projektů.

Kdejaký tutorial k Rails popisuje, že v definici modelu má být nastaveno attr_accessible, jinak hrozí přesně to, na co upozornil Homakov. Tzn. pokud ty "projekty" píše někdo, kdo si přečetl a pochopil aspoň nějaký tutorial (zjevně není případ programátorů GitHubu), tak se ho tahle záležitost vůbec netýká.

[Lol Phirae]

Hmm, a opravdu se domníváš, že defaultní nastavení by měla fungovat tak, že si tak každý bude dělat, co chce? Jinými slovy, např. když nainstaluješ defaultní Apache, tak by každý hejhula měl přes internet optimálně dostat práva roota?

[trekker.dk]

Špatný příklad (překvapivě).

Defaultní Rails aplikace není nastavená tak, že si tam může každý dělat co chce. Do takového stavu to dostanou až špatní programátoři, kteří nevědí, co dělají.

[Lol Phirae]

Pokud něco nenastavím, tak předpokládám, že defaultní hodnota je tzv. "sane". Takže ano, defaultně je nastavená tak, že to potom dopadne takhle.

PHP si tím prošlo holt dřív, ale vývojáři Ruby si toho asi nevšimli, takže tu katastrofu bylo nutné zopakovat.

https://github.com/rails/rails/issues/3453 https://github.com/rails/rails/pull/3952 https://github.com/rails/rails/pull/4062 https://github.com/rails/rails/issues/5228

A propos, ta zoufalost je známa od roku 2007.

[trekker.dk]

Pokud něco nenastavím, tak předpokládám

No a to je ten problém. Dokud předpokládáš, nemůžeš se divit, když něco uděláš blbě. Pokud chceš pracovat s nějakým frameworkem, měl bys vědět

[Lol Phirae]

Ufff. Jistě. Takže když bude nějaký firewall defaultně mít ACCEPT na všechny příchozí pakety, tak to taky bude čupr bezva featura, a každý, kdo předpokládá opak, je totální blbec.

[xkucf03]

Ale vždyť takhle to je. Ve výchozím stavu se přijímají všechna spojení a to i když máš v systému iptables – až když si nastavíš příslušná pravidla (typicky: zahazovat všechno a přijímat jen vybrané), tak to začne fungovat. Ale hlavně: když programátor řekne: „naplň všechny atributy objektu“ tak co to proboha má udělat jiného než naplnit všechny atributy objektu??

[Lol Phirae]

Ve výchozím stavu se přijímají všechna spojení a to i když máš v systému iptables – až když si nastavíš příslušná pravidla

Ne, to je fakt marné. Víte, v normální distribuci jsou nastavená rozumná defaultní pravidla pro ten firewall, ať už se k tomu používá ufw, shorewall, firestarter nebo cokoliv dalšího. Ano, samotné iptables nedělají nic, to by opravdu blbej neřek.

Ale hlavně: když programátor řekne: „naplň všechny atributy objektu“ tak co to proboha má udělat jiného než naplnit všechny atributy objektu??

Ale hlavně vidím, že jste ani po celodenní debatě nepochopil podstatu problému, on programátor nic takového neříká, on si to dokonce ani většinou nepřeje. Akorát to holt bylo defaultně debilně nastaveno a nic ho nenutilo to nastavovat jinak.

[xkucf03]

Ne, pořád jsem to nepochopil. Když programátor v RoR napíše:

nějakýObjekt.update_attributes(…)

tak co od toho čeká? Že to nastaví všechny atributy objektu nebo jen některé?

[Ladicek]

Když programátor v RoR napíše

A když scaffold generátor v RoR napíše?

[xkucf03]

Hmm, tak jsem si RoR nainstaloval ještě jsem se tím neprokousal, tak zatím jen teoreticky: vytvořím si nějaký model a generátor mi k tomu udělá formuláře a kód pro zpracování odpovědí z těchto formulářů. V této fázi jsou ve formuláři všechny atributy a všechny může uživatel měnit, je to tak?

Pokud ano, tak v další fázi si třeba programátor řekne, že některé atributy měnit nepůjdou a smaže je z HTML formuláře. Vážně si někdo myslí, že když ve formuláři to pole nebude, že nepůjde poslat ten původní POST, ve kterém bylo?

[Heron]

Jsem na tom podobně jako Franta. Podotýkám, že nejsem programátor v ROR, ale jestliže programátor opravdu použil fci na předání všech parametrů, tak se potom opravdu nemůže divit, že to předalo všechny parametry. A jestli je to zabezpečení dokonce i v tutoriálu, tak už je to jednoznačně chyba na straně programátorů. Nebo ta fce dle dokumentace nemá předávat všechny parametry?

K tomu FW. Tohle má každá krabička jinak (například RouterOS má default policy na ACCEPT a ve výchozím nastavení, nebo při prázdné konfiguraci filtru to opravdu vše propustí). Je věcí administrátora, aby to nastavil. K těm "rozumným defaultním pravidlům" v distribucích. Ehm, pokaždé se do nich musí sáhnout. Pokaždé. Abych to shrnul, do každé krabičky a do každého fw se musí sáhnout bez ohledu na jeho výchozí nastavení a to konečné nastavení je tak zcela v režii administrátora.

Nevím, jak předchozí odstavec pasuje na ruby, možná by to chtělo výchozí hodnoty nastavit tak, aby (pokud je to opravdu takový problém a ani tutorial nestačí) do toho musel pokaždé (tj při každém použití té fce explicitně definovat co předat) programátor sáhnout.

[xkucf03]

Nevím, jak předchozí odstavec pasuje na ruby, možná by to chtělo výchozí hodnoty nastavit tak, aby (pokud je to opravdu takový problém a ani tutorial nestačí) do toho musel pokaždé (tj při každém použití té fce explicitně definovat co předat) programátor sáhnout.

Pokud chce nastavit jen něco, tak může napsat kód ve smyslu:

nějakýObjekt.setA(požadavek.getParameter("A"));
nějakýObjekt.setB(požadavek.getParameter("B"));
nějakýObjekt.setC(požadavek.getParameter("C"));

Nebo použít nějaký filtr na původní sadu parametrů a filtrovaný výsledek nastavit hromadnou funkcí. Nebo použít whitelist/blacklist na úrovni objektu. Ale když nic z toho neudělá, tak mi přijde celkem přirozené, že se nastaví vše, kde se podaří spárovat jména atributů a parametrů.

Už na začátku jsem se ptal, jestli programátor definuje ve frameworku formulář a framework všechno ostatní vygeneruje, nebo jestli si to píše ručně (tudíž tu není nějaká pevná vazba mezi formulářem a kódem, který ho přijímá a framework tudíž nemůže vědět, jaké parametry tam programátor chtěl a jaké ne) a nějaký rubista mi na to napsal, že je to ta druhá varianta. Kdyby to byla ta první, tak ano, to bych bral jako chybu frameworku, protože ten mohl vědět, která políčka jsou ve formuláři a ostatní POST parametry (podstrčené útočníkem) zahodit.

[Heron]

může napsat kód ve smyslu

Tak to je jasné a o tom tamhle debata asi není. Jak tak čtu ostatní komentáře, tak mi to tak trochu připadá jako kdyby programátor chtěl použít jednořádkovou (protože je líný to vyjmenovávat, stejně jako klasická SQL "chyba" SELECT *) fci: "naplň všechno co můžeš, ale udělej to v dané situaci rozumně a bezpečně". Což je už požadavek na umělou inteligenci.

[trekker.dk]

Každý, kdo o firewallu předpokládá cokoliv místo toho, aby se podíval (ať už na ten firewall nebo do dokumentace), je totální blbec. A totéž platí o dalších podobných předpokladech.

[little.owl]

Nesmysl.

Chcete mi treba rici ze si mam nastudovat default SELinux policy a pak si napsat vlastni?

Vy popirate princip restrictive-by-default a to je u systemu pracujicich v nebezpecnem prostredi pristup, ktery se vymsti.

Cilem podobnych frameworku je moznost jednoduse napsat aplikaci s nutnosti minimalniho kodovani s ohledem na vyzadovanou funkcionalitu a zaroven abstrahovat nektere komplexni technologie. Pokud bude uzivatel nucen opakovane pridavat zbytecny kod v pripade nejcasteji uzivaneho scenare a studovat detaily implementace, aby neudelal snadno kritickou chybu, stoji framework za velke kulovi, protoze tu chybu v realnem svete drice ci pozdeji nekdo udela.

[trekker.dk]

Jestli se spoléháš na to, že máš zabezpečený systém, protože někdo někde udělal nějaký default, tak si koleduješ o malér.

protoze tu chybu v realnem svete drice ci pozdeji nekdo udela.

... a bude to jenom jeho chyba

[little.owl]

Nesmysl. Defaultni nastaveni musi maximalne restriktivni. Pokud toto zasadni pravidlo bezpecnosti systemu v Rails nerespektuji, je treba se jich vyvarovat, protoze drive ci pozdeji se i zkuseny developer popali - malokdo muze sledovat vsechny implementacni detaily stale meniciho se frameworku.

[Lol Phirae]

Nesmysl. Defaultni nastaveni musi maximalne restriktivni. Pokud toto zasadni pravidlo bezpecnosti systemu v Rails nerespektuji, je treba se jich vyvarovat

Bohužel, asi bude lépe se jim skutečně vyhnout. Toto je totiž jejich představě o opravě toho průseru. Whitelist all attribute assignment by default. Juch!

[xkucf03]

V tom případě bych doporučoval se vyhnout všem programovacím jazykům – např. v Javě můžeš udělat:

Collections.copy(cíl, zdroj);

A ti sprosťáci dokonce do dokumentace napsali:

Copies all of the elements from one list into another.

Přitom by jeden čekal, že ta metoda zkopíruje jen některé položky, nebo spadne, že?

[Lol Phirae]

Před Javou netřeba varovat, vyhýbám se jako upír česneku a stříbrným kulkám.

Jinak, komentoval jsem o kus níž (viz :without_protection), tohle se tam IIRC obojí dostalo současně ve verzi 3.1, přijde mi to tak nějak jako "uff, furt nás někdo prudí z bezpečností, tak tam dáme config.active_record.whitelist_attributes, no ale radši to defaultně zakomentujeme a kdyby to snad někdy někdo nedejbože odkomentoval, tak tam přihodíme :without_protection, aby to ten BFU nemusel moc studovat a moh to rychle vypnout. Hmmmm.

[little.owl]

Tady se nebavime o programovacim jazyku a jeho standardnich knihovnach, to je uplne jina rovina a Ruby je zde vicemene OK.

Tady jde o high level framework, ktery muze byt komplexnejsi nez jazyk sam a ktery je cilene designovan pro vyvoj webovych stranek bez nutnosti znat vsechny implementacni detaily a technologie pouzite uvnitr frameworku.

[Ladicek]

No, je to o dost lepší, to whitelistování je aspoň ve výchozím stavu zapnuté, a když to člověk v té třídě uvidí (a vlézt do ní musí, bez editace toho "modelu" se nedá udělat ani obligátní blog v 15 minutách), tak ho to aspoň trkne. Kompletně tu hromadnou aktualizaci vypnout snad nechce nikdo

[Lol Phirae]

Ale tak jistě lepší, než drátem do voka Jen fakt nevím, jestli nutně potřebujeme, aby tady bylo něco, v čem každej BFU udělá "blog za 15 minut". Hmmmm

[Jendа]

S Rails jsem nikdy nedělal, ale nešlo by to připodobnit SQL injection v PHP? To je taky „defaultní chování“, které to nějak „magicky“ neošetřilo.

[l4m4]

Chování PHP při použití parameterizovaných dotazů, což je dnes normou, je v pořádku. Toto není hodnocení PHP, ale pouze toho přirovnání...

[little.owl]

To ze jsou v SW chyby je celkem normalni, ale reakce vyvojaru je naprosto zoufala. Ta chyba - zde bez diskuze - je znama pet let, za tenhle back door je snad neko platil, jinak to nelze ani rozumne vysvetlit. Lepsi se drzet od Rails dale.

[HFechs]

Nejsem na railsy žádný odborník, napsal jsem v nich pár webů, ale už s prvním sem se pídil po tom, jak tam ten blacklist udělat. Takže je to chyba převážně vývojářů. Že mohl být backlist defaultní je jiná věc (já jsem pro) - zabránilo by to lamerům programovat, ale tohle není nějaká ukrytá zrada (prostě nějaké přetečení zásobníku, nějaké neošetřeňí či podobná klasická díra), ale dokumentovaná vlastnost a programator, kteremu není divné, že se do formuláře uloží všechno, i když nezadal které sloupečky, nebo že mu nedocvakne, že si do POSTu jde sloupeček přidat je minimálně dost nedůvtipný.

[HFechs]

A v méně "inteligetních" řešeních si to přece všechno musí ošetrit sám - to je pak ten systém taky "zabugovaný"? Jó pokud někdo moc spolehá na framework, tak si nabije tlamu....

[little.owl]

zabránilo by to lamerům programovat,

Kazdy dela chyby, clovek se zkusenostma mene (nebot jich uz ma za sebou plno).

Tady jde o to, ze tvurci Rails nerespektuji princip restrive-by-default a to je z hlediska bezpecnosti cesta do pekla.

[little.owl]

restrictive-by-default

[Lol Phirae]

Já jim fakt nerozumím. Viz ten whitelist patch, který jsem komentoval nahoře. Vidím přesně, jak to dopadne.

> Heleee, Frantooo, vono to s tou patchnutou verzí nějak nefunguje, co s tím?

>> Ahaa, ukáž... hmmm, divný, no zkus to takhle:

Model.new(params[:model], :without_protection => true)

> Jeeee, supeeer, už to fičí, dík!

Proč tam někdo takovéhle pakárny implementuje, jde fakt mimo mě. Opravdu by byl takový problém, kdyby programátor musel "zvednout zadek" a udělat tohle?

class Model < ActiveRecord::Base
  attr_accessible :foo, :bar, :baz, :as => :admin
  attr_accessible :foo, :as => :bfu
end

...

Model.new(params[:model], :as => :bfu)

[little.owl]

Nevim, muze je palit otazka zpetne kompatibility a proto nechteji byt radikalni, ale nedokazi to posoudit neb Rails nepouzivam.

[Lol Phirae]

Já už taky moc ne. A vůbec, už mi tak nějak všechny ty webové aplikace lezou krkem. Je tady vůbec něco rozumného, v čem se to dá dělat? PHP už nemůžu ani vidět, Ruby teda taky nic moc, na Javu ani s třímetrovou tyčí, hmmm, babo raď.

[Käyttäjä 11133]

Perl :D

[Lol Phirae]

Dík!

$ perl -le'/(??{s!!!})/'
Neoprávněný přístup do paměti (SIGSEGV)

[little.owl]

perl -le'/(??{s!!!})/'
Segmentation fault (core dumped)

Tak, tak, to je zname!

[petr_p]

Ano, je to známé:

Because perl's regex engine is not currently re-entrant, delayed code may not invoke the regex engine either directly with "m//" or "s///"), or indirectly with functions such as "split".

[little.owl]

Webarinu nedelam, pracuji na RTOS a embedded systemech, ale obcas neco ulipu v Djangu - treba rozhrani pro SAT-based testovani - nastesti to neni vystavene ven.

[Lol Phirae]

nastesti to neni vystavene ven.

Potřebuju nějakej monitor se stěračem, dnes už utírám potřetí!

[little.owl]

Budiz vam prano.

[Radek Miček]

Co třeba Ocsigen nebo Yesod?

[Ladicek]

To už radši Opa.

[Radek Miček]

Osobně preferuji OCaml, neboť má lepší systém modulů a lze tam používat camlp4.

[little.owl]

+1

[Ladicek]

Osobně preferuji méně obskurní jazyky, mimo jiné i proto, že chybová hlášení z programů psaných programy, které jsou napsané jinými programy, jsou zoufale nepoužitelná.

[xkucf03]

Náhodou, takové pěkné chyby, člověk si i počte

        at GregorSamsa.applyTemplates()
        at GregorSamsa.applyTemplates()
        at GregorSamsa.http$colon$$slash$$slash$www$dot$w3$dot$org$slash$1999$slash$xhtml$colon$template$dot$11()
        at GregorSamsa.applyTemplates()
        at GregorSamsa.applyTemplates()
        at GregorSamsa.http$colon$$slash$$slash$www$dot$w3$dot$org$slash$1999$slash$xhtml$colon$template$dot$11()
        at GregorSamsa.applyTemplates()
        at GregorSamsa.applyTemplates()
        at GregorSamsa.http$colon$$slash$$slash$www$dot$w3$dot$org$slash$1999$slash$xhtml$colon$template$dot$11()
        at GregorSamsa.applyTemplates()
        at GregorSamsa.applyTemplates()
        at GregorSamsa.http$colon$$slash$$slash$www$dot$w3$dot$org$slash$1999$slash$xhtml$colon$template$dot$11()
        at GregorSamsa.applyTemplates()
        at GregorSamsa.applyTemplates()
        at GregorSamsa.http$colon$$slash$$slash$www$dot$w3$dot$org$slash$1999$slash$xhtml$colon$template$dot$11()
        at GregorSamsa.applyTemplates()
        at GregorSamsa.applyTemplates()
        at GregorSamsa.http$colon$$slash$$slash$www$dot$w3$dot$org$slash$1999$slash$xhtml$colon$template$dot$11()
        at GregorSamsa.applyTemplates()
        at GregorSamsa.applyTemplates()
        at GregorSamsa.http$colon$$slash$$slash$www$dot$w3$dot$org$slash$1999$slash$xhtml$colon$template$dot$11()
        at GregorSamsa.applyTemplates()
        at GregorSamsa.applyTemplates()
        at GregorSamsa.http$colon$$slash$$slash$www$dot$w3$dot$org$slash$1999$slash$xhtml$colon$template$dot$11()
        at GregorSamsa.applyTemplates()
        at GregorSamsa.applyTemplates()
        at GregorSamsa.http$colon$$slash$$slash$www$dot$w3$dot$org$slash$1999$slash$xhtml$colon$template$dot$11()
        at GregorSamsa.applyTemplates()
        at GregorSamsa.applyTemplates()
        at GregorSamsa.http$colon$$slash$$slash$www$dot$w3$dot$org$slash$1999$slash$xhtml$colon$template$dot$11()
        at GregorSamsa.applyTemplates()
        at GregorSamsa.applyTemplates()
        at GregorSamsa.http$colon$$slash$$slash$www$dot$w3$dot$org$slash$1999$slash$xhtml$colon$template$dot$11()
        at GregorSamsa.applyTemplates()
        at GregorSamsa.applyTemplates()
        at GregorSamsa.http$colon$$slash$$slash$www$dot$w3$dot$org$slash$1999$slash$xhtml$colon$template$dot$11()
        at GregorSamsa.applyTemplates()
        at GregorSamsa.applyTemplates()
        at GregorSamsa.http$colon$$slash$$slash$www$dot$w3$dot$org$slash$1999$slash$xhtml$colon$template$dot$11()
        at GregorSamsa.applyTemplates()
        at GregorSamsa.applyTemplates()
        at GregorSamsa.http$colon$$slash$$slash$www$dot$w3$dot$org$slash$1999$slash$xhtml$colon$template$dot$11()
        at GregorSamsa.applyTemplates()
        at GregorSamsa.applyTemplates()
|#]

[Lol Phirae]

To vypadá opravdu drsně. To je asi nadlouho, anžto ani jeden z jazyků mi nic neříká, nicméně ten ocsigen server určitě někde pokusně zkusím zprovoznit, koukám, že v Debianu je balíček, tak by snad pod Mintem neměl být problém.

[xkucf03]

To mi přijde ještě víc matoucí – jestliže vývojář v tomto jazyce/frameworku nečte* dokumentaci, tak se koukne na tenhle kód a má pocit, že je to zabezpečené – a pak někde nastaví nějaké atributy individuálně, bude si myslet, že se to neprovede (vždyť přece definoval, že daná role nemá práva měnit tenhle atribut) nebo že to vyhodí bezpečnostní výjimku, ale nic z toho se nestane a projde to, protože tahle oprávnění fungují jen při hromadném nastavování. Prostě falešný pocit bezpečí.

*) kdyby ji četl, tak by věděl, aplikace touhle chybou netrpěly a celé tahle aféra by se nekonala