Microsoft neumí zabezpečit web servery... Mají díru v Azure AppService.

Fis

...

Ach jo. Docela mě mrzí, že vaše povědomí o bezpečnosti je takové jaké je. Jen doufám, že neprovozujete žádné webové služby. Nebo aspoň takové, kde byste mohl svým zákazníkům spíše uškodit. Nebo s tímhle přístupem raději žádné.

Jediný z celé diskuse, na koho mi tohle tvrzení sedí, jste vy. A začalo to hned prvním příspěvkem, který je podle mého názoru jen komentářovým spamem – bombastický titulek, a pak nic, žádný dotaz ani doložené tvrzení, jenom odkaz na vlastní blog. Asi ten blog nikoho nezajímá, tak je potřeba přivést nějaké návštěvníky, které zajímá, co je to zase za nesmysl, že?

Podle vás jsem měl obsah sdělení přepsat sem?

Primárním účelem bylo varovat všechny, kdo
a) chce provozovat v Azure aplikaci na App Service, aby věděli, že pokud si nezabezpečí svoji aplikací tím, že ji napíšou správně (a věřte, že to nejde a vždy se najde nějaká chyba), aby si by byli vědomi toho, že pomocí téhle zranitelnosti budou útočníci schopni v rámci daného oprávnění IIS udělat úplně všechno. Vykrást databázi, bezpečnostní klíče i vlastní  kód aplikace. A bohužel, mnohem hůře, vydeployovat si svou aplikaci a např. phishovat hesla.
b) použili nějakou službu, klidně Azure, přesně jak říkáte, pouze výpočetní výkon a tam si nakonfigurovali vše podle potřeby.
c) upozornit na to, jak Microsoft reaguje na oznámení o bezpečnostních hrozbách. Což už ostatně udělal nedavno Google a bylo z toho docela haló.
s mým blogem to nemá nic společného. ten blog jsem založil jen kvůli tomu, abych tam zveřejnil tuhle zranitelnost. To až potom jsem se rozhodl přidat tam i další příspěvky.
d) zjistit, kolik lidí má o takovou informaci zájem a kolik si jí zhruba přečete. I kdyby to mělo mít 1% dopad na povědomí o výše uvedeném nebo zvýšení povědomí o bezpečnosti obecně, je to pro mě obrovský úspěch.


Mimochodem, nějak jste zapomněl vysvětlit, proč si myslíte, že Azure AppService je typ služby, kde by tohle mělo být ošetřeno provozovatelem služby a ne autorem aplikace. Normálně se totiž poskytují oba typy služeb – někdo vám poskytne čistý hardware nebo VPS a je zcela na vás, co si s tím uděláte. Máte na daném počítači roota nebo administrátora a je na vás, abyste si to zabezpečil.

A proč bych vás měl vodit za ručičku. Vy neumíte číst? Nebo použít Google? Zjevně ano, když reagujete na něco, o čem, zase - jako jiní reagující, nic nevíte a předem si nic nezjistíte. App Service je služba typu SAAS. To je software as a service. I když v tomhle případě je to mnohem více, zahrnul bych to do téhle kategorie. To znamená, že o komplet podvozek se vám stará provozovatel. Nicméně, u takového typu služeb máte jen minimální možnost, jak něco nakonfigurovat. A vězte, že tam rozhodně nemáte roota. Výhoda této služby je, že skutečně jen deployujete aplikaci a nemusíte se starat o instalaci, konfiguraci, ale hlavně zabezpečení a aktualizace celého toho ansáblu, který je k provozu vašeho businessu potřeba. Provozovat webovou aplikaci na vlastním železu nebo pouze na "železu" typu VPS, který jste zmínil obrovská zodpovědnost se spoustou zbytečné práce kolem, o které když nic nevíte, tak to dopadne přesně tak, že máte 777 na wwwroot, default admin admin a spoustu otevřených věcí, protože se vám to prostě jinak rozjet nepovedlo nebo jste to na něco zapomněl  nebo jste to tam zapomněl, což je u profesionálů mnohem běžnější (i přes to, že se leckdy mají řídit konfiguračními standardy a interními předpisy firem. Ale jsou to taky jenom lidi, že?)

Nevím, jak jste přišel na to, že Azure AppService má blíž k tomu druhému – podle mne bude obecný webový server vždy patřit do té první kategorie, tudíž je na tom, kdo tam nasazuje nějakou aplikaci, aby si zajistil, že je ta aplikace bezpečná – nejde vytvořit takový obecný web server, který zabrání nasazené aplikaci v čemkoli nebezpečném.

Opět. Další. Nic o tom nevíte a píšete. Proč si o tom nejdříve něco nepřečtete, nevytvoříte si v Azute free účet a nevyzkoušíte si to, než začnete teoretizovat? Azure není obecný web server. A jak jsem na to přišel? Asi tak, že jsem si s tím hrál a přečetl jsem si spoustu dokumentů jak o funkčnosti, tak o zabezpečení. A věřte, že je to moc pěkné čtení. Asi tak jako když vám šmejdi nabízí hrnce. To se taky pěkně poslouchá.

Citace
A k té poznámce na konec, jak jste nepochopil, jak funguje autoaktualizace webových aplikací, třeba WordPressu – pokud má ta aplikace umět zaktualizovat sama sebe, vždy musí mít právo na serveru přepsat soubory aplikace, které jsou „spustitelné“ webovým serverem. To je přece princip aktualizace – že původní aplikaci nahradíte novou verzí.

Já to právě, a asi i boužel, chápu moc dobře. Jenže ta autoaktualizace musí být spuštěná z důvěryhodných zdrojů, důvěryhodným uživatelem a ideálně odděleně od "nedůvěryhodného" (nebo raději méně důvěrného, aby mě zase netahal někdo za slovíčko). Správně je to tak, že autoupdate proces běží pod separátním účtem, stáhne si co potřebuje a aktualizuje wwwroot. Ale zase nemůže dělat vůbec nic jiného. Tzn. nemůže kamkoliv na internet a nemůže si dělat co chce na disku. Ale ze všeho nejsprávnější je, že žádný autoupdate není. Protože nejdříve by se měla udělat revize a testování aktualizace ze všech pohledů, než se vůbec nasadí. Na wordpressu je o tom celý ansábl dokumentů, jak to dělat správně a bezpečně. Já to nečetl. Nemám ho rád. A naštěstí jsem ho nikdy nemusel deployovat nebo s ním něco dělat.

