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.
46 Odpovědí
8083 Zhlédnutí