Dokazatelná bezpečnost

RobertM:

Záznam přednášky, který mě fakt potěšil. U vývoje nové verze svého FW totiž uvažuji podobným směrem a měl jsem pocit, že v uvažování tímto směrem jsem poměrně osamělý. A ono ejhle - v Google uvažují obdobně.
Za naprosto klíčovou větu považuji "Veškerý kód který máme, musí být kompilovaný." (ve smyslu našimi kompilátory, které si mohu nastavit). S tím 100% souhlas. A není jenom kvůli ochraně před XSS, ale těch důvodů je mnohem více. Já jim obecně říkám, že program má svému kódu rozumět a mít možnosti si jej zkontrolovat a optimalizovat. Jaké různé možnosti tam vidím? (Budu mluvit spíše o serverové straně, ale to není tak podstatné) Např.:
1. Přeložení scriptu s možností vytvořit body v kterých se zaloguje "program tudy prošel". Pokud na takto přeložený script aplikuji testy tak jsem schopen zjistit kudy všude testy prošly, případně doplnit testy tak, aby pokrývaly ty části kódu kudy zatím testy neprochází a docílit až "dokazatelného 100% pokrytí" testy.
2. Přeložení scriptu s možností vytvořit body v kterých se script zastaví a čeká na další příkaz (který přijde z jiného processu s kterým je nastavena komunikace). Tím jsem schopen vytvořit debuger toho kompilovaného scriptu.
3. Možnost přeložit program na základě nových vlastností jazyka, kvůli kterým by jinak program nikdo nepřepisoval. Např. array_map (v PHP) mohu přeložit jako array_map nebo jej vytvořit pomocí foreach, while atd... Pokud zjistím, že v nějaké nové verzi PHP je třeba překlad pomocí while rychlejší než foreach není problém to v kompilátoru změnit a v okmažiku nasazení nové verze PHP vše překompilovat.
atd...
S tím, že program musí vědět jestli je ve stringu prostý text či oescapovaný tj. HTML (a podle toho některé věci zakázat) samozřejmě naprostý souhlas. A to samozřejmě též vede k poznání, že je potřeba script kompilovat, protože v čistém (třeba PHP) nelze prostě některé konstrukce zakázat (třeba echo $JakakolivPromenna).
Nakonec bych se zastavil u příkladu s ošetřením SQL, kde jsme také ve shodě. Programátor chce samozřejmě zapsat "SELECT neco, neco FROM tabulka WHERE neco = $variable" protože je to pro něj velice intuitivní. Nicméně pro program je takovýto string zcela neprůhledný. Aby tomu rozuměl program tak je ideální, aby SQL dotaz byl napsán v nějaké array struktuře  (vnořované - subquery), kde je jasně určeno co jsou názvy polí a co hodnoty proměnných a podle toho se udělá escapovaní. Osobně to mám připraveno tak, že takovýto SQL string je v jiných uvozovkách a při překladu se přeloží jako ta array struktura. Na ní je pak možno aplikovat další podmínky atd... A zase, v okamžiku, kdy program zapsanému SQL "rozumí" je možno dělat různé kontroly (např. zda použité názvy sloupců existují, zda souhlasí typy), použité SQL funkce se stanou virtuálními a lze je přeložit (např. group_concat v případě přenosu z MySQL do MS SQL).
Nicméně jsou i věci kde plánuji trochu jiné řešení. Ten rozdílný pohled ideově vychází z toho, že vývojáře považuji "jen za uživatele systému" (s právy zapisovat do jiných tabulek) a scripty vyvíjené v tom vyšším jazyku nepovažuji za program, ale za data. Z toho pak vychází jiný přístup k celé koncepci vytváření programu. Vývojáři nemají principiálně přímý přístup do FS, ale scripty zapisují do db, z které se na základě datové události (obdoba trigeru v serverovém jazyku) přeloží do výkonného jazyka a zapíšou do FS. Tím mohu rozlišit, že různé skupiny vývojářů mají přístup k různým částem systému. Někdo může zapisovat jen stránky (šablony), někdo má možnost zapisovat serverovou logiku, jiný má právo psát třeba knihovny používané jako komponenty (gridy, edity, atd...) a někdo může zapisovat knihovny vytvářející různé konverzní funkce (např. zde zmiňované HTML escapování) a nejvyšší právo samozřejmě umožňuje měnit i scripty tabulek z nichž se generují knihovny kompilátoru. A kompilátor samozřejmě ví, které konstrukce jsou v které tabulce povoleny a dle toho buď přeloží nebo ne.

Jinak z širšího pohledu si myslím, že mnohé současné jazyky (např. PHP) jsou pro začínající vývojáře příliš komplexní (což je dáno i vývojem kterým prošly) a v praxi bude potřeba spíše "omezovat" než rozšiřovat. Myslím, že v budoucnu budou "jednoduché kompilátory" (s DSL zaměřenými na část vývojového procesu) vznikat mnohem víc než dnes. Tokenizace, parsing vytvoření stromu příkazů a převod do cílového jazyka není tak obtížná úloha, jak to dnes mnoha programátorům připadá. Do takového jazyka lze pak snadno přidat i spoustu "syntaktického cukru", který je pro používání jazyka přínosem a samozřejmě spoustu kontrol, které by dělat ručně bylo hodně problematické.

mario:

dakujem za prednasku, vnukol si mi jednu myslienku ako aplikovat dokazatelnu bezpecnost na svoj framework..