Mimochodem, přečetl jste si ten dokument, na který odkazuji v blogovém příspěvku? Hardening WordPress? Víte, ono to není o tom, že si přečtete půlku informací (nebo vlastně spíše žádné, ty se obvykle hledají, až když clověk neví jak dál), stáhnete si worpress, vyklikáte si tři volby v instalátoru a považujete svojí práci hotovou. Když to chcete brát vážně, je potřeba to nastudovat komplet. Že to je moc práce? Souhlasím. Nebo spousta let praxe.


Fis

Ja to taky nechapu. Navic Microsofti bug bounty program se vztahuje i na Azure, tak jim to bezte nareportovat, ne?

Víte, ono vás to po dvou měsících komunikace s MSRC a Bounty přestane bavit. Zvlášť, když odpovídají, jak odpovídají. Kluci z Project Zero to vydrželi jen týden.

andy

Zkus mi osvětlit ten problém - vzhledem k tomu, že ta webová aplikace může být v PHP, node, pythonu apod., tak si může na tom systému dělat v rámci svých práv co chce celkem bez ohledu na to, jestli má někam zápis nebo ne. Mohl bys mi zkusit vysvětlit, v čem je ten problém?

Ssouhlasím s tím, že je lepší, když ta webová aplikace nemá právo zápisu pomalu nikam; ale je docela rozdíl v "je to best practice" a "je to díra".

Fis

On jde spíš o to, co je "security best practice". Asi se shodneme na tom, že best practice není první návod na rozběhnutí něčeho, který najdu na webu.

Napsal jsi to naprosto správně. Aplikace si může dělat co chce v rámci svých práv, což v případě Linuxových serverů jsou "většinou" práva uživatele/skupiny webdata, na IIS pak IUSR_něco nebo networkservice nebo impersonifikovaného uživatele (je tam toho víc, už jsem to dlouho neklikal, tak si to nepamatuju).

To co může ta PHPková, ale klidně i nativní, CGIčková aplikace dělat se řídí právě těmihle oprávněními. Protože pod nimi běží např. apache, v tom třeba interpret PHP a pak teprve ta apka. A tyhle práva by, jak zase správně píšeš, měly být co možná nejomezenější. Proč?

Obecně. Je jedno, jestli to je PHP nebo nativní kód. A je úplně jedno, jestli to je webová apka nebo server od tlustýho klienta použvajícího ke komunikaci úplně jiný protokol (typicky RMI, RPC a pod.). mail server nebo cokoliv jiného. Vždycky pod tím běží nějaký operák, který se stará o přidělení zdrojů danému procesu. Prostě jakmile je to vyzadekený na síť, existuje hrozba, že se to někdo pokusí napadnout a čím víc práv ten daný server bude mít, tím víc práv bude mít i ten útočník a tím pádem, tím větší škodu může napáchat. Kromě toho, ve větších prostředích, né když s něco postavím sám, je problém s tím, že i admin může něco provést. Proto se dělí role na admina OS, admina Web server a admina aplikace.

V čem je problém konkrétně u Azure? Těch problémů je, hypoteticky, víc.

Předpoklady pro zneužití téhle díry jsou (jsou to jen základn příklady):

Vždy je předpoklad, že zapisuje na lokální filesystém (jinak bych tam nemohl jako útočník nic nahrát, že ;)

a potom:

a) aplikace je děravá, tzn. nějakým způsobem, třeba pomocí get/post parametrů jsem ji schopen manipulovat
b) aplikace má úmyslně nějaký interface ke správě souborů, třeba fotek a spoléhá se, že OS zajistí práva na složky (je to nejjednodušší, jak to napsat a bude to typicky problém, když použiju knihovnu třetí strany, o které nic nevím)
c) v administračním rozhraní aplikace je úmyslně nejaký filebrowser pro adminy aplikace, aby mohli něco dělat na filesystému - tady pozor, admin interface běží třeba i na jiném portu a nemá k němi nikdo jiný než aplikační admin přístup.
d) není nijak omezen typ souboru, který můžu na filesystém uložit

tyhle požadavky se dají velmi snadno splnit. Ještě 5 let zpátky je splňovala každá druhá apka.

Zneužití:

Všechny případy mi dovolí na web server do www root nahrát cokoliv, tzn. třeba i soubor s příponou .php (v případě .Net pak do wwwroot aspx, do wwwroot/bin dll s kódem), který pak můžu spustit.

Dopady:
Můžu třeba vyměnit originální apku a odchytávat hesla
Můžu kompletně ukrást celý aplikační kód původní aplikace (což mi hrozně zjednoduší jiné kroky)
Můžu kompletně vykrást databázi (protože si zjistím connection stringy)
Můžu si začít provozovat svojí apku za cizí peníze
Ani v jednom případu nezjistím, kdo mi ty soubory na disk zapsal. Vlastně ano, byl to www-data user nebo iis iusr_ něco. A to je samozřejmě špatně.

Ochrana:
nemít zápis práva na www root
typicky se zápisová práva pro web-data skupinu nastavují jen na vybrané složky nebo soubory mimo wwwroot (třeba /var/log/apache/něco nebo /tmp/www/files) - tohle je léta uznávaný "security best practice" a každý web server, když ho vydeplojuji, má dnes takto práva nastavená. Vy co updatujete Wordpress automaticky, že jste to museli nějak prasit, aby vám to fungovalo?




Fis

Já tam napsal jiný slovo než "vyzadekený" :D To mě hodně pobavilo :D


Tomas2

  • ****
  • 310
    • Zobrazit profil
    • E-mail

aneb řečeno, vadí ti, že obrazy na Azure nejsou secured by default a potřebuješ k tomu admina, aby daný stroj dal do pořádku? Dobrej objev...

Fis


aneb řečeno, vadí ti, že obrazy na Azure nejsou secured by default a potřebuješ k tomu admina, aby daný stroj dal do pořádku? Dobrej objev...

Uz jsem to psal... U AppService nejde nic takoveho udelat explicitne. Je to sluzba ber jak je. Neni tam nic jako moznost nastaveni prav.

Ach jo. Docela mě mrzí, že vaše povědomí o bezpečnosti je takové jaké je. Jen doufám, že neprovozujete žádné webové služby. Nebo aspoň takové, kde byste mohl svým zákazníkům spíše uškodit. Nebo s tímhle přístupem raději žádné.
Tahle fáze je vždycky zábavná. Přijde někdo, kdo předvádí znalosti, jako by si právě přečetl knížku „Učebnice něčeho pro zelenáče“, a začne se pohoršovat nad tím, jak to všichni kolem dělají špatně. Přičemž obvykle není schopen to podpořit žádnými argumenty a protiargumenty ostatních nechápe, protože to v učebnici pro zelenáče nebylo.

Podle vás jsem měl obsah sdělení přepsat sem? Primárním účelem bylo varovat
Ono by vám to jedině prospělo, kdybyste měl jednou větou zformulovat, v čem je problém.

Jinak by asi bylo dobré uvědomit si, že tohle je diskusní fórum. Na diskusním fóru se diskutuje, neslouží k varování. Diskutovat se dá třeba o tom, jestli to, co vy považujete za chybu, je opravdu chyba. Jenže to byste musel napsat, že to a to považujete za chybu z toho a toho důvodu.

chce provozovat v Azure aplikaci na App Service, aby věděli, že pokud si nezabezpečí svoji aplikací tím, že ji napíšou správně (a věřte, že to nejde a vždy se najde nějaká chyba)
Nikoli. „Zabezpečit aplikaci“ v tomto případě znamená zajistit, aby s její pomocí útočník nemohl zapsat na server soubory, které by mohl server nebo klient interpretovat. To není zas až tak těžké, resp. programátor se musí trochu snažit, aby takovou chybu vůbec vyrobil. Pokud takovou chybu někdo vyrobí, je to proto, že na bezpečnost úplně kašle – a pak bude mít v aplikaci nejspíš ještě spoustu jiných bezpečnostních chyb, před kterými ho server zachránit stejně nemůže.

Ostatně je to vidět i na vás, kdy jste si sice uvědomil riziko interpretace kódu na serveru, ale úplně jste pominul riziko interpretace kódu (např. JavScriptu) na klientovi.

aby si by byli vědomi toho, že pomocí téhle zranitelnosti budou útočníci schopni v rámci daného oprávnění IIS udělat úplně všechno. Vykrást databázi, bezpečnostní klíče i vlastní  kód aplikace. A bohužel, mnohem hůře, vydeployovat si svou aplikaci a např. phishovat hesla.
Ne pomocí téhle zranitelnosti, pomocí té chyby v aplikaci. Víte, jak řeší WordPress ty autoaktualizace, když web server nemá práva zápisu do souborů webu? Vyžádá si od váš přihlašovací údaje pro FTP přístup a aktualizuje se přes něj. Ve vašem pojetí je FTP přístup „zranitelnost serveru“, přes kterou může útočník získat kontrolu nad serverem a v rámci jeho oprávnění udělat úplně všechno. Ano, je to tak, a proto se přístup k FTP drží v tajnosti a proto se neumožňuje komukoli zapisovat do souborového systému web serveru.

Ano, je rozumné umožnit správci serveru zakázat uživateli, pod kterým běží ten server, zápis do souborového systému. Pokud to aplikace nepotřebuje, může si to její správce nastavit jako další vrstvu ochrany – třeba jako hashování hesel. Ale není to primární ochrana. Když zakážete zápis do souborového systému, a nějaká aplikace ho bude potřebovat, bude si příslušná data místo toho ukládat do databáze – a jsme tam, kde jsme byli, když to bude napsané špatně, umožní to útočníkovi spouštět kód v kontextu webového serveru nebo prohlížeče.

upozornit na to, jak Microsoft reaguje na oznámení o bezpečnostních hrozbách
Poslali vás do háje? To by byla adekvátní reakce na někoho, kdo sotva pochytil nějaké základy, a hned sebevědomě tvrdí, že tam mají vážnou chybu, a nenechá si to vysvětlit.

s mým blogem to nemá nic společného. ten blog jsem založil jen kvůli tomu, abych tam zveřejnil tuhle zranitelnost. To až potom jsem se rozhodl přidat tam i další příspěvky.
Naopak, váš původní komentář je čistě jen propagace toho vašeho příspěvku na blogu. Z obsahu toho „diskusního“ příspěvku jsme se nedozvěděli nic, akorát pod čarou se dalo tušit, že zase další zelenáč zavítal do oblasti bezpečnosti, zaregistroval nějaký úplný základ a na jeho základě učinil objev, se kterým se hned musí pochlubit – místo aby se pokorně snažil to celé pochopit. Po rozkliknutí odkazu (udělal jsem to, až když tady byly nějaké komentáře – ráno jsem ten příspěvek rovnou nahlásil jako spam a odkaz jsem ani nerozklikával) se tušení potvrdilo.

zjistit, kolik lidí má o takovou informaci zájem
K informaci to má hodně daleko. Aby to byla informace, musel byste se oprostit od představy, že jste objevil bezpečnostní díru, a místo toho pro ostatní zelenáče popsat, že dovolit uživatelům vytvářet na serveru obsah je vždy rizikové. A že jedním z rizik je, když uživatelům dovolíte na server nahrávat soubory – že je pak potřeba si ověřit, jak je server nakonfigurovaný a co s těmi soubory bude dělat – na základě jejich umístění, názvu, obsahu.

kolik si jí zhruba přečete
Právě proto jsem na ten odkaz původně neklikal. Musíte si ale uvědomit, že když lidé klikají na odkaz, nevědí ještě, co je na cílové stránce. Takže když si přečtou to, co jste v úvodním komentáři napsal, mohou se řídit jenom tím – takže na odkaz kliknou ti naivnější, kteří si myslí, že je to o bezpečnostní díře v Azure AppService, a pak na to klikne ta většina, která se chce pobavit tím, co zase vyplodil někdo, kdo umí změnit obrázek na ploše Windows, tak už si o sobě myslí, že je bezpečnostní odborník.

I kdyby to mělo mít 1% dopad na povědomí o výše uvedeném nebo zvýšení povědomí o bezpečnosti obecně, je to pro mě obrovský úspěch.
Ano, kdyby tohle způsobilo zvýšení povědomí o bezpečnosti, byl by to opravdu nečekaný úspěch. Zatím to ale vypadá, že pro zvýšení průměrného povědomí o bezpečnosti můžete nejvíc udělat tak, že se budete sám vzdělávat.

A proč bych vás měl vodit za ručičku. Vy neumíte číst? Nebo použít Google?
Nejde o to, abyste za ručičku vodil mne. Jde o to, že kdybyste se to pokusil vysvětlit, třeba by vám došlo, že toho o problému zas tak moc nevíte a že si to nejdřív musíte lépe nastudovat.

Zjevně ano, když reagujete na něco, o čem, zase - jako jiní reagující, nic nevíte a předem si nic nezjistíte.
No, pokud jde o úroveň znalostí, jste v této diskusi na chvostu vy. Jsou tu i jiní diskutující, kteří jsou v obraze podstatně lépe než vy.

App Service je služba typu SAAS. To je software as a service. I když v tomhle případě je to mnohem více, zahrnul bych to do téhle kategorie. To znamená, že o komplet podvozek se vám stará provozovatel. Nicméně, u takového typu služeb máte jen minimální možnost, jak něco nakonfigurovat. A vězte, že tam rozhodně nemáte roota. Výhoda této služby je, že skutečně jen deployujete aplikaci a nemusíte se starat o instalaci, konfiguraci, ale hlavně zabezpečení a aktualizace celého toho ansáblu, který je k provozu vašeho businessu potřeba.
Jenže provozovatel se stará o vše od úrovně webového serveru níž. Samotná webová aplikace už je vaše starost, a to včetně zabezpečení. Tam vám provozovatel SaaS žádným způsobe nepomůže a musíte prostě počítat s tím, že veškerá práva, která máte jako provozovatel aplikace, můžete chybami ve vaší aplikaci zpřístupnit i útočníkům. Když v té aplikaci budete mít chybu SQL injection, může útočník manipulovat s databází – a není to chyba provozovatele webového serveru, ale chyba vaší aplikace. A když tam budete mít chybu file injection, je to zase chyba vaší aplikace.

máte 777 na wwwroot
Což nutně nemusí být chyba.

První pravidlo bezpečnosti je, že neexistuje žádná obecná bezpečnost, kterou buď máte nebo nemáte. Vždy se jedná o zabezpečení konkrétní aplikace, kterou musíte zabezpečit tak, aby dál poskytovala služby, které poskytovat má. Pokud ta aplikace má umožňovat nahrávání souborů na server, je samozřejmě obtížnější to zabezpečit – ale pokud to dělat má, tak je holt potřeba se tomu zabezpečení věnovat.

default admin admin
To je úplně něco jiného, k tomu není žádný důvod a pokud je tohle přístupné z venku, není to žádné zabezpečení. To, že může webový server zapisovat soubory, které může následně číst a případně interpretovat, samo o sobě žádná chyba není.

Opět. Další. Nic o tom nevíte a píšete. Proč si o tom nejdříve něco nepřečtete
Vy jste s tím začal.

Azure není obecný web server.
Ne? Vy tam nemůžete nahrát libovolný soubor, který od následně bude servírovat klientům? Už jen to samo o sobě by na funkci „obecný web server“ stačilo.

A jak jsem na to přišel? Asi tak, že jsem si s tím hrál a přečetl jsem si spoustu dokumentů jak o funkčnosti, tak o zabezpečení. A věřte, že je to moc pěkné čtení. Asi tak jako když vám šmejdi nabízí hrnce. To se taky pěkně poslouchá.
Pak byste si měl také přečíst nějaké základy. Třeba o tom, že za bezpečnost každé aplikace je zodpovědný její autor, a nikdy není možné zabezpečit aplikaci jenom tím, že pro její vytvoření nebo provoz použijete nějaké nástroje. Ty nástroje vám mohou pomoci (např. když se pro přístup k SQL databázi standardně používá binding parametrů a ne skládání stringů), ale nikdy bezpečnost nevyřeší za vás.

Já to právě, a asi i boužel, chápu moc dobře. Jenže ta autoaktualizace musí být spuštěná z důvěryhodných zdrojů, důvěryhodným uživatelem a ideálně odděleně od "nedůvěryhodného" (nebo raději méně důvěrného, aby mě zase netahal někdo za slovíčko).
Ne, bohužel to asi nechápete vůbec. Autoaktualizace znamená, že a aplikace aktualizuje sama sebe, s těmi oprávněními, které má jako webová aplikace, a dělá to automaticky, bez zásahu uživatele. Ano, je to šílené, je to berlička pro situace, kde neexistuje rozumná správa software, ale bohužel se tenhle mor z Windows šíří i na jiné systémy.

Správně je to tak, že autoupdate proces běží pod separátním účtem, stáhne si co potřebuje a aktualizuje wwwroot.
Ano, jenže to už pak není autoupdate (kdy aplikace aktualizuje sama sebe), ale běžný update správcem aplikací.

Protože nejdříve by se měla udělat revize a testování aktualizace ze všech pohledů, než se vůbec nasadí. Na wordpressu je o tom celý ansábl dokumentů, jak to dělat správně a bezpečně. Já to nečetl. Nemám ho rád. A naštěstí jsem ho nikdy nemusel deployovat nebo s ním něco dělat.
WordPress obvykle neprovozují lidé, kteří by byli schopní dělat nějaké testy před nasazením. Tam je úspěch to, že se to zaktualizuje dost rychle samo, takže těch nezabezpečených WordPressů není tolik, kolik by jich mohlo být. Ano, autoaktualizace jsou velmi špatné řešení, ale pořád výrazně lepší, než neaktualizovaný WordPress. To, že se prosadil zrovna takhle děravý systém, mne vůbec netěší, ale když už to tak dopadlo, je potřeba aspoň minimalizovat škody.

Mimochodem, přečetl jste si ten dokument, na který odkazuji v blogovém příspěvku? Hardening WordPress?
Pořád mne fascinuje, že si někdo přečte jeden článek někde na webu, a hned se považuje za experta.

Máte to napsané i v tom vlastním zápisku. „standard 755/644 respectively“ Víte, co znamená pro vlastníka adresáře práva 755? Důležitá je ta sedmička, a ta říká „právo pro čtení, zápis a procházení adresářů“. Pro soubory ta šestka znamená „čtení a zápis“. Víte, kdo je typicky vlastníkem těch souborů WordPressu? Uživatel, pod kterým běží webový server. V případech, kdy to tak není, musíte pro adresáře, do kterých WordPress dělá upload, nastavit práva jinak, aby tam mohl i ten webový server zapisovat. Což se v té příručce pro zelenáče nedozvíte, tam je jenom ten úplně nejjednodušší postup. Víte, co to celé znamená? Že ty webové servery, na kterých běží WordPress, jsou typicky nakonfigurované právě tak, jako Azure AppService – tedy že uživatel, pod kterým běží web server, má právo zápisu do oblasti, odkud web server servíruje obsah a odkud také spouští skripty. Díky tomu bylo třeba docela snadné do WordPressu naprogramovat tu autoaktualizaci nebo instalaci pluginů přes webové rozhraní, díky tomu se WordPress může „instalovat“ (ona je to spíš konfigurace) přímo přes webový prohlížeč. Ono by to šlo i bez toho, ty soubory by se ukládaly do databáze a interpretovaly odsud, ale to by jednak omezilo kešování na straně webového serveru, ale hlavně by to bylo ještě náchylnější na bezpečnostní díry, než současný WordPress. Takže díky za ta práva -w- na těch webových serverech.

Víte, ono to není o tom, že si přečtete půlku informací (nebo vlastně spíše žádné, ty se obvykle hledají, až když clověk neví jak dál), stáhnete si worpress, vyklikáte si tři volby v instalátoru a považujete svojí práci hotovou. Když to chcete brát vážně, je potřeba to nastudovat komplet. Že to je moc práce? Souhlasím. Nebo spousta let praxe.
Teoreticky to máte zmáknuté dobře. Tak teď ještě abyste se tím začal řídit.

Sten

Milý pane odborníku, Azure App Service není SaaS. SaaS je služba, kdy vám někdo pronajme hotový software provozovaný na jejich infrastruktuře. Takové služby nabízí třeba GitHub či Atlassian. Rule of thumb je, že k tomu software nemáte zdrojáky a nestaráte se o aktualizace. Azure App Service je PaaS. To je docela zásadní rozdíl, co se týče nároků na zabezpečení.

PCI DSS nevyžaduje, aby aplikace neměla možnost měnit své chování či se aktualizovat. Pojem „security best practice“ se v PCI DSS oddílu 6 nevyskytuje vůbec, nejbližší podobný termín „industry standards and best practices“ se týká jen vývoje, a to nejspíš protože je to tak abstraktní pojem, že je prakticky nevymahatelný.

Vždy je předpoklad, že zapisuje na lokální filesystém (jinak bych tam nemohl jako útočník nic nahrát, že ;)
To je chybný předpoklad. Pokud ta aplikace bude zapisovat do databáze, může vzniknout úplně stejný problém. Typický příklad je script injection – třeba diskusní fórum, kde bude moci útočník vložit do svého příspěvku javascriptový kód, který se následně provede v kontextu diskusního fóra všem, kteří se na příslušnou webovou stránku podívají. A samozřejmě – v závislosti na aplikaci – v té databázi může být uložen i kód, který může provádět server. Doufám, že nebudete dál hájit svůj přístup a tvrdit, že v tom případě nemá Azure AppService povolit ani zápis do databáze.

a) aplikace je děravá, tzn. nějakým způsobem, třeba pomocí get/post parametrů jsem ji schopen manipulovat
Pak je potřeba tuhle chybu opravit.

b) aplikace má úmyslně nějaký interface ke správě souborů, třeba fotek a spoléhá se, že OS zajistí práva na složky (je to nejjednodušší, jak to napsat a bude to typicky problém, když použiju knihovnu třetí strany, o které nic nevím)
c) v administračním rozhraní aplikace je úmyslně nejaký filebrowser pro adminy aplikace, aby mohli něco dělat na filesystému - tady pozor, admin interface běží třeba i na jiném portu a nemá k němi nikdo jiný než aplikační admin přístup.
d) není nijak omezen typ souboru, který můžu na filesystém uložit
Buď k tomu mají přístup jen důvěryhodní lidé, a u těch se předpokládá, že škodit nebudou. A samozřejmě je nutné zabezpečit, že se k tomu rozhraní nedostane nikdo nepovolaný. Naopak, kdyby web server nepovoloval zápis souborů, budou tyhle funkce b) až d) úplně k ničemu.


tyhle požadavky se dají velmi snadno splnit. Ještě 5 let zpátky je splňovala každá druhá apka.
Což je problém těch aplikací a je nutné jej opravit v té aplikaci. Na úrovní webového serveru to není řešitelné – jak jsem psal výše, když aplikaci zakážete zapisovat do souborového systému, upraví to programátor tak, aby to zapisoval do databáze, a udělá tam úplně tu stejnou chybu.

nemít zápis práva na www root
To není ochrana, je to pojistka pro případ, kdy primární ochrana (v aplikaci) selže. A často tahle pojistka není použitelná. Např. byste asi marně hledal veřejný PHP webhosting, kde web server nemá právo zápisu do adresářů, odkud se servíruje obsah – protože by si uživatelé stěžovali, že jim tam nefunguje spousta aplikací.

tohle je léta uznávaný "security best practice" a každý web server, když ho vydeplojuji, má dnes takto práva nastavená.
Tohle si můžete nastavit na svém serveru, když víte, jaké požadavky má aplikace, kterou tam budete instalovat. Na veřejném hostingu je to neprůchozí.

Vy co updatujete Wordpress automaticky, že jste to museli nějak prasit, aby vám to fungovalo?
Vždyť to máte napsané v závěru toho vašeho blogového zápisku. Standardní právo write pro vlastníka, tedy pro webový server. Funguje to tak na každém veřejném PHP webhostingu. Takové ty vaše větičky o tom, jak byste se měl dovzdělávat, už si jistě doplníte sám.

Fis

Milý pane odborníku, Azure App Service není SaaS. SaaS je služba, kdy vám někdo pronajme hotový software provozovaný na jejich infrastruktuře. Takové služby nabízí třeba GitHub či Atlassian. Rule of thumb je, že k tomu software nemáte zdrojáky a nestaráte se o aktualizace. Azure App Service je PaaS. To je docela zásadní rozdíl, co se týče nároků na zabezpečení.

Mate samozrejme pravdu. Ruka byla rychlejsi nez myslenka. Je to PaaS. To ale neznamena, ze to, za co ma odpovednost provozovatel bude zabezpeceno jinak nebo mene. Konkretne u App Service nemate moznost cokoliv managovat a nastavovat opravneni, tzn. melo by to byt utazeno pokud mozno co nejvice. Nelze se spolehat na bezpecnost aplikace. To bysme potom mohli rici, ze aplikace se postara o veskerou bezpecnost.

PCI DSS nevyžaduje, aby aplikace neměla možnost měnit své chování či se aktualizovat. Pojem „security best practice“ se v PCI DSS oddílu 6 nevyskytuje vůbec, nejbližší podobný termín „industry standards and best practices“ se týká jen vývoje, a to nejspíš protože je to tak abstraktní pojem, že je prakticky nevymahatelný.

Budeme tedy slovickarit. Krome toho, ze PCI DSS je jenom a pouze bezpecnostni standard (provoz a vyvoj z ostatnich hledisek je ciste vase vec, pokud dodrzite bezpecnostni pozadavky). Pozadavek 6 standardu 3.2 (aby me tu zase nekdo neobvinil, ze pouzivam starsi, nicmene stale platny standard) rika: Develop and maintain secure systems and applications. Dale v pozadavcich (a poznamkach) pak je presne to co pisete, industry best practices a best practices. Protoze je PCI DSS bezpecnostni standard a pozadavek 6 je o "secure" systems & applications,  industry best practices a best practices = je rozhodne mysleno jako security best practices.

O te nevymahatelnosti byste se mohl chvili zkusit hadat s auditorem. Vy totiz mate podle PCI DSS standardu (hlavne pozadavek 2, ale v podstate se jedna o vsechny pozadavky) povinnost presne zdokumentovat a prokazat na zaklade jakych best practices a guides a standards provadite jake cinnosti a take to na vyzadani predvest. A to ze to tak nedelate se prokaze velmi rychle. Pro systemy a jejich konfiguraci se casto pouziva CIS, pro vyvoj SW treba OWASP, pro penetracni testovani treba NIST nebo take OWASP. Uznavaji se take konfiguracni standardy a hardening guides vyrobcu jednotlivych produktu. Jako je prave treba hardening guide k WordPressu.

Pozadavek 6 se vztahuje hlavne k aplikacim, to ano, ale k systemum take. On se tak nejmenuje jen tak nahodou. Jinak systemum jako takovym se venuje hlavne bod 2, do ktereho by pravdepodobne spadla i mnou uvadena zranitelnost, protoze je to konfiguracni chyba.  Pozadavek 2 o konfiguracnich standardech a jejich dodrzovani, jenze uz jsem psal vyse, ty nejsou verejne k dispozici, takze neni mozno zjistit, jestli a jak je porusen. U pozadavku 6 je to vcelku jasne. Proste neudrzuji secure systems.

melo by to byt utazeno pokud mozno co nejvice
Zkuste být konkrétnější. A taky napište, kdo by pak takovou službu kupoval.

Nelze se spolehat na bezpecnost aplikace. To bysme potom mohli rici, ze aplikace se postara o veskerou bezpecnost.
Ano, aplikace se musí postarat o veškerou bezpečnost. Nelze nebezpečnou aplikaci obecně zabezpečit zvenčí – vždycky někdo vymyslí nějaký nový způsob, jak udělat aplikaci nebezpečnou. Ostatně, kdyby to šlo udělat z venčí, proč by operační systém vůbec umožňoval něco jiného? Napište ten váš operační systém, ve kterém nepůjde provozovat aplikace nebezpečným způsobem, a bude z vás miliardář.

mnou uvadena zranitelnost, protoze je to konfiguracni chyba
Povolený zápis do databáze, který může mít úplně stejné důsledky, také považujete za konfigurační chybu?

Citace
Konkretne u App Service nemate moznost cokoliv managovat a nastavovat opravneni, tzn. melo by to byt utazeno pokud mozno co nejvice

Nedá se to provést ani z kódu dané aplikace (případně nějaké miniaplikace, kterou pustíte jednou a pak ji odstraníte)? Zejména pokud jste schopen spustit i nativní kód (řekněme načíst DLL knihovnu), měl byste mít přístup k příslušným API, abyste mohl upravit příslušná ACL tak, aby k nim uživatel, pod kterým běží webserver, ztratil přístup, který mu dát nechcete.

Netvrdím, že se jedná o zvlášť úžasné řešení, ale těm, kdo chtějí své aplikaci ubrat nějaké to oprávnění, by mohlo posloužit.

Kdybyste možnost zápisu do www root nenazýval "critical vulnerability", ale spíše popsal možnost, jak podle vás vytvořit pro většinu aplikací bezpečnější prostředí, toto téma by asi vypadalo jinak (pokud by vůbec existovalo). Kritická zranitelnost podle mojí zkušenosti vypadá úplně jinak.

Fis

Tahle fáze je vždycky zábavná. Přijde někdo, kdo předvádí znalosti, jako by si právě přečetl knížku „Učebnice něčeho pro zelenáče“, a začne se pohoršovat nad tím, jak to všichni kolem dělají špatně. Přičemž obvykle není schopen to podpořit žádnými argumenty a protiargumenty ostatních nechápe, protože to v učebnici pro zelenáče nebylo.

Víte, řekl bych to takhle, až budete mít naježděno dopředu to co já nacouváno.... Dělám bezpečnost přes 10 let, z toho 4 roky ve finančním sektoru, zhruba 250 Web App pentestů, 50 infrastrukturních a pár dalších zajímacých. Předtím 8 let praxe admina od sítí přes os až po aplikace. A ještě předtím něco málo profesionálního developmentu v Delphi a PHP. Obecně je programování tak trochu i můj koníček, takže tomu se více nebo méně věnuji vlastně pořád, v různých jazycích od c po javascript. Takže abych to uzavřel, řekl bych, že o tom vím jen o malinkou píď víc než kdybych si jen přečetl knihu "42 for Dummies".

Ono by vám to jedině prospělo, kdybyste měl jednou větou zformulovat, v čem je problém.

Jinak by asi bylo dobré uvědomit si, že tohle je diskusní fórum. Na diskusním fóru se diskutuje, neslouží k varování. Diskutovat se dá třeba o tom, jestli to, co vy považujete za chybu, je opravdu chyba. Jenže to byste musel napsat, že to a to považujete za chybu z toho a toho důvodu.

To, co předvátíte je pouze zbytečné pruzení. V blogu jsem to jednoznačně vysvětlil, ve fóru nalinkoval a očekával diskuzi. No a teď o tom diskutujeme, že? Takže účel svetí prostředky. Na blogu jsem varoval, na fóru o tom diskutujeme.

Nikoli. „Zabezpečit aplikaci“ v tomto případě znamená zajistit, aby s její pomocí útočník nemohl zapsat na server soubory, které by mohl server nebo klient interpretovat. To není zas až tak těžké, resp. programátor se musí trochu snažit, aby takovou chybu vůbec vyrobil. Pokud takovou chybu někdo vyrobí, je to proto, že na bezpečnost úplně kašle – a pak bude mít v aplikaci nejspíš ještě spoustu jiných bezpečnostních chyb, před kterými ho server zachránit stejně nemůže.
Ostatně je to vidět i na vás, kdy jste si sice uvědomil riziko interpretace kódu na serveru, ale úplně jste pominul riziko interpretace kódu (např. JavScriptu) na klientovi.
tomuhle v kontextu k tomu co jsem napsal vůbec nerozumím. Napsal jsem (jinými slovy), že pokud zprasím apku, tak mě AppService nezachrání. Přesto že by měla. Můžete mi vysvětlit, jak se vztahuje Stored XSS k deploymentu vlastní aplikace na server? Mícháte hrušky a jablka. Bavíme se primárně o zranitelnosti "DEPLOYMENT ČEHOKOLIV NA SERVER", který má nějaké předpoklady. Jako třeba připojení k síti. Nebo děravou apku. A proč to můžu udělat? Protože tomu server nezabránil. To, že tomu primárně nezabránila aplikace, to je jiná zranitelnost. A může to být 100+1 různých druhů zranitelostí, proč tomu aplikace nezabránila. Také to nemusí být zranitelnost, ale feature aplikace, která se spoléhá na zabezpečení podvozku. Těch vektorů je zde mnogo.

Ne pomocí téhle zranitelnosti, pomocí té chyby v aplikaci.
Ne. Přesne pomocí zneužití této chyby se to povede. Kdyby tam nebyla, nevydeployuju nic. I kdyby padaly trakaře a aplikace byla zprasená až do aleluja. Správce serveru se prostě nemůže spoléhat na to, že to vývojář nezprasí. A musí udělat všechno proto, že kdyby to vývojář zprasil, tak aby utočník udělal co nejmenší škodu. Jenže v případě téhle zranitelnosti je škoda skoro maximální. S velmi velkou pravděpodobností, že bude totální, protože dávám útočníkovi možnost útočit i na případný sandbox nebo přímo OS.

Víte, jak řeší WordPress ty autoaktualizace, když web server nemá práva zápisu do souborů webu? Vyžádá si od váš přihlašovací údaje pro FTP přístup a aktualizuje se přes něj. Ve vašem pojetí je FTP přístup „zranitelnost serveru“, přes kterou může útočník získat kontrolu nad serverem a v rámci jeho oprávnění udělat úplně všechno. Ano, je to tak, a proto se přístup k FTP drží v tajnosti a proto se neumožňuje komukoli zapisovat do souborového systému web serveru.

Nevím, jak to funguje s FTP přístupem, ale kdybych to navrhoval, tak cca takto: Ten updater, který updatuje Worpress běží pod jiným uživatelským účtem, než standartní web, vůbec není vystavený na web, běží ideálně na jiném serveru mimo web serverovou DMZ a jediné co může je stáhnout aktualizace z předem definovaného zdroje, ideálne přes HTTPS, FTPS nebo SFTP tak, aby byla zajištěná bezpečnost dat při přenosu s možností oveření zdroje aktualizací aplikace pomocí serverového certifikátu a pak instaluje aplikace do toho web rootu. To znamená, že k updateru nikdo, kromě admina nemůže. Ale stejně, jak jsem psal. Autoupdate není idální řešení. Aktualizace by se měly před nasazením otestovat. Jak z funkčního, tak z bezpečnostního hlediska. Ve většině prostředí také schválit jako změna.

Ano, je rozumné umožnit správci serveru zakázat uživateli, pod kterým běží ten server, zápis do souborového systému. Pokud to aplikace nepotřebuje, může si to její správce nastavit jako další vrstvu ochrany – třeba jako hashování hesel. Ale není to primární ochrana. Když zakážete zápis do souborového systému, a nějaká aplikace ho bude potřebovat, bude si příslušná data místo toho ukládat do databáze – a jsme tam, kde jsme byli, když to bude napsané špatně, umožní to útočníkovi spouštět kód v kontextu webového serveru nebo prohlížeče.

Pokud webová aplikace požaduje zápis do wwwroot, tak je to chyba v designu. Typicky, aplikace může zapisovat pouze do logů a nějakého tempu. Nikdy rovnou tam, co je znovu přístupné z webu. Validace toho, co tam můžu zapsat je samozřejmostí. Také by nikdy neměl být nastaven atribut Execute na takto zapsané soubory. Plus spoustu dalších věcí.

Pokud bude aplikace zapisovat data do SQL, tak se mi s velkou pravděpodobností nepodaří takové soubory na serveru vůbec zpustit. Jak bych to asi udělal? Pokud tedy někdo není blázen a nepoužívá nerozumně třeba PHP eval. S čímž už jsem se samožřejmě také párkrát setkal.

Poslali vás do háje? To by byla adekvátní reakce na někoho, kdo sotva pochytil nějaké základy, a hned sebevědomě tvrdí, že tam mají vážnou chybu, a nenechá si to vysvětlit.

Víte, s vámi je těžká práce. Nejste chopen pochopit, o co tady běží. Až se nahackujete aspoň na tři servery, dejte mi vědět. Ok? Jejich reakce byla taková, že jsem jim musel 3x vysvětlit o co běží, pak se 2 měsíce nikdo neozval a pak, když jsem pohrozil, že to zveřejním, odpověděli, že to je by design. Tak to mě zvedlo ze židle a proto to šlo ven. By design to být může, podle best practices (a to podle worpress hardening guide i jejich vlastních - prosím otevřete tehnle tehnle link, než zase napíšete nějakou hloupost - https://codex.wordpress.org/Hardening_WordPress#File_Permissions) to rozhodně není.


Citace
Spousta zelenáčů. neschopnosti, neznalosti, amatérismu...

Samozřejmně. Máte pravdu. Udělal jsem reklamu svému blogovému příspěvku. O tom se hádat nehodlám. Proč jsem to udělal jsem vám už vysvětlil. Ten zbytek komentovat nebudu, za to mi, takový amatér jako vy nestojí.

máte 777 na wwwroot
Což nutně nemusí být chyba.

Což samozřejmě z bezpečnostního pohledu je chyba naprosto zásadní.

První pravidlo bezpečnosti je, že neexistuje žádná obecná bezpečnost, kterou buď máte nebo nemáte. Vždy se jedná o zabezpečení konkrétní aplikace, kterou musíte zabezpečit tak, aby dál poskytovala služby, které poskytovat má. Pokud ta aplikace má umožňovat nahrávání souborů na server, je samozřejmě obtížnější to zabezpečit – ale pokud to dělat má, tak je holt potřeba se tomu zabezpečení věnovat.

Naopak. Obecná bezpečnost existuje a má svá pravidla. To že je neznáte neznamená, že neexistují. Pár úplně těch nejzákladnějších: Co nemusí ven, zůstane uvnitř. Co není potřeba, není nainstalováno. Co není potřeba, je zakázáno. Co je potřeba, to se povolí, pokud to má svůj business důvod, je riziko akceptovatelné nebo lze dopady snížit na akceptovatelnou úroveň.

Azure není obecný web server.

Ne? Vy tam nemůžete nahrát libovolný soubor, který od následně bude servírovat klientům? Už jen to samo o sobě by na funkci „obecný web server“ stačilo.
Ne. Azure AppService opravdu není jen obyčejný obecný webový, lépe řečeno aplikační server. Je to služba se spoustou dalších věcí. Ale z vašeho pohledu se to tak může jevit.

...

Správně je to tak, že autoupdate proces běží pod separátním účtem, stáhne si co potřebuje a aktualizuje wwwroot.
Ano, jenže to už pak není autoupdate (kdy aplikace aktualizuje sama sebe), ale běžný update správcem aplikací.

Prosím? Takže když dám do cronu skript, který je dodáván s aplikací, tak je to aktualizace správcem aplikací. To je pro mne novinka. To jsem nevěěl.

Protože nejdříve by se měla udělat revize a testování aktualizace ze všech pohledů, než se vůbec nasadí. Na wordpressu je o tom celý ansábl dokumentů, jak to dělat správně a bezpečně. Já to nečetl. Nemám ho rád. A naštěstí jsem ho nikdy nemusel deployovat nebo s ním něco dělat.
WordPress obvykle neprovozují lidé, kteří by byli schopní dělat nějaké testy před nasazením. Tam je úspěch to, že se to zaktualizuje dost rychle samo, takže těch nezabezpečených WordPressů není tolik, kolik by jich mohlo být. Ano, autoaktualizace jsou velmi špatné řešení, ale pořád výrazně lepší, než neaktualizovaný WordPress. To, že se prosadil zrovna takhle děravý systém, mne vůbec netěší, ale když už to tak dopadlo, je potřeba aspoň minimalizovat škody.

Konečně jste uhodil hřebíček na hlavičku. To je poprvé, co s vámi souhlasím. Krásné místo pro hackery.

Pořád mne fascinuje, že si někdo přečte jeden článek někde na webu, a hned se považuje za experta.

Asi myslíte hardening guide k word pressu. Vsadil bych si, že jste doteď ani netušil, že něco takového existuje.

Máte to napsané i v tom vlastním zápisku. „standard 755/644 respectively“ Víte, co znamená pro vlastníka adresáře práva 755? Důležitá je ta sedmička, a ta říká „právo pro čtení, zápis a procházení adresářů“. Pro soubory ta šestka znamená „čtení a zápis“. Víte, kdo je typicky vlastníkem těch souborů WordPressu? Uživatel, pod kterým běží webový server. V případech, kdy to tak není, musíte pro adresáře, do kterých WordPress dělá upload, nastavit práva jinak, aby tam mohl i ten webový server zapisovat. Což se v té příručce pro zelenáče nedozvíte, tam je jenom ten úplně nejjednodušší postup. Víte, co to celé znamená? Že ty webové servery, na kterých běží WordPress, jsou typicky nakonfigurované právě tak, jako Azure AppService – tedy že uživatel, pod kterým běží web server, má právo zápisu do oblasti, odkud web server servíruje obsah a odkud také spouští skripty. Díky tomu bylo třeba docela snadné do WordPressu naprogramovat tu autoaktualizaci nebo instalaci pluginů přes webové rozhraní, díky tomu se WordPress může „instalovat“ (ona je to spíš konfigurace) přímo přes webový prohlížeč. Ono by to šlo i bez toho, ty soubory by se ukládaly do databáze a interpretovaly odsud, ale to by jednak omezilo kešování na straně webového serveru, ale hlavně by to bylo ještě náchylnější na bezpečnostní díry, než současný WordPress. Takže díky za ta práva -w- na těch webových serverech.

Tady máte pravdu, ale jen do určité míry. Azure není správně nakonfigurován. Víte proč? Protože ten updated content spustím! tzn. má 777 (nebo něco podobného). Já osobně jsem i proti zápisu do www root (nebo jiné publikované složky) přímo tou službou publikovanou na web. Je to prostě nebezpečné. Ta databáze je mnohem mnohem, mnohem lepší. Nebo nějaký temp  pak background taskem profiltrovaný obsah zpět do wwwroot. Ale rozhodně ne nikdy na přímo. I když z provozního hlediska to nemusí být ideální. Ale tak už to holt chodí, co je bezpečné se špatně spravuje.

Fis

Citace
Konkretne u App Service nemate moznost cokoliv managovat a nastavovat opravneni, tzn. melo by to byt utazeno pokud mozno co nejvice

Citace
Nedá se to provést ani z kódu dané aplikace (případně nějaké miniaplikace, kterou pustíte jednou a pak ji odstraníte)? Zejména pokud jste schopen spustit i nativní kód (řekněme načíst DLL knihovnu), měl byste mít přístup k příslušným API, abyste mohl upravit příslušná ACL tak, aby k nim uživatel, pod kterým běží webserver, ztratil přístup, který mu dát nechcete.

Netvrdím, že se jedná o zvlášť úžasné řešení, ale těm, kdo chtějí své aplikaci ubrat nějaké to oprávnění, by mohlo posloužit.


Hezký hack. Nezkoušel jsem.

Citace
Kdybyste možnost zápisu do www root nenazýval "critical vulnerability", ale spíše popsal možnost, jak podle vás vytvořit pro většinu aplikací bezpečnější prostředí, toto téma by asi vypadalo jinak (pokud by vůbec existovalo). Kritická zranitelnost podle mojí zkušenosti vypadá úplně jinak.

Primárně nejde jen o zápis, ale o zápis a spuštění. To se spíše zvrtla diskuze. Ten vlastní zápis není critical, ale já bych to jako nález v pentestu jako HIGH uvedl